Problem Statement

The current connection mechanism (Verida Connect) relies on the Verida Wallet mobile app as well as a (currently) centralised Auth server. The Verida Wallet is also the main way for users to create a Verida identity/account in the first place.

While having some purpose, the Verida Wallet adds friction to onboard new users.

A way we are exploring is to allow users create a Verida identity/account and connect to Verida via more usual methods such as email, social login (Google, Facebook, etc.), passkeys, as well as crypto wallets (Metamask, etc.).

Web3 now has a variety of "Wallet infrastructure" providers such as Web3Auth, ThirdWeb, Privy, Reown (WalletConnect) and others. They provide roughly the same capabilities in regards to onboarding users via the methods cited above. Technically they all eventually provide a crypto wallet and signer for the application integrating them.

This crypto wallet can do what the Verida Wallet is currently doing.

The Verida Wallet uses AutoAccount but as it has the private key available, it uses it directly, given the limited scoped of its actions.

By using an alternative wallet, we obviously won't have the private key but a signer instead.

Original Assumption

The original assumption is that whatever wallet is created by the third-party wallet infrastructure, we would just use it to sign a hardcoded message and the signature would become the top level private key of the Verida Account, passed into AutoAccount. That top level private key is the same thing as the seed/private key generated in the Verida Wallet. Everytime the user would connect, they would sign the same hardcoded message to generate the top-level private key.

There is a problem with the existing Verida accounts from the Wallet though. We can't export their seed/PK and import them in Metamask & similar. Because the private key (that used to be available in the Verida Wallet and passed down the line in clear) will no longer be available. And if that Metamask is connected via the third-party and we follow the logic above (signing a hardcoded message becoming the top level private key), it will create a completely different Verida identity/account.

Rather than the original assumption described above, I wondered if we could use the wallet generated by the third-party as the actual controller of the Verida identity/account. We don't have access to the private key but we could use a Signer to sign and execute all necessary transactions necessary for the Verida protocol to operate.

But the SDK is critically relying on the private key in a few places (mostly VdaDid and DIDdocument apparently).

Ideally, using a Signer rather than the PK directly would be the best solution (and can be backward compatible for AutoAccount), so making changes to the SDK is relevant despite the effort and regression risks.

Solutions

Option 1 - No changes to the SDK

We don't make any changes to the Verida SDK. We use third-party wallet infrastructure for the user connection. Sign a hardcoded message, use it as top-level primary key for the actual Verida identity/account. We implement what the Wallet currently do in the Verida Vault web app, with little to no changes. Also no changes to the Verida SDK. The Vault web app continue to support the Verida Wallet as a connection option, but we'll have to think about a solution later.

Pros:

• Quickest
• No changes to the SDK

Cons:

• Not compatible with the current Verida identities/accounts from the Wallet. If users export their seed and import on Metamask, using it to connect with the third-party wallet infrastructure, it will create a new Verida identity/account.
• Missed opportunity to have the connected wallet (via the third-party wallet infra) as the actual controller of the Verida identity/account, instead we introduce a child/intermediate wallet account derived from the connected one.
• Using the third-party smart account capabilities (such as sponsoring fees) is not as straight forward because of that intermediate account

Option 2 - Update the SDK

We update the SDK to pass a Signer deep down where the PK is currently directly used. We use the third-party wallet infra for the user connection, get the Signer out of it, pass it to the SDK. We implement what the Wallet currently do in the Vault web app. Wallet users can export their seed and import in Metamask to connect via the third-party wallet infra, this will work straight away.

Pros:

• Compatible with the current Verida identities/accounts, by exporting/importing their seed in Metamask and connecting via theselected third-party wallet infra
• The connected account is the actual controller of the Verida Identity/Account, which has UX considerations (DID is the same as the wallet address, funding the wallet to directly be used on Verida, etc.).
• More straightforward to use the third-party's smart account capabilities
• Better security rather than moving the PK along and keeping it in classes' property
• SDK changes can be backward compatible with AutoAccount using the PK

Cons:

• Requires changes to the SDK, on critical parts of the protocol, with potential regressions

Additional Considerations

Going with a Signer allows supporting different types of wallet, including mobiles, browser extensions, via WalletConnect, etc.

During the flow of the different protocol use cases there are several occurrences when the wallet need to sign something. For users using external wallets (Metamask & similar), it means they will have a pop-up asking to sign every time.
For instance:

• When creating an account, a proof is signed and added to the DID document.
• When connecting, opening a context requires a signature of a consent message. Additionally, the protocol requests access to the storage nodes (often 3 nodes), each node sends their own challenge to sign.
• Etc.
  Is it acceptable?

Note: Only external wallets are behaving this way. In-app wallets (from social logins) can sign automatically.