ADR-0001: Passkey Attestation Policy
- Status: Accepted
- Date: 2026-01-26
- Author: @digiwedge/engineering
Context
IDP passkeys (WebAuthn) are being rolled out for Access Control Admin and other first-party apps. WebAuthn supports attestation statements that can prove authenticator provenance, but attestation introduces privacy concerns, inconsistent device support, and higher registration failure rates.
We need a default attestation policy that balances user experience, security, and operational support burden across consumer and enterprise tenants.
Decision
Use attestation type none as the default policy for all passkey
registrations.
Specifically:
- IDP requests
attestationType: "none"during registration by default. - The system does not require or verify attestation statements or vendor metadata at registration time.
- The system does not enforce an authenticator allowlist or AAGUID policy.
- Attestation objects and AAGUIDs (when provided by the platform) are stored for audit and future policy upgrades.
- User verification remains preferred (not required) to maximize device compatibility.
This policy is configurable via WEBAUTHN_ATTESTATION_TYPE for future opt-in
hardening, but the default remains none.
Consequences
Positive
- Broad device compatibility and lower registration friction.
- Minimal privacy exposure for users (no device identity enforcement).
- Fewer support tickets caused by attestation failures or blocked devices.
- Keeps passkeys usable for both platform and roaming authenticators.
Negative
- No hardware provenance assurance by default.
- Enterprise compliance requirements (device allowlists) are not met out of the box.
- Security posture relies more heavily on MFA and session protections.
Alternatives Considered
| Alternative | Pros | Cons | Why not chosen |
|---|---|---|---|
direct attestation for all tenants | Stronger hardware provenance | Higher failure rates; privacy concerns; vendor-specific issues | Too much friction for general rollout |
indirect attestation with metadata service | Allows vendor trust policies | Requires external metadata upkeep and extra ops | Adds operational complexity and latency |
| Per-tenant allowlist from day one | Meets enterprise compliance | Requires policy UI + support processes | Overkill for initial rollout |
Follow-ups
- Add per-tenant attestation policy flag and allowlist support (Phase 5)
- Document attestation configuration in IDP internal docs
- Add telemetry for registration failures by authenticator type