[feature] eID wallet onboarding restructure

[sosweetham]

Description

Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

• Each user begins as an unverified user.
• The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
• The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
• From this point the user may procure other binding documents

Binding Documents

Current binding documents which we support are:

• Physical ID Documents
• Passphrase/PIN
• Photograph
• Friends

Flows to obtain Binding Documents

For Physical ID Documents

Same as the current Veriff flow.

Passphrase/PIN

During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

Photograph (only works with Veriff flow)

During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

Friend based

Allow for friends to sign binding documents tying self stated details by a user to their eName

Example

• Bob onboards using unverified flow
• Bob claims his name as Bob Smith
• Bob asks his friend Alice to sign this assertion
• Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
• Bob counter-signs this certificate proving a mutual friend relationship

Recovery Flows

Passphrase

Allow for recovery to an eVault if eName is known and the user also holds the passphrase

The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

Physical ID Document

Current implementation

Friends Based

Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

NOTE:
This approach doesn't technically guarantee that either friends or the said notary are not malicious .
This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

Acceptance Criteria

Onboarding

• eID onboarding always begins with unverified flow.
• Allow for a user to go through the KYC flow through the settings or by clicking the ePassport card
• Always create a binding document tying eName and public key via the remote CA
• Always create a self signed certificate tying self asserted personal data to the eName

Passphrase

• Always store the hash of the passphrase/PIN in a protected zone which can't be read by post-platforms
• Have the eVault expose a recover endpoint which accepts the passphrase and compares it with the hash with rate-limits and exponential back off
• Rate-limit and backoff shall be IP specific

Friend Binding Documents & Recovery

• Via the share ePassport modal allow the users to request their friends' signatures for binding documents
• Always require friend's binding documents to be counter-signed by the subject they are for.
• Create a hypothetical sandbox eNotary with permissions to override Binding Documents.