WebAuthn attestation — what the device is, not who the user is.
Attestation is how a relying party verifies the make and model of an authenticator. It does not tell you who the user is — it tells you what hardware they're using. For consumer flows, skip it. For high-assurance enterprise, it's the policy primitive that lets you require certified hardware.
Attestation formats (fmt)
| fmt | Used by | Notes |
|---|---|---|
none | Consumer flows; some Apple flows | Empty attStmt. RP cannot verify make/model. Fine for low-assurance use. |
packed | FIDO2 default; most certified hardware authenticators | Generic format from §8.2 of the WebAuthn spec. Carries alg, sig, optional x5c chain. |
tpm | Windows Hello (TPM-bound) | TPM2_Quote-style format with versionInfo, pubArea, certInfo. |
android-key | Android Keystore | Carries the Android KeyStore attestation chain, including device verifiedBootState. |
android-safetynet | Legacy Android (deprecated by Google) | JWS payload with SafetyNet result. Don't adopt for new deployments. |
fido-u2f | U2F-derived authenticators | Legacy envelope; same X.509 + ECDSA shape as classic U2F. |
apple | Apple Touch ID / Face ID anonymous | Apple-specific anonymous attestation; no AAGUID per device, but a per-cohort identity. |
apple-appattest | iOS App Attest | App-integrity rather than authenticator attestation. |
What gets signed
For packed attestation:
The attestationKey is the per-device or per-cohort key shared across many devices of the same model (privacy-preserving). The x5c chain links the attestation key to the manufacturer's root, which is in turn listed in the FIDO Metadata Service (MDS) BLOB. RPs validate the chain up to a trusted root and pin the AAGUID against MDS.
Enterprise attestation
Enterprise attestation is a CTAP2.1 capability where the authenticator returns a per-device identifier (typically a serial number) inside the attestation. Browsers won't surface this to RPs unless the user agent is configured to do so — typically by a managed-device policy.
Use case: an organisation that bought 5,000 authenticators wants to bind each registration to a specific physical device they shipped to a specific employee. Without enterprise attestation, the AAGUID tells you "this is a YubiKey 5C" but not "this is the YubiKey 5C with serial 12345". With enterprise attestation, you can.
Privacy considerations are real — enterprise attestation is a tracking primitive. Browsers gate it behind explicit policy and never expose it to consumer-context RPs.
FIDO Metadata Service (MDS) integration
MDS is the directory that maps AAGUIDs to certified authenticator metadata: vendor, model, certification level, attestation root certificates, supported algorithms, transports, and a status field that tracks revocations / known-compromised devices.
Production RPs should:
- Fetch the signed MDS BLOB from
https://mds.fidoalliance.org/on a schedule (daily is typical). - Verify the JWT signature against the FIDO Alliance MDS root.
- Cache the entries by AAGUID.
- At registration time, check the AAGUID against the cached MDS and reject if status is
USER_VERIFICATION_BYPASS,ATTESTATION_KEY_COMPROMISE, etc.
Don't fetch MDS on the registration hot path — runtime fetches couple your auth availability to the FIDO Alliance.