Feat: Deterministic Passkey Generation ENG-487

[HashMapsData2Value]

ℹ Overview

Introduces: https://github.com/algorandfoundation/deterministic-P256-kt

Summary: Adds the ability to set a mnemonic, generating passkeys deterministically based on the origin and user id.

In detail:

• Adds DerivedSecrets repo/db, a database made specifically to store derivedSecret keys and mnemonics. Though it is not necessary to do so, and we could instead only store the former.
• Imports the deterministic passkey library, dP256.
• With the help of derivedSecretParent key, all passkeys are generate deterministically from the userId, the
• Adds PassKeyMnemonicFragment, a dialogue that pops up and prompts the user to provide a mnemonic or. to generate a 24 word one.
• Makes it so that the Notification fragment does not get "cancelled" when the user presses elsewhere on the screen.

✅ Acceptance:

• Conventional Commits

[HashMapsData2Value]

Michael and I did a test run. Unfortunately, when you wish to use passkeys to sign into Github, there's no step where you input your email and then GitHub responds with the UserId. Instead, it just presents a "sign in with passkey" button, which when you connect your phone, will prompt it for the Credential Id. However, if you've just re-installed Liquid Auth, it will be empty, mnemonic or no, there will be no passkey Credential Id to present.

A solution is proposed as follows:

• Switch from using the UserId to using the UserHandle to deterministically generate the passkeys (and in turn, Credential Id).
• Add a "recovery/manual add" flow where you can specify 1) the UserHandle, 2) the Origin and a passkey will be created with the appropriate credential id.

This solves the problem. However, by replacing the UserId with the UserHandle we, we lose passkey continuity for a service where a user switches their UserHandle (e.g. their GitHub username) to a new one. If they try to recover Liquid Auth they will need to type in their old UserHandle to generate the passkey that is registered.

A UI solution could be as follows. If someone changes their UserHandle, the next time they do a sign in with passkeys, if we can presume that there will be a flow of information (indexed by the Credential Id) where the (new) UserHandle will be included and made available to LiquidAuth, it can check with the UserHandle stored on the phone. If it notices that the passkey was generated with the inclusion of an old UserHandle, it can flag that passkey as being "dirty" and encourage the user to create a new passkey - this one generated with the new UserHandle.

[PhearZero]

Tested against the current app and the staged refactor.

Both worked well and recovery went through as expected for third party sites