The direct answer
Accept an additional passkey assertion only through a complete supported verifier and its association with the known user, expected RP, origin and server challenge. Use the verified result only for the intended pending action context. A touch, user-verification flag or successful ceremony does not itself approve the action’s contents or commit its effect.
Choose one known-user step rather than a new login system
A fictional console prepares internal note action A-A for ticket T-A. Signed-in user U-A reviews its stored snapshot and is asked for additional authentication before the approval workflow continues. Another tab contains A-B. A green passkey message must not silently satisfy whichever action happens to be visible next.
This profile uses a previously registered credential C-A, a configured relying-party identity RP-A and one allowed origin O-A in a top-level same-origin page. Registration, discovery of an unknown user, attestation, embedded or related-origin flows, recovery and payments are excluded.
Existing audited verifier applicability, trusted credential/public-key registry and challenge lifecycle are prerequisites, not implementations supplied here. Their actual deployment evidence is unknown. Without that evidence, the positive remains conditional and no real admission is established.
Every card below is PROPOSED_UNRUN. No browser, credential, challenge, key, signature, authenticator, biometric/PIN check, session or model operation occurred.
Keep browser completion separate from server verification
The source profile is WebAuthn Level 3, W3C Recommendation dated 25 August 2026. It establishes no browser, device or verifier installation here.
The MDN Web Authentication API overview, modified 27 October 2026, describes secure-context authentication with existing credentials and separate server validation. A fulfilled browser operation is therefore not the application’s final verification result. This guide selects no browser-call or transport implementation.
Keep pending, response_received and step_up_verified distinct in the application record. Raw client flags, a credential-looking object or a frontend success animation cannot create the verified state. Maintain readable failure and unsupported-environment outcomes instead of silently dropping the additional-authentication requirement.
Review the complete assertion contract, not one signature
Section 7.2 checks the known user’s registered credential, any returned user handle, authentication type webauthn.get, encoded challenge equality, expected origin and RP-ID hash, embedding context, flags and registered-key signature. Full verification also handles credential state and extensions. This summary is not a verifier implementation or substitute checklist.
For this narrow application, the allowed credential set comes from U-A’s trusted registry. Require O-A exactly and reject excluded cross-origin/embedding cases; a familiar parent domain is insufficient. The chosen policy requires user verification. Treat UP and UV as evidence only through the complete supported verification result, never from unverified client fields.
Freeze the verifier revision, credential record and expected profile together. Unknown support or a mismatched user/credential association blocks admission; do not enroll a new key, switch protocol purpose or accept another account because an assertion is well formed.
Bind the challenge lifecycle to the intended pending record
Invent server-owned record P-A associating U-A, current session S-A, immutable A-A snapshot, challenge reference CH-A, credential/profile policy and an explicit local expiry. These are inert references, not actual challenge bytes, encodings or a database schema. The model cannot set those associations.
The specification requires trusted randomized challenges and matching returned values. Secure generation, temporary storage, expiry and coordinated one-use consumption still need a supported implementation. This article creates none. Browser timeout or tab state cannot stand in for the server’s authoritative pending disposition.
After actual verification, resolve P-A and recheck its unchanged user/session/action association and current rights before advancing the intended workflow. Reject an expired, consumed, replaced or uncertain record. Do not transfer P-A’s result to A-B, and do not repair uncertainty by marking it unused.
The useful positive records only step_up_verified for P-A. A separate supported exact-action approval and commit boundary remains necessary. This association is application design, not a transaction guarantee supplied by WebAuthn.
Walk eight inert assertion-admission cards
| Inert condition | Required decision |
|---|---|
| Expected U-A/S-A/P-A/A-A/C-A/RP-A/O-A; complete supported verification and current rights | Permit only the associated step-up state; no action execution or human-comprehension result claimed. |
| Credential belongs to another user or is absent from the allowed association | Reject substitution; a display name cannot establish ownership. |
| Challenge, ceremony purpose or pending session/action differs | Reject the crossed proof rather than adopting another login or action context. |
| Origin is unexpected or an excluded embedding context appears | Reject despite plausible RP-related data. |
| Required UV condition fails despite reported presence | No verified step-up state; presence is not a substitute for the selected verification policy. |
| P-A repeats, expires, is consumed or has unknown disposition | Consult supported state; no fresh transition from replay. |
| Counter or backup state lacks a defensible supported policy/disposition | Hold under this application profile; do not invent clone or hardware assurances. |
| Authentication succeeds but A-A changed or current approval/object rights are absent | Withhold approval and commit independently. |
Do not turn ceremony evidence into business intent
The specification permits zero counters; a non-increasing counter can signal cloning, malfunction or processing order, rather than prove a clone. Backup eligibility and state also have defined rules. Apply the full verifier and established RP policy without claiming always-increasing counters or hardware-bound credentials.
An authenticator gesture concerns the ceremony. This worksheet does not establish that U-A read the note, understood its consequence or approved changed terms. Keep the trusted review display and current authorization separate. The specification also warns about malicious code on credential origins; passkeys do not certify the page’s own code.
Record minimized case, profile and disposition references, without reusable proofs or account details. Boundary is prelaunch and does not provide this passkey, verifier or approval service. Its synthetic action evidence concerns different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.