Registering a public-key credential
Registration supplies creation options and a challenge, with the browser mediating credential creation. The service validates returned data and records a public key and identifier. Later authentication uses the corresponding private key rather than repeatedly submitting an account password.
Credentials have RP ID scope, handled by client, authenticator and service checks. Receiving a credential object does not complete registration without challenge, origin, RP binding and applicable attestation validation.
References: [1]
Signature checks bind the challenge and context
Authentication checks client data and authenticator data, including operation type, challenge, expected origin and RP ID hash. The registered key verifies a signature over authenticator data and the client-data hash, rather than accepting any old correctly signed response.
User presence and user verification have distinct flags. A required verification policy checks UV. Biometric recognition occurs locally to the authenticator, with results and proofs rather than raw biometric data revealed to the relying party.
References: [1]
Device and backup properties need distinction
Authenticators can be platform-integrated or roaming, with capabilities supporting second-factor and passwordless uses. A WebAuthn interaction does not universally mean entering a fingerprint.
Level 3 distinguishes backup eligibility from current backup state and single-device from multi-device credentials. WebAuthn use alone does not prove every key is confined to one nonmigratable hardware device; guarantees depend on credential and authenticator properties and policy.
References: [1]