WebAuthn ceremonies and attestation
All AmbiSecure engineering content tagged WebAuthn, newest first. Newer entries reflect current thinking; earlier entries come from the engineering archive.
WebAuthn (Web Authentication) is the W3C browser API behind FIDO2: it lets a website register and authenticate a user with a public-key credential created and held by an authenticator. Paired with CTAP2 for external devices, it delivers phishing-resistant login because credentials are scoped to the relying-party origin and signed by a non-exportable key.
This category covers WebAuthn engineering: the registration and authentication ceremonies, attestation objects, authenticatorData and clientDataJSON, and how COSE keys and CBOR encode the credential material. The emphasis is on getting the ceremony and attestation verification right on the server side.
Frequently asked questions
What happens during a WebAuthn registration ceremony?
The relying party issues a challenge; the authenticator creates a new key pair scoped to the origin, stores the private key, and returns an attestation object containing the public key and (optionally) proof of the authenticator model.
What is authenticatorData?
authenticatorData is the signed structure the authenticator returns, carrying the relying-party ID hash, flags (user presence/verification), a signature counter, and — at registration — the new credential's public key.
How is attestation verified?
The server parses the attestation statement, checks the format and certificate chain, and confirms the authenticator meets policy — for example that it is a certified model — before trusting the credential.
What is clientDataJSON and why is it signed?
It records the challenge, the origin and the ceremony type as the browser saw them. Signing it binds the assertion to a specific site and request, which is what makes WebAuthn resistant to relay and phishing.
What is a resident or discoverable credential?
A credential stored on the authenticator itself, so it can identify the user without a username being supplied first. It is what enables a true usernameless login.