diff --git a/application/20240221-passkey.md b/application/20240221-passkey.md new file mode 100644 index 00000000..089abe0e --- /dev/null +++ b/application/20240221-passkey.md @@ -0,0 +1,61 @@ +--- +status: draft +flip: 264 +authors: jeffrey.doyle@flowfoundation.org, hao.fu@flowfoundation.org +sponsor: jeffrey.doyle@flowfoundation.org +updated: 2024-02-21 +--- + +# FLIP 250: Passkey + +## Objective + +For self-custody wallets, enabling users to custody their secrets presents two flaws. 1st, users are responsible for safeguarding their secrets. This, of course, is prone to user error, where users either lose access to their secrets or they fall victim to exploit. Fortunately, devices like iPhone & Mac (like traditional hardware wallets such as Ledger) with secure enclave technology turn a user’s devices into hardware wallets, abstracting secret generation and storage to specialized hardware, greatly reducing the burden of responsibility of the user safeguarding their secrets. This solution however presents the 2nd flaw with existing user-custody mechanisms, which is that since secrets are isolated to specific device secure enclaves, portability of those secrets across a user's devices isn't possible. + +## Solution + +The Passkey standard, along with WebAuthn, exist to enable passwordless authentication for internet applications. Support for WebAuthn & Passkeys has been implemented on iOS, Android, Mac, Windows and even with password managers, such as 1Password. With passkeys, a secret that is generated on one device is made available across a user's other devices. Existing blockchain wallet providers have since taken advantage of this feature (eg: https://www.dynamic.xyz/blog/embedded-wallets-with-passkeys) which generates and stores a user’s secrets using Passkeys. Passkeys present a solution which solves the existing two flaws with self-custody wallets, in that they remove the burden of responsibility for users to safeguard their secrets, while also enabling access to those secrets across the user’s devices. + +## Design Proposal + +### Flow Protocol + +Flow Protocol, including access node API and client SDKs must be updated to support sending, receiving and verifying transactions signatures using data that conforms to the Passkey specification. Passkey signatures are performed by signing a payload ("Authenticator Data" see [here](https://www.w3.org/TR/webauthn-2/#sctn-authenticator-data)) to generate an signature (part of an "Attestation Statement" see [here](https://www.w3.org/TR/webauthn-2/#sctn-attestation-formats)), both of which are joined together to form a payload ("Attestation Object" see [here](https://www.w3.org/TR/webauthn-2/#sctn-attestation)). This payload contains both the signature ("Attestation Statement") and data used to generate the signature ("Authenticator Data"). The Authenticator Data has a variable length field ("Extension") which can be used to include the existing Flow transaction encoding. Flow SDKs and Access Node API will need to be updated to support receiving both existing transaction payloads, along with Authenticator Data and Attestation Statements to both support existing signature format and that of the new Passkey standard. + +### Flow Reference Wallet + +A new Flow Reference Wallet iFrame platform will be created, which will enable users to easily authenticate with applications without first having to install and set up a wallet application. Flow Reference Wallet iFrame (along with Flow Wallet on iOS, Android, and Chrome extension) will enable users to create new Flow accounts secured by secrets stored in Passkeys. Each platform will enable users to view and manage their Passkeys, including deleting passkeys they no longer want (while ensuring the associated Flow accounts remain secure). A Passkey used to secure an account on one platform (eg: iOS) must be accessible on other platforms (eg: Mac/IFrame). The Passkey integration will additionally support password managers, such as 1Password. + +## Drawbacks + +Passkeys require a Flow protocol update to support verification of passkey generated transaction signatures, which may impact performance and cause additional complexity. + +Signing transactions using Passkeys is done by setting the Flow transaction body as the challenge used to generate the signature used during Passkey authentication. Since the process relies on the Passkey authentication mechanic, some platforms will display variations of an authentication message (eg: "Sign In") to users when prompting the user to submit biometrics (eg: Face ID / Touch ID) to sign the transaction. This process is brief, yet may confused users as by the time they're signing a transaction with a Passkey wallet, they likely have already authenticated with that wallet or application. + +## Performance Implications + +Passkeys require a Flow protocol update to support validation of passkey generated transaction signatures, which may impact performance and cause additional complexity. + +## Dependencies + +### Flow Reference Wallet + +Flow Reference Wallet will need to support Passkeys across all platforms, iOS, Android, Chrome Extension and new iFrame platform proposed in this FLIP. + +### Flow Protocol + +Flow Protocol will need to be updated to support validating transaction signatures generated using Passkeys. + +Flow SDKs will need to be updated to support sending transactions using the new Passkey format, along with the existing transaction format. + +Flow Access Node APIs will need to be updated to support receiving transactions using the new Passkey format, along with the existing transaction format. + +## Engineering Impact + +### Flow Protocol + +Flow Protocol is now expecting just one spork this calendar year. If the passkey integration requires a protocol spork, the updates must be completed prior to the spork if Flow is to gain Passkey compatibility this year. + +## Best Practices + +Wallet developers will now have the option of using Passkeys to secure accounts on Flow. Documentation for using Passkeys oriented at wallet developers will need to be made available on Flow Reference Wallet's documentation site frw.gitbook.io