Clarification on dApp share requiring custom verifiers

[hazim-j]

Hi! I'm currently building a mobile wallet and looking for some clarification about the dApp share (https://web3auth.io/docs/dapp-share)

At the bottom of the doc it says dappShare is only available for custom verifiers and not the standard web3auth verifiers but the reasoning is a bit vague. Could anyone help me better understand why this is the case?

[shahbaz17]

Hey @hazim-j

This is done to make sure that an application only has access to the corresponding share to the private key of their application's user. Hence, to use dApp Share, one has to use the custom authentication feature of Web3Auth.

Here, standard web3auth verifiers is the default verifier you get for the Web3Auth Plug n Play UI SDK

Also, the dApp Share is only returned to users who have enabled 2FA to their account.

To get dapp share in Android, one has to initialise web3auth like below:

web3Auth = Web3Auth (
  Web3AuthOptions (
    context = this,
    clientId = getString (R.string.web3auth_project_id),
    network = Web3Auth.Network.MAINNET,
    redirectUrl = Uri.parse ("{YOUR_APP_PACKAGE_NAME}://auth"),
    // Optional loginConfig object
    loginConfig = hashMapOf("google" to LoginConfigItem(
      verifier = "verifier-name", // get it from web3auth dashboard
      typeOfLogin = TypeOfLogin.GOOGLE,
      name = "Custom Google Login",
      clientId = getString(R.string.web3auth_google_client_id) // google's client id
    ))
  )
)

Web3Auth issues a dApp Share in the response, ie. a backup share, that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user.

See https://web3auth.io/docs/sdk/android/dapp-share#example to know more on how to use dapp share in subsequent logins.

[hazim-j]

This is done to make sure that an application only has access to the corresponding share to the private key of their application's user. Hence, to use dApp Share, one has to use the custom authentication feature of Web3Auth.

I read this in the docs but it doesn't really tell me why this is the case (unless I'm missing something obvious here). I guess my question more specifically is what is the difference between custom verifiers and standard web3auth verifiers?

Put another way, what is it about custom verifiers that make the below statement true?

This is done to make sure that an application only has access to the corresponding share to the private key of their application's user.

[himanshuchawla009]

Hi, first of thanks for asking this question, So before biting the bullet to answer why dappShare is returned for custom verifiers and how dapps can use this share, I will make some effort to describe what verifier is and what is the difference between custom and default verifiers.

• Verifier:- A verifier is a piece of information about the OAuth provider being used by the application which is queried by web3auth auth network nodes from a smart contract deployed on the Ethereum blockchain to verify the jwt token.

• Default verifiers:- These are the verifiers associated with OAuth providers which are owned and managed by web3auth's account.

• Custom verifiers:- If you want to manage your OAuth providers yourself or maybe want to use some proxy providers like firebase, aws cognito, auth0 etc, you can create your custom verifiers from the developer dashboard. https://dashboard.web3auth.io.

Now coming to dapp share:-

What is a dapp share?

Dapp Share:-

• As you already know that a user's private key in web3auth gets split into various shares and the user needs only 2 of those shares to log in.

• Dapp share is one of those shares which is generated for a user account.

• Dapp share is generated only after the user enables MFA, so if the user has not enabled it will not be returned to dapp.

• Another point to consider is that this share is generated only for custom verifiers. You may ask why!!.

• Before answering this, I would like to clear up another "why", why is dapp share is required at all even for custom verifiers !!.

Why dapp share is required at all?

• So as I said that 2 out of n shares are required for a user to log in, one can be a social login account share and the other can be any of these but not limited to:-
  • a password
  • backup token
  • a device share.

Let's consider a login scenario:-

• User logs in to a new browser with social login + backup token.

  • On successful login in a new browser, web3auth SDK also creates a new device share to mark the device as a trusted device by user and stores it in the browser's local storage scoped to the web3auth domain.

• Now let's say, User comes back after 2 days and tries to login in same browser, now we need 2 shares from user right so how can it be achieved with out compromising the user login experience:-

  • User will do social login again. Users are happy doing it since they are used to it and we will get first share.
  • How to get the second share?
    • Happy case:- We will get the device share from local storage since this device is already marked as trusted and user will be able to log in happily.
    • Not so happy case:- Browser local storage might have cleared due to any reason. In this case following actions can be done by user or dapp:-
      - User can enter his/her second share as a previously backup share or password.
      - User can approve the share transfer from existing logged in device.
      - Dapp can provide dapp share as the second input to user's account, but wait how does dapp has a share now, ok my bad, I have not told you yet. Let's answer this next.

How does dapp get access to dapp share?

• So while storing the device share in local storage of web3auth's browser domain we also return the same share to dapp which dapp can manage and we call it dapp share. As a dapp you are not limited to but you can:-

    - store dapp share as an encrypted backup in your server.
    - store it as a backup on user's apple cloud.
    - store it in the android/ios key store if you are a mobile app.
  

Why dapp share is issued only for custom verifiers?

• Because default verifiers are shared among various applications.

• Let's say if two applications A and B are using default verifiers, then a user "x" can log in to both applications with the same shares.

• Now let's assume if would have returned dapp share for default verifiers then both applications A and B can access one common share of the user's account. In this case, if any of A or B got malicious and got access to the user's social login account or any other share then the malicious application can affect the security of rest of the applications which are using default verifiers as well. So it seems a better option to not return dapp share at all for default verifiers and hence we don't return it.

I hope this answers your question, feel free to shoot any further queries.

[hazim-j]

@himanshuchawla009 This is an excellent write up and makes a lot of sense, thanks! This should also be added as part of the official documentation imo :)

[sandys]

@himanshuchawla009 thanks for this answer. i was just searching for something like this. just a basic question about dappshares. all the dappshares are computed on the userbrowser right ? and sent to the web3auth verifier nodes ?
which means that the verifier nodes are simply storing a piece of dappshare against the login token. just wanted to check if verifiers compute a dappshare.

second question - according to https://github.com/tkey/tkey/blob/5a19a7d3c2727cb71c726e22318b1b8d783f3c83/tkeyflow.md , it seems that verifier/social login/serviceprovider is not mandatory. i can use webstorage + seedphrase + security questions as the three shares ? so that it is totally offline ?

[himanshuchawla009]

yes, dapp share is computed in browser and for second question can you create a seperate discussion , may be someone else will be able to answer your other question.

[ppoliani]

@himanshuchawla009 may I ask you a couple of question on this topic.

You mentioned this

Dapp share is generated only after the user enables MFA, so if the user has not enabled it will not be returned to dapp.

What if user does not enable MFA? How do we deal with the non happy case you described?

Not so happy case:- Browser local storage might have cleared due to any reason

My understanding is that ShareA was in the local storage which we wiped out. Then ShareB will be returned from the torus nodes. But how do we get ShareC?