Phase A — Passkey sign-in and management for existing accounts

[yahyafakhroji]

Sub-issue of datum-cloud/enhancements#738. Phase A of the passkey program.

Scope

Let existing Datum Cloud accounts (Google/GitHub today) enroll a passkey, manage
their passkeys, and sign in with one. No change to signup. Social login stays as
the fallback throughout, which is what makes this phase reversible.

What's included

• feat(identity): add read-only Passkey kind and passkey/email login providers milo-os/milo#727 — read-only Passkey kind + LastLoginProvider enum (passkey, email)
• fix(iam): grant users RBAC to list their own passkeys milo-os/milo#739 — RBAC so users can list their own passkeys
• feat: add ListPasskeys and exempt passkey-verified sessions from suspicious-login email milo-os/zitadel-provider#122 — ListPasskeys + passkey-verified sessions exempted from the suspicious-login email
• feat: read-only passkeys REST resource + passkey-added notification milo-os/zitadel-provider#124 — read-only passkeys REST resource + passkey-added notification handler
• feat: add user-passkey-added notification template email-templates#78 — user-passkey-added template
• datum-cloud/infra#3619 — staging: passwordless policy ALLOWED + Passkeys feature gate + mTLS wiring
• datum-cloud/infra#3709 — bind the passkey-added Zitadel action to the notification sidecar
• feat: passkey management, login polish, and two-step enrollment (Phase A) #102 — enrollment with naming, /id/passkeys management page (list/remove, last-method guard), sudo step-up, created-at, cross-device sign-out, login-flow rework
• feat: rebuild account security tab with real identity and passkey data cloud-portal#1370 — account security tab with real identity + passkey data
• fix(login): make passkey sign-in reachable when password is disabled #107 — make passkey sign-in reachable when password login is disabled
• feat(login): usernameless passkey sign-in #108 — usernameless passkey sign-in (hint-based fast path + discovery ceremony)

Status

Released to staging. Enrollment, management, and passkey sign-in are live and ready for team testing. See the status comment on datum-cloud/enhancements#738 for what to try.

Remaining before production

• VG-2 — hybrid transport test. Passed. Passkey created on macOS, sign-in on Android over QR/BLE works. It surfaced that a cold-browser sign-in costs two ceremonies — an identity-discovery ceremony plus the Zitadel-bound one — which on hybrid transport renders as two QR scans (or, with a credential-manager extension installed, one scan plus the extension serving the second locally). This is inherent to the usernameless workaround, not a defect: Zitadel cannot resolve a credential ID to a user (Passkey Authentication with "Autofill UI" zitadel/zitadel#8899), so identity must be discovered first. A returning browser with the passkey-hint cookie is a single ceremony. Documented in Passkey program: passwordless sign-in, management, and signup enhancements#738 (comment). Re-run after the passkey-arming work lands — the cold-path ceremony count may change.
• VG-3 — RP-ID audit of the legacy auth.prod.env.datum.net listener. Audit complete; risk accepted, not remediated. auth.datum.net is a CNAME to this host, so touching the listener or its DNS record carries production-auth risk disproportionate to the exposure. Login-v2 redirects the login flow to auth.datum.net/id before any ceremony renders, leaving only Zitadel Console self-service exposed — admins only, on an unlinked hostname, failing closed with a browser SecurityError. Mitigation: admins use auth.datum.net for Console. Revisit as a standalone redirect change, decoupled from the passkey program.
• Phase A exit review — gates the production decision.
• datum-cloud/infra#3732 — production enablement. Open draft; must not merge before the exit review.

Scope note (31.07.26): the passkey-removed notification moved to Phase B (#111).
It spans four repos, and Phase A is a release candidate under team review — limiting
the remaining Phase A surface to auth-ui and infra keeps that review stable.

Dependencies and gates

• Zitadel login-policy changes apply only on a Pulumi job re-run; console edits get clobbered. Git is the only source of truth.
• Zitadel Actions targets are manual per-instance setup — staging and production must each be configured and verified explicitly.