passkeydemo
Loading demo account…

Reference

A glossary and a detailed, step-by-step recap of both ceremonies — for looking something up, not for reading start to finish. If you haven't yet, Mental model is the better starting point.

Glossary

Relying party (RP)
The website. Identified by its RP ID, not its origin — see RP ID and origins.
RP ID
A registrable domain (e.g. passkeydemo.com) that scopes which credentials a given origin may use.
Authenticator
Whatever holds the private key: Touch ID, Windows Hello, a security key, a phone.
Platform authenticator
Built into the device you're using right now. See Platform vs roaming.
Roaming (cross-platform) authenticator
Not tied to the current device — a USB/NFC/BLE security key, or a phone used over hybrid transport.
Passkey
A discoverable WebAuthn credential, marketed under a friendlier name. Every passkey is a WebAuthn credential; not every WebAuthn credential is a passkey (non-discoverable ones aren't usually called that).
Discoverable credential / resident key
A credential the authenticator itself can list, enabling sign-in without a typed username. See Discoverable credentials.
Conditional UI / conditional mediation
Autofill-driven passkey login — the ceremony starts on page load and surfaces via a normal-looking input field. See Conditional UI.
Attestation
A claim, signed by the authenticator's manufacturer, about what kind of device generated a credential. See Attestation.
Hybrid transport (caBLE)
The QR-code + Bluetooth-proximity mechanism behind cross-device sign-in. See Cross-device sign-in.
BE / BS flags
Backup-eligible and backup-state bits in authenticator data, describing whether (and if) a credential is synced to a backup service. See Backup flags.
clientDataJSON
The browser's own signed record of the ceremony: type, challenge, and origin — hashed and included in what the authenticator signs.
authenticatorData (authData)
A binary structure the authenticator produces: RP ID hash, flags byte (UP/UV/BE/BS/AT/ED), signature counter, and — during registration — the new credential's public key.
COSE
The key/algorithm encoding WebAuthn uses (CBOR Object Signing and Encryption) — alg: -7 means ES256, for example.
CTAP2
Client to Authenticator Protocol — how the browser actually talks to an authenticator. WebAuthn is the web-facing API; CTAP2 is underneath it.

The registration ceremony, step by step

  1. Browser asks the server to start registration.
  2. Server generates a random challenge, decides the allowed credential parameters (pubKeyCredParams, authenticatorSelection, excludeCredentials), and persists the challenge keyed to this session.
  3. Browser calls navigator.credentials.create() with those options.
  4. The authenticator generates a new key pair scoped to the RP ID, signs the challenge (via the attestation statement), and returns the new public key.
  5. Browser builds clientDataJSON (type "webauthn.create", the challenge, the origin) and sends the whole response — attestation object, clientDataJSON, transports — to the server.
  6. Server re-derives the challenge it issued, checks it matches, checks the origin and RP ID are on its allowlist, and verifies the attestation statement's signature.
  7. Only after all of that passes does the server store the new public key.

The authentication ceremony, step by step

  1. Browser asks the server to start authentication (optionally with no username, for discoverable credentials).
  2. Server generates a fresh challenge, persists it, and returns it — with a list of allowed credential IDs, or an empty list for a discoverable/conditional flow.
  3. Browser calls navigator.credentials.get().
  4. The authenticator finds a matching credential (by RP ID, and by credential ID if one was specified), signs over authenticatorData ‖ SHA-256(clientDataJSON) with the existing private key, and returns the assertion.
  5. Server looks up the stored public key for the credential ID in the assertion (this is also how a discoverable login resolves who is signing in), re-derives the signed byte string, and verifies the signature against that stored public key.
  6. Server checks the signature counter hasn't gone backwards (one signal a credential may have been cloned), then considers the visitor signed in.

Further reading