Passkey Authentication Service  ·  View 21 of 21  ·  Assurance

Identity Flow — From Verdict to the Tenant's Own Session

Nine messages, and the two that deliberately do not exist.

Editable source SVG draw.io All views
User WebAuthn client Verdict signer Vault and HSM Relying-party backend Verification material 1. completes the assertion 2. finish ceremony 3. sign verdict 4. signature 5. verdict, 60 s, single use 6. POST /session 7. fetch key, cached 8. check nonce, assurance, audience 9. its own session cookie Identity Flow — From Verdict to the Tenant's Own Session There is no message where the platform issues a session, and none where it revokes one. Logout, session lifetime and step-up stay with the relying party. v 1.0 · owner Security & Identity Architecture · date 2026-10

Decisions

  • The platform returns a signed, short-lived, single-use verdict. It never issues a session, and there is no message in this flow where it could.
  • The verdict carries the credential used, the user-verification state, the assurance level of the path taken, and the risk signals that applied — everything a relying party needs to make its own step-up decision.
  • Verification is offline against cached material, so a platform outage does not prevent a relying party validating a verdict it already holds.
  • Logout, session lifetime, revocation and step-up stay with the relying party, which is what bounds the consequence of a compromise of this platform.

Assumptions

  • Verdict TTL 60 seconds, single use, audience-bound to one RP ID.
  • Verification material cached by relying parties for up to an hour, which bounds key-rotation effect.
  • Platform administrators authenticate through this same flow against the platform's own RP ID — it is its own first relying party.

Risks

  • A relying party that does not check the nonce, the audience or the assurance level turns a correct verdict into a replayable token. The SDK does it; the contract says it; nothing in the platform can enforce it.