Attestation and Assertion

This page is not complete.

This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

There are two different types of certificates used in WebAuthn for registration and authentication. They have similar names and similar purposes, but understanding the differences may be an initial point of confusion. The sections below describe attestation, which happens during registration, and assertion which happens during authentication.



When an authenticator registers a new key pair with a service, the authenticator signs the public key with an attestation certificate. The attestation certificate is built in to the authenticator during manufacturing time and is specific to a device model. That is all "Samsung Galaxy S8" phones have the same attestation certificate.
Different devices have different attestation formats. The pre-defined attestation formats in WebAuthn are:


  • Packed - a generic attestation format that is commonly used by devices who's sole function is as a WebAuthn authenticator, such as security keys.
  • TPM - the Trusted Platform Module (TPM) is a set of specifications from the Trusted Platform Group (TPG). This attestation format is commonly found in desktop computers and is used by Windows Hello as its preferred attestation format.
  • Android Key Attestation - one of the features added in Android O was Android Key Attestation, which enables the Android operating system to attest to keys.
  • Android SafetyNet -prior to Android Key Attestation, the only option for Android devices was to create Android SafetyNet attestations
  • FIDO U2F - security keys that implement the FIDO U2F standard use this format  
  • none - browsers may prompt users whether they want a site to be allowed to see their attestation data and / or may remove attestation data from the authenticator's response if the `attestation` parameter in `navigator.credentials.create()` is set to `none`
The purpose of attestation is to cryptographically prove that a newly generated key pair came from a specific device. This provides a root of trust for a newly generated key pair as well as being able to identify the attributes of a device being used (how the private key is protected; if / what kind of biometric is being used; whether a device has been certified; etc.).
It should be noted that while attestation provides the capability for a root of trust, validating the root of trust is frequently not necessary. When registering an authenticator for a new account, typically a Trust On First Use (TOFU) model applies; and when adding an authenticator to an existing account, a user has already been authenticated and has established a secure session.


When an user chooses to log in to log in to a service, the server sends a challenge and the authenticator signs over it with a previously registered key pair. This creates an assertion, which is returned through the WebAuthn API as the AuthenticatorAssertionResponse. Unlike the attestation, the format of the assertion is always the same regardless of the device being used. The assertion format is fairly simple as it contains three basic ArrayBuffers:


  • clientDataJSON - the same as in attestation, this is an ArrayBuffer that contains a JSON representation of what the browser saw when being asked to authenticate
  • authenticatorData - data created and / or used by the authenticator
  • signature - a signature over the clientDataJSON and authenticatorData that can be verified with the public key that was created during registration
It's important to highlight that the signature for assertion uses a different key pair than attestation. Assertion is using the key pair that was generated during registration, not the attestation certificate that burned into all models of the same device.


Document Tags and Contributors

Contributors to this page: apowers313
Last updated by: apowers313,