What is a WebAuthn attestation statement?

It is a signed object an authenticator returns during registration that lets the relying party verify the authenticator's make and model and that the new key pair was generated on genuine hardware. The format is named in the fmt field of the CBOR attestation object, with the signature and certificates in attStmt.

What is the difference between packed and fido-u2f formats?

packed is the modern, compact FIDO2 format that signs the authenticator data and client-data hash with the credential or an attestation key, supporting self, basic and ECDAA trust. fido-u2f is the legacy CTAP1/U2F format kept for backward compatibility, always using an X.509 attestation certificate.

Which attestation format do Apple devices use?

Apple platform authenticators (Face ID / Touch ID on the Secure Enclave) use the apple format, an anonymous attestation. The statement contains an X.509 certificate chaining to Apple's CA, and the nonce is embedded in a certificate extension rather than a separate signature over the client data.

When is the attestation format none?

When the relying party requests attestation conveyance of none, or the authenticator declines to provide one. The attStmt is empty and the AAGUID is zeroed. This is common and recommended for most consumer logins because attestation can be a privacy and tracking concern.

What trust models exist for attestation?

The main models are self attestation (the credential key signs itself, no separate cert), basic attestation (a shared attestation key with an X.509 cert), attestation CA / AnonCA (a per-device certificate from a privacy CA), and ECDAA (a privacy-preserving group signature, now rarely used).

WebAuthn Attestation Format Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

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.

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.