Passkeys and WebAuthn: Registration, Authentication and Recovery

A passkey is not merely a password stored somewhere better. In WebAuthn, a Relying Party uses the browser and an authenticator to create or exercise a public-key credential, while the server must verify ceremony state such as challenge, RP ID, origin, and the requested user-verification policy. Recovery is not a harmless exception path either: if recovery is materially weaker than the protected credential, that weaker path can redefine the account boundary. This lesson uses a deterministic local synthetic fixture only; it never touches a real credential, account, physical authenticator, or external target.

1. Start before the “Sign in with a passkey” button

The scenario is a synthetic relying party at https://login.example.test. Registration and authentication are separate ceremonies with separate server state. The main question is not whether the UI succeeded. The question is what the server issued, what came back, what the server verified, and which security assumptions remain unproven.

2. The bounded artifact

Your output is WebAuthn Registration & Recovery Record v1. Each row records Ceremony, RP ID, Origin, Challenge State, Credential ID, User Verification Policy, Server Verification Result, Recovery Path, Negative Probe, Evidence, and Residual Decision.

3. What this lesson does not prove

The fixture does not prove production security. Passkeys do not all share identical synchronization, backup, or attestation properties. A challenge helps only when trusted server state generates and verifies it. Recovery is not automatically allowed to use a materially weaker factor because it is an exception. TOTP and recovery-code design remain in the next lesson.

4. Public-key credential model

The bounded mental model keeps private credential material with the authenticator and lets the Relying Party retain public material and metadata needed for verification. The fixture does not generate or export a real private key; it models only the trust boundary.

5. Relying Party and RP ID

The RP ID participates in credential scope. The baseline uses login.example.test. Keep the server's expected RP ID separate from the full origin: the origin includes scheme and host, while the RP ID is a distinct domain-based input. The fixture rejects an intentional RP-ID mismatch.

6. Origin

The baseline origin is https://login.example.test. The fixture accepts only the expected origin. The origin_mismatch mutation demonstrates that a correct-looking credential identifier alone is not enough when the response arrives with an unexpected origin.

7. Challenge is server-side ceremony state

Registration and authentication each use a separate synthetic challenge. In this model, the challenge is server-generated, has a deadline, and cannot remain valid after use. Separate the challenge value returned by the client from the server's expected, still-valid challenge state.

8. Freshness and replay

The expired_registration_challenge probe deliberately crosses the deadline and must classify as EXPIRED_CHALLENGE_REJECTED. A separate authentication probe returns the wrong challenge and must classify as CHALLENGE_MISMATCH_REJECTED. These are deterministic mutations of synthetic data, not external attack activity.

9. Registration ceremony

The server issues synthetic options containing RP ID, expected origin, challenge, and userVerification=required. The virtual authenticator returns a synthetic credential ID plus public material. The server associates that credential with the synthetic account only when the expected ceremony inputs verify.

10. Authentication ceremony

Authentication uses a fresh challenge and a previously registered credential. The fixture verifies credential registration, expected RP ID, origin, challenge state, and required user verification. A success proves only this bounded model path.

11. User Verification

userVerification=required is an explicit Relying Party policy in this fixture. It does not mean the server receives a biometric secret. The model records only a synthetic boolean observation that the virtual authenticator satisfied the requested policy.

12. Credential ID and credential material

The credential_id is a synthetic identifier. It is not treated as a private secret, and its presence alone does not prove a valid ceremony. Verification depends on the ceremony context around it.

13. Fact, observation, and inference

expected_rp_id=login.example.test is a configuration fact. origin mismatch rejected is a fixture observation. “Therefore the real deployment is safe against every phishing scenario” is an unsupported inference. Keep these levels separate in the record.

14. Positive registration evidence

A positive registration trace shows a valid unused challenge, matching RP ID and origin, the required user-verification observation, and server registration of the synthetic credential. Merely seeing a credential ID is insufficient evidence.

15. Positive authentication evidence

A positive authentication trace shows a previously registered credential, a fresh challenge, expected RP/origin, and the requested user-verification observation. Record the result as VERIFIED_AUTHENTICATION, not as a general claim that the account is secure.

16. Negative evidence: expired challenge

Replay registration with an expired synthetic challenge. The expected classification is EXPIRED_CHALLENGE_REJECTED. Preserve the challenge state and server verification result in the evidence row.

17. Negative evidence: mismatched challenge

During authentication, return a different synthetic challenge from the one held by the server. The expected classification is CHALLENGE_MISMATCH_REJECTED. Client-supplied challenge material is not accepted without comparison to trusted server state.

18. Negative evidence: wrong origin

The origin_mismatch case changes the origin to https://evil.example.test. The fixture must return ORIGIN_MISMATCH_REJECTED. The claim is limited to enforcement of this synthetic allowlist; it does not add claims about a live browser or external target.

19. Negative evidence: wrong RP ID

The rp_id_mismatch case changes the RP ID and must return RP_ID_MISMATCH_REJECTED. Keep RP ID and origin as separate evidence fields so the two boundaries do not collapse into one shortcut.

20. Negative evidence: missing User Verification

When policy is required but the virtual authenticator observation is false, the model must return USER_VERIFICATION_REQUIRED. This classification proves only the fixture's declared policy boundary.

21. Recovery is not a free authentication bypass

The lost-device scenario adds a recovery decision. The baseline allows a backup authenticator or supervised identity proofing for controlled re-enrollment. The synthetic email_only_link shortcut is marked materially weaker and is not accepted without a separate justified risk decision.

22. Recovery and re-enrollment

Recovery restores account authority, so it participates in credential assurance. The record should state which path is allowed, what identity-proofing or backup-authenticator evidence exists, and what happens to superseded credentials. The lesson does not prescribe one universal recovery architecture.

23. Synced versus device-bound assumptions

The transfer case uses a staff portal with a device-bound credential. Do not carry the baseline's backup or synchronization assumptions into that case. Re-evaluate user verification and recovery evidence in the changed context.

24. Mutation: weaker recovery shortcut

The weak_recovery_shortcut probe selects email_only_link. The fixture must classify it as WEAK_RECOVERY_REJECTED. Record the bounded reason; do not generalize this synthetic result to every real email-assisted process without context.

25. Evidence completeness

If any of the eleven required artifact fields is missing or blank, the validator must return EVIDENCE_INCOMPLETE. A green happy path without row-level traceability is not complete evidence.

26. Run the lab

Use lab://SEC-004/SEC004-LAB1. Run static_preflight.py, then run_local_lab.py, and finally run_checks.py. Everything is synthetic; no network, real credential, or external target is required.

27. Capture baseline before mutation

Run and preserve registration and authentication baseline output first. Then apply one mutation at a time. If baseline and mutation change together, evidence attribution becomes ambiguous.

28. Build WebAuthn Registration & Recovery Record v1

Create a separate row for each ceremony or recovery decision. Server Verification Result is an observation. Residual Decision preserves what is not proved and keeps accountable judgment separate from automation.

29. Mental diagram

Main path: RP server challenge → browser/WebAuthn ceremony → virtual authenticator operation → server verification → bounded session authority. The recovery branch is separate and returns to controlled re-enrollment only through an explicit recovery gate. No edge ends in a generic “secure” state without evidence.

30. Transfer Case

Transfer Case: a synthetic staff portal protects a higher-risk role with a device-bound credential. Re-evaluate user-verification and recovery evidence without assuming the baseline credential is synchronized or backed up. Write the final bounded decision independently.

31. Final assessment standard

Completion requires tracing registration and authentication, separating challenge/origin/RP-ID/user-verification evidence, explaining at least one negative probe, rejecting or deferring an unjustified weaker recovery shortcut with bounded reasoning, and completing the changed-context decision independently.

32. Sources and freshness

The frozen source boundary contains exactly W3C-WEBAUTHN-L3, FIDO-PASSKEYS, and FIDO-PASSKEY-RECOVERY. The snapshot was recorded on 2026-09-02; the earliest review date is 2026-10-02. Query 1 runs on 2026-09-16, still inside that window. A current-primary-source check was also performed without adding a source or expanding the claim boundary.

33. Human accountability boundary

AI may suggest defensive probes after the learner states the objective or help organize synthetic observations. It may not invent unobserved evidence, turn one green ceremony into proof of general security, or replace the learner's final recovery, risk, or owner decision.