Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passkey Support #250

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Passkey Support #250

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
07f5281
Adds initial Passkey FLIP
JeffreyDoyle Feb 23, 2024
91b2d53
Adds FLIP number
JeffreyDoyle Feb 23, 2024
f78be35
Update 20240221-passkey.md
JeffreyDoyle Apr 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions application/20240221-passkey.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
status: draft
flip: 264
authors: [email protected], [email protected]
sponsor: [email protected]
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.
Copy link

@lmcmz lmcmz Feb 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 which includes challenge, rpId to generate a signature (part of an "Public Key Credential" see here). Under Authenticator Assertion Response Object (see here), there are authenticatorData, clientDataJSON, userHandle and signature. To reconstruct the signed message, clientDataJSON and authenticatorData are SHA256 Hashed and combined as the actual signing payload. The ClientDataJSON has a variable length of challenge 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 clientDataJSON and authenticatorData to both support the existing signature format and that of the new Passkey standard.

Here is the example code to reconstruct signed message:

Data reconstructSignedMessage(const Data& authenticatorData, const Data& clientDataJSON) {
    const auto& clientHash = Hash::sha256(clientDataJSON);
    Data message;
    append(message, authenticatorData);
    append(message, clientHash);
    return Hash::sha256(message);
}


### 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