Passkey Authentication Service  ·  View 01 of 21  ·  Context and scope

System Context

Who signs in, which trust inputs the platform consumes, and the three things it declines to own.

Editable source SVG draw.io All views
Trust inputs Authenticator platform or roaming FIDO Metadata Service signed BLOB People End user 180 M accounts Support agent tenant staff Tenant administrator Relying parties Relying-party app web and mobile Relying-party backend 40 tenants Relying-party sessions issued by the tenant Passkey Authentication Service WebAuthn, multi-tenant Downstream, and deliberately refused Authorization and entitlements the tenant's job Password storage stays with the tenant Tenant SIEM audit export Out-of-band channel tenant's provider enrols, signs in, recovers assisted recovery policy runs the ceremony signed verdict attestation, assertion daily snapshot recovery message Passkey Authentication Service — System Context External / third party Person or role Risk / gap synchronous batch event / async Audit export and the tenant's own session issuance are shown without arrows: both are the tenant's pull, not this platform's push. v 1.0 · owner Security & Identity Architecture · date 2026-10

Decisions

  • The platform authenticates and nothing else. Authorization, entitlements and the tenant's session all stay outside the boundary, which is what keeps a compromise of this platform from becoming a compromise of a tenant's data.
  • The authenticator is drawn as an external party rather than a client detail, because the only secret that matters never crosses the boundary at all.
  • The FIDO Metadata Service is an input, not a dependency: it arrives as a signed snapshot on a daily pull and the hot path never calls it.
  • The out-of-band recovery channel belongs to the tenant, so the weakest link in a passwordless account is contractually theirs and visibly so.

Deliberately refused

  • Password storage and verification — kept by the tenant for the migration window, then removed by them.
  • Authorization and entitlement decisions, which the identity-and-access-management use case covers.
  • Session issuance, logout and step-up: the platform returns a signed verdict and the relying party issues its own session.
  • Directory synchronisation and provisioning.

Assumptions

  • 180 million end-user accounts across 40 relying-party tenants, 2.3 credentials per user.
  • Audit export is a pull by the tenant's SIEM from the evidence store, not a push from the platform.
  • Every tenant has at least one configured recovery route; the platform refuses to serve production traffic for one that does not.
All views High-Level Architecture  ▶
Solution Architecture v1.0 · open source, self-hosted on Kubernetes · Security & Identity Architecture · 2026-1001-system-context