• The rate limiting requirement applies to all user verification methods (other than user presence check).
• Implementing a more strict rate limiting method is allowed.
• We recommend
  1. Allowing up to 3 failed user verification attempts without any penalty and then imposing a delay of at least 30 seconds before the 4th one, increasing exponentially with each successive attempt (e.g., 1 minute before the 5th one, 2 minutes before the 6th one), or
  2. Disable the biometric user authentication and offer another factor (e.g., a different biometric modality or a PIN/Passcode if it is not already a required factor) if such an alternative method is already available after the 5th failed user verification attempt.

     Disabling the first user verification method and falling back to an alternative user verification method MAY take place at any time without imposing additional delays.

The goal of this requirement is that, for privacy reasons, the Authenticator MUST NOT leak information about the user across multiple Relying Parties by sharing a Correlation Handle.

This requirement specifically applies to KeyIDs/CredentialIDs, KeyHandles etc.

This requirement is intended to avoid third parties having physical access to an Authenticator to determine the AppIDs/RP IDs the Authenticator has been registered to - without having user consent.

This means that Authenticators that (a) persistently store the Uauth key pair inside the Authenticator boundary and (b) that implement no user verification or only implement user presence check need to provide a response that cannot be distinguished from a valid authentication response.

Such Authenticators could maintain a dedicated Uauth key pair for generating responses for unknown AppIDs / RP IDs. The corresponding public key shall never leave the Authenticator (since with knowledge of the corresponding public key the response could be distinguished from a response for a registered AppID / RP ID).

Key refresh needs to be initiated by the RP for ideal user experience. In the current protocol, there is no provision for the Authenticator to initiate key refresh.

This requirement interacts with requirements 2.3, 2.25, 5.5, 5.6.

This is a requirement that provides flexibility in satisfying other requirements. The idea is that key use limit SHOULD be established such that the other requirements cited here are fulfilled (providing the vendor the ability to restrict the number of possible key uses rather than using longer nonces or better side-channel countermeasures), and additionally provides the option for the vendor to defend the Authenticator against attacks that are not yet known.

Both cryptographic and side-channel attacks on the Authenticator can be enabled by having access to information associated with distinct cryptographic operations under the same key, so the vendor MAY elect to impose a conservative key use limit in order to defend against such attacks, especially for attacks that are not yet known and thus cannot easily be otherwise defended against.

Any limit that allows the Authenticator to fulfill the other related requirements is sufficient for compliance to the requirement set. Some examples follow:

If a vendor doesn't require any particular key use limit to satisfy additional requirements, and they are not concerned with the possibility of unknown cryptographic attack, then this limit can be simply the maximal possible uses of this key, given the hardware constraints of the Authenticator (i.e., the rate of key use that the hardware can support multiplied by the total expected lifetime of the Authenticator). In this instance, the Authenticator need not retain the number of uses of each key. For example, if a device can perform one key use per second and has an expected lifetime of 5 years, then a reported key use limit of roughly (5*365+1)*86400 (less than 2^28) would be sufficient.

If the vendor does wish to limit the number of possible key uses, but does not wish to store state associated with this data, then the vendor can limit the average key use rate such that the total number of uses of a given key throughout the expected lifetime of the Authenticator is sufficiently low. For an example, if an Authenticator vendor wishes to limit the total number of key uses of a user key to 10,000,000 (less than 2^24) and the Authenticator has a expected lifetime of 5 years, then the Authenticator MUST enforce a long term average key use rate of roughly 1 key use every 158 seconds.

If a vendor does not wish to arbitrarily limit the rate at which keys can be used, but does wish to restrict the number of possible key uses, then they can store a count of the number of times a particular key has been used, and then disable use of the key at the limit.

Some keys (e.g., the User Private Key, or the Attestation key) cannot be painlessly replaced within the FIDO protocol (this requires re-enrolling, or replacing the Authenticator, respectively), so a suitably large limit SHOULD be chosen to prevent usability problems.

FIDO Authenticators typically require a user verification before using a private key. Such manual interaction requires a minimum amount of time.