Passkey Authentication Service · View 09 of 21 · Structure
Decisions
- Ceremony begin and finish are the only interfaces a relying party's client touches; everything a client could get wrong is therefore in two calls.
- Verdict verification is offline by design: the relying party fetches verification material and checks a signature rather than calling back on every login.
- The management API, the console and the support-desk tooling are one surface with one authorization model, so there is no second path to a revocation.
- All three outbound dependencies are off the hot path, which is what lets each one have a named degradation in view 20's failure handling.
Assumptions
- 40 relying-party backends; per-tenant API credentials scoped to specific RP IDs with no cross-tenant read under any role.
- Verification material is cached by relying parties for up to an hour, which bounds how fast a key rotation can take effect.
Risks
- An SDK is the only thing standing between a tenant's front end and a subtly wrong origin check. The gateway re-checks server-side precisely because the SDK cannot be trusted to be current.