WebAuthn Attestation Format Reference

WebAuthn attestation formats

During WebAuthn registration an authenticator can return an attestation statement proving its make, model and that the key was generated in genuine hardware. The fmt field of the CBOR attestation object names the format. This reference covers every standard format, its trust model, and how a relying party verifies it.

How it works

The authenticator returns an attestation object with three parts:

{
  fmt:      "packed",            // the statement format name
  authData: <bytes>,            // RP ID hash, flags, counter, AAGUID, credential
  attStmt:  { alg, sig, x5c }   // format-specific signature + cert chain
}

The relying party hashes the client data, concatenates it with authData, and verifies sig over that data using either the credential public key (self attestation) or the attestation certificate in x5c, then walks the certificate chain to a trusted root (basic / AttCA). The AAGUID in authData identifies the authenticator model and can be matched against the FIDO Metadata Service.

The attestation formats in detail

packed. The modern standard format introduced with FIDO2. Supports three sub-cases: self attestation (the credential key signs itself), basic attestation (a shared batch attestation key with an X.509 cert), and ECDAA (a privacy-preserving group signature, now rarely implemented). packed with a certificate chain (x5c) is the typical enterprise deployment.

tpm. Used by Windows Hello and hardware TPM devices. The statement includes TPM-specific structures — certInfo (a TPMS_ATTEST structure) and pubArea (a TPMT_PUBLIC structure) — rather than a standard X.509 certificate signature. Verifying TPM attestation requires parsing these structures and validating against AIK certificates from the TPM manufacturer. This is the format you encounter in enterprise Windows environments where TPM 2.0 is mandatory.

android-key. Android hardware-backed key attestation, where the Android Keystore generates a key in a Trusted Execution Environment (TEE) or StrongBox and signs a certificate chain attesting to the key’s properties. The relying party verifies the certificate chain against Google’s Android root CAs and inspects the KeyDescription extension in the leaf certificate to confirm the key was generated in hardware.

android-safetynet. A legacy format using Google’s SafetyNet attestation API, which returns a JWS token signed by Google asserting device integrity. Largely superseded by android-key and Google Play Integrity, but still encountered in older Android authenticators. Requires verifying the JWS signature against Google’s certificates and checking the nonce claim matches a hash of the authenticator data.

fido-u2f. The original CTAP1/U2F format, kept for backward compatibility. Always uses an X.509 attestation certificate, with the signature computed over the application parameter and key handle rather than the WebAuthn client data format. Used by older security keys (U2F-era YubiKeys, for example) that do not support the newer FIDO2 packed format.

apple. Used by Face ID and Touch ID on Apple devices (iPhone, iPad, Mac). An anonymous attestation format where the certificate contains a nonce in a proprietary extension rather than a separate signature. The chain terminates at Apple’s attestation CA. The format is designed for privacy — you can verify the device is genuine Apple hardware without identifying the specific device.

none. The attStmt is empty and the AAGUID is zeroed. Appropriate for consumer sign-ins where you want passkeys without device tracking, or when the authenticator declines to provide attestation regardless of what the relying party requested.

When to use each conveyance preference

The attestationConveyance preference in the PublicKeyCredentialCreationOptions controls what the browser requests — but authenticators can always downgrade or refuse:

• none — recommended for most consumer and B2C applications. Fastest registration, no privacy risk, no cert verification overhead.
• indirect — the authenticator may provide anonymised attestation; useful when you want some information about key hardware without requiring specific models.
• direct — full attestation with a verifiable certificate chain; required for enterprise deployments where you must allow only approved authenticator models (for example, FIPS-validated security keys).
• enterprise — allows relying parties with registered enterprise credentials to receive non-anonymised attestation that can identify individual devices.

Tips and notes

• For most consumer sign-ins, request attestation none — it avoids cert verification and the privacy risk of identifying the exact device.
• packed with x5c is the common enterprise choice when you must confirm an approved authenticator model via the FIDO MDS.
• tpm attestation carries TPM-specific structures (certInfo, pubArea) and needs a TPM-aware verifier.
• Always verify the signature and the certificate path; a valid signature from an untrusted cert proves nothing about the hardware.