This requirement is general and applies to all user verification and/or user presence check caching mechanisms. It covers pinToken, pinUvAuthToken, future mechanisms, proprietary mechanisms and so on.

This requirement is general and applies to any FIDO protocol mechanisms or extensions for the relying party to request a particular timeout and for the authenticator to report the timeout in effect. This requirement applies to existing mechanisms like UserVerificationCaching, modifications to UserVerificationCaching or any future mechanisms or extensions, either standardized or proprietary.

This requirement is designed to work equally for authenticators that do user verification, biometric enrollment and credential management within the authenticator boundary as for authenticators that use External User Verification (collect PIN input outside the authenticator boundary).

To follow this requirement, an authenticator must either adhere to the base maximum timeout values, report a different value in the metadata or report a different value in FIDO protocol messages.

For operations like biometric enrollment that do not associate a relying party, timeouts are either fixed as described in the metadata or are the base values.

As of the initial writing of this requirement (January 2020), there are no metadata fields to report the time-to-start or the time-to-complete. There is only one protocol mechanism, UserVerificationCaching, and it only allows selecting and reporting time-to-complete only for UAF. Until additions are made to the metadata statements or UserVerificationCaching is defined for FIDO2 or such, all certified FIDO2 implementations must implement only the base values and there is no way for the relying party to request otherwise.

It is allowed for the authenticator to implement additional timeouts such as a lack-of-activity timeout that expires after 30 seconds of receiving no CTAP commands as long as the above requirements are still met.

These timeouts are maximums. An authenticator may use shorter timeouts. If an authenticator uses shorter timeouts it is does not need to report them to the relying party.

The purpose of the maximum time-to-start is to be sure the user can know that they are authorizing for a particular relying party and only that relying party. For example, they might verify for a transaction for First Bank. Something may go wrong with that transaction with no assertion generated for it. If there is no maximum time-to-start, many minutes later, an assertion for Second Bank might be generated without any user verification required.

The purpose of the maximum time-to-complete is to limit the time for which authentication is valid for the associated relying party. To give an example of what happens without this timeout, an attacker may come to "own" the non-authenticator part of a user's phone that was used to log in to a bank. That attacker would be able to log back into that bank for hours or days. The bank's server timeouts do not help because the attacker can just re authenticate.

The 10-minute base value for time-to-complete is for two reasons. The first is to allow biometric enrollment, which may involve a number of steps to complete. The second is to accommodate worst-case scenarios such a slow and simple authenticator working with a large number of credentials over a slow CTAP connection that might take as much as 10 minutes to complete.

The [FIDOCTAP] specification has text discussing the lifetime of getting a pinToken from the authenticator, suggesting they can be generated once at power up implying no timeouts are necessary. To pass certification, even at L1, the timeouts described here are required.

Some may consider these timeouts to be of little benefit for authenticators using External User Verification because the attacker outside the authenticator boundary can capture and replay the PIN whenever the timeout goes off to renew their authentication. While this is true, not all authenticators collect the PIN outside the authenticator boundary and it is simpler to have a uniform timeout requirement for all authenticators.

The first operation in a cached period may have no associated relying party (e.g. a biometric enrollment). It is currently allowed for subsequent authenticator operations for the same cached period to then have an associated relying party. For example, the user might initiate and complete a biometric enrollment in 5 minutes and then 4 minutes later authenticate to a relying party. There would be a user verification when the biometric enrollment started, but not necessarily for the authentication to the relying party. Similar is true when the relying party operation is first. Note that this gives a 10-minute window after the start of a biometric enrollment for an attacker controlling the platform to generate authentications for one relying party. This non-requirement allows for biometric enrollment and registration with a relying party to be performed in line / together and require only one user verification.

The CTAP specification refers to the authenticator-external identifier as the pinToken or pinUvAuthToken, a randomly generated byte string whose length is a multiple of 16 bytes. Some versions of the CTAP specification say it should be generated once on power up. For certification, this is not allowed. It must be a new identifier for each cached period.

Multiple cached periods (e.g., pinUvAuthTokens) are allowed simultaneously, but not required.

See also requirement 2.2.1 which requires the identifier be generated with a certified random number generator.

All Authenticators have a need to accept user input or provide user output except those that are Silent Authenticators [FIDOGlossary] or exclusively implement external user verification.

A Trusted Path is the means by which a user and a security functionality of the Authenticator can communicate with the necessary confidence. In other words, a Trusted Path allows users to perform functions through an assured direct interaction with the security functionality of the Authenticator. For instance, plaintext ASPs may be entered into or output from the Authenticator in an encrypted form (e.g. display text digitally signed).

This means that any user output performed under this requirement SHALL be protected from a display overlay attack.

The exception for external user verification methods is only for the user input and output. Stored / enrolled reference data (templates) and the comparison of the input to these must still be protected per requirements at the required calibration level.

• The rate limiting requirement applies to all user verification methods (other than user presence check).
• The below calibration of the rate limiting for the different levels is expressed as a formula that expresses the chance a false input is accepted in a determined time period. The chance that your UV method accepts a false input (ie, randomly guessing the correct PIN, the FAR of a fingerprint, ...) times the allowed number of attempts in that period must be smaller or equal to this chance. Because of how the formula is constructed, you can allow a certain number of tries and then block without keeping time, as long as that puts the chance below the 170/10000. Note that if you increase the time period, the allowed chance will increase too but the higher you go in levels, the smaller the chance is per time period.
• Implementing a more strict rate limiting method is allowed.
• The rate limits were set to accomodate certain mobile phone PIN settings and are considered way too lax, which is why we recommend a much higher standard below.
• 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 16th 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.