-
Notifications
You must be signed in to change notification settings - Fork 23
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.
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
base: main
Are you sure you want to change the base?
Passkey Support #250
Conversation
|
||
### 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. |
There was a problem hiding this comment.
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);
}
Hi @JeffreyDoyle - This FLIP is not reflected on FLIP project tracker. Can you pls follow the process outlined in https://github.com/onflow/flips? Specifically the following would help show the FLIP on the project tracker-
Thank you! |
No description provided.