Attestation is built-in to the FIDO and WebAuthn protocols, which enables each relying party to use a cryptographically verified chain of trust from the device’s manufacturer to choose which security keys to trust, or to be more skeptical of, based on their individual needs and concerns.

By default, attestation signatures are disabled in WebAuthn. To collect attestation data you must set the PublicKeyCredentialCreationOptions.attestation parameter to the value ‘direct’ when registering a credential.

In order to enable the most flexibility and security, Yubico recommends that administrators and developers configure or build the following into their systems:

  1. Request “direct” attestation and store responses in your authentication system, but do not require it unless necessary.

    Direct attestation responses are provided only during credential registration, and allow your service to know the details (e.g. make, model, and version) of the devices being used with your service. Even if you don’t parse them now, you can store them and validate them for later use in risk-based and auditing decisions.

  2. If you need to require direct attestation, validate the signature of the attestation when it is provided, and use a deny list of authenticators you know to cause issues or to be unsafe, rather than an allow list.

    Make sure to notify people who are using authenticators that you are more skeptical of, or are disallowing, in a way that informs them why this was done if possible.

    You can find the root certificates used to sign attestations on manufacturer websites (Yubico’s is here) or in the FIDO metadata service version 3.

  3. If you need to use an allow list, validate the signature of the attestation when it is provided as listed above. Make sure to allow all, or a subset based on your criteria, of the authenticators listed in the FIDO metadata service version 3, and stay up to date with changes in the metadata service’s list.

    Specifically, we recommend you notify administrators of changes in the MDS data so they can make informed decisions about what to do if a new device is added or if one is removed. Define a policy for user impact in the event a registered authenticator has been removed or otherwise flagged as unsafe, allowing for continued access to protected accounts while providing incentive for the user to remove suspect credentials and replace them with ones tied to approved authenticators.

    Automated addition of new devices might be reasonable depending on your requirements, but we recommend against automated removal in the unlikely event there are MDS issues or errors.