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
Missing stored data in server #95
Comments
I'm glad you brought this up, it encapsulates something I've been musing over lately, one whether I need to think about providing additional date out of attestation verification. I've heard some one or two people that aaguid would be useful output, and now you're bringing up things like authenticator attachment. Let me take a look at that developer guide and see if that can't become the basis for returning more info from an attestation verification. |
In the guide, they are saying that:
And the utility to store attestation data is describe here |
And User Handle is very important as well because it can allow usernameless/passwordless verification so we have to store it during This should be a stable, unique identifier for the user - equivalent to a username. However due to privacy considerations it is recommended to set the user handle to a random byte array rather than a username and not using the user primary key store in the db. |
PR #97 will introduce a feature that sets a new, random 64-byte Buffer as |
Ah, I got my issues mixed up. PR #97 is targeting fixes for both this issue and #96 hence my getting all turned around. In addition to my comment above, that PR also updates |
@MasterKale thanks and can we have the |
@akanass I don't see in Yubico's docs what the "metadata" table is supposed to contain, but based on your comments I'm thinking the way I'll return metadata is either A) As for |
@MasterKale , Here the And in Yubico demo website the call to list authenticators is this one: fetch("https://demo.yubico.com/api/v1/user/5420a14a-4a0e-4a61-af56-c8fa8cb7213b/authenticator", {
"headers": {
"accept": "*/*",
"accept-language": "fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7",
"sec-fetch-dest": "empty",
"sec-fetch-mode": "cors",
"sec-fetch-site": "same-origin",
"sec-gpc": "1"
},
"referrer": "https://demo.yubico.com/webauthn/",
"referrerPolicy": "strict-origin-when-cross-origin",
"body": null,
"method": "GET",
"mode": "cors",
"credentials": "include"
}); RESPONSE {
"data":{
"authenticators":{
"webauthn":[
{
"deviceType":"yk5series",
"id":"f4b6c018-d8f9-4d3e-825f-406b76895448",
"lastUsed":"2021-01-30T15:25:39.147510+00:00",
"metadata":{"authenticator_attachment":"cross-platform"},
"name":"YubiKey 5 Series",
"registeredAt":"2021-01-30T15:25:39.147510+00:00",
"type":"webauthn"
},
{
"deviceType":"unknown",
"id":"9c5c1bfc-a845-43f0-9c4a-56770d59c4a1",
"lastUsed":"2021-01-30T15:32:07.304554+00:00",
"metadata":{"authenticator_attachment":"platform","form_factor":"pc","os_family":"macos"},
"name":"macOS computer",
"registeredAt":"2021-01-30T15:32:07.304554+00:00",
"type":"webauthn"
}
]
}
},
"status":"success"
} As we can see, at least we have |
Thank you for the example. Looking closely at that, it all appears to be metadata specifically for Yubico's Relying Party implementation. |
Going down the list of columns in that Yubico table definition:
The retrieval and storage of these values will be left up to the RP. Orchestrating all of this would be better as entries on the SimpleWebAuthn docs site, which will be work addressed in Issue #96. |
PR #97 has been merged, so I'm going to close out this ticket. |
As described in the Yubico developer Guide to backing up authenticator data,
userHandle
,metadata
, andattestation
data should be stored in the database.For the
attestation
, see my commentFor the
userHandle
, the value exists and it's theuser.id
field duringattestation generation phase
- we have to store it duringattestation verification phase
insideAuthenticatorDevice
object with others data and to do it, we have to keep it likechallenge
between both phases. see comment also.For the
metadata
, the value should be returned byMDS
but if it's not included, we should have at least this{"authenticator_attachment":"cross-platform"}
or{"authenticator_attachment":"platform"}
regarding the type of the authenticator registered. This can be very helpful to display dedicated section in the UI regarding the authenticator type.All this new values should be stored inside
AuthenticatorDevice
object and in the database as well, like this they can be used during verification process.The text was updated successfully, but these errors were encountered: