Simplifying Passkey Implementation with Opaque Records and a Go API
Opaque, Interoperable Passkey Records (and a Go API)
I propose a new interoperable format for storing passkey records as opaque strings, similar to password hashes, to simplify server-side implementation. This approach abstracts complex WebAuthn details, allowing developers to manage credentials more easily while preserving the ability to switch libraries or backend languages. I also share a draft stateless Go API designed to streamline both registration and login flows using this standardized record format.
Don't let the attacker dictate your PRIMARY KEY and you won't have PRIMARY KEY collision attacks.
- deathanatos
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
- AppAttestationz
Wondering how webauthn extensions will fit into this.
PRF for example, takes salts as inputs, if extensions are taken into consideration then it would need to capture input & client extension results too.
- HAL3000
Having this in the Go standard library would be great. We are currently looking into implementing passkeys in our system using Go, is there any battle tested library?