> The authenticator data is a CBOR structure defined in the WebAuthn Level 3 specification, is returned by the getAuthenticatorData() method of the AuthenticatorAttestationResponse
From TFA,
> The payload is the authenticator data, a CTAP2 CBOR encoding of most of the credential record fields that is already specified by WebAuthn
Both link to the same section of the WebAuthn spec, §6.1 Authenticator Data[1]. Unless I'm missing something, that section is describing a custom binary format, not a CBOR encoding of data. (Though n.b. that one of the items contained by the outer custom binary format is CBOR, but the 37(ish) byte array itself is not CBOR.)
(…and it's stuff like that that just makes all of WebAuthn so impenetrable.)
I was unclear on that as well. WebAuthn uses an extended form of the U2F format, such that if you don't use any of the new features or extensions the two are binary compatible with compatible signatures.
So the U2F bits like authenticator data are in a bespoke format using section lengths, while the newer features and extensions are CBOR.
One could translate the bespoke bits to CBOR, but care would be needed if you want to round-trip back to the bespoke format (e.g. so that attestations could be verified in the future off of the registration record.) Since CBOR isn't really as usable as say JSON as being an abstract object access API, and since CBOR is going to take up more space, I don't think this would really provide value over leaving it in the WebAuthn format for tooling to work on directly.
The article does not say it’s storing the authenticator data (in the format the webauthn spec specifies), it says it’s storing (most of) the fields in cbor. So it’s using the webauthn reference for logical purposes (the names and types of fields) not physical (the encoding).
Oooof, thank you for catching this. This is what I get for writing spec and API before the implementation (which, to be fair, is usually the right order not to lose sight of the broader picture).
Sorry for the confusion, it's indeed the §6.1 binary format. I corrected the spec and post not to claim it's CBOR.
> You know what it's called when you store a secret string in your password manager?
You keep changing your comment, but on the off chance you're still throwing shade.. Filippo probably wrote your password manager (or the code it runs, or the code your docker/kube system runs), and the decoder on the other end.
The user still needs to provide proof that they own the passkey in order to login. It's not like someone could hack the website, steal the "string" and use it to login.
From the linked spec,
> The authenticator data is a CBOR structure defined in the WebAuthn Level 3 specification, is returned by the getAuthenticatorData() method of the AuthenticatorAttestationResponse
From TFA,
> The payload is the authenticator data, a CTAP2 CBOR encoding of most of the credential record fields that is already specified by WebAuthn
Both link to the same section of the WebAuthn spec, §6.1 Authenticator Data[1]. Unless I'm missing something, that section is describing a custom binary format, not a CBOR encoding of data. (Though n.b. that one of the items contained by the outer custom binary format is CBOR, but the 37(ish) byte array itself is not CBOR.)
(…and it's stuff like that that just makes all of WebAuthn so impenetrable.)
[1]: https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data
I was unclear on that as well. WebAuthn uses an extended form of the U2F format, such that if you don't use any of the new features or extensions the two are binary compatible with compatible signatures.
So the U2F bits like authenticator data are in a bespoke format using section lengths, while the newer features and extensions are CBOR.
One could translate the bespoke bits to CBOR, but care would be needed if you want to round-trip back to the bespoke format (e.g. so that attestations could be verified in the future off of the registration record.) Since CBOR isn't really as usable as say JSON as being an abstract object access API, and since CBOR is going to take up more space, I don't think this would really provide value over leaving it in the WebAuthn format for tooling to work on directly.
The article does not say it’s storing the authenticator data (in the format the webauthn spec specifies), it says it’s storing (most of) the fields in cbor. So it’s using the webauthn reference for logical purposes (the names and types of fields) not physical (the encoding).
Oooof, thank you for catching this. This is what I get for writing spec and API before the implementation (which, to be fair, is usually the right order not to lose sight of the broader picture).
Sorry for the confusion, it's indeed the §6.1 binary format. I corrected the spec and post not to claim it's CBOR.
Ok so we are achieving interoperability by turning passkeys into strings.
You know what it's called when you store a secret string in your password manager?
A password.
> You know what it's called when you store a secret string in your password manager?
You keep changing your comment, but on the off chance you're still throwing shade.. Filippo probably wrote your password manager (or the code it runs, or the code your docker/kube system runs), and the decoder on the other end.
The user still needs to provide proof that they own the passkey in order to login. It's not like someone could hack the website, steal the "string" and use it to login.
That's his point - he's demonstrating a proposed standard that would make storing passkeys server-side almost as easy as passwords.