FIDO Credential Lifecycle Guide

From NIEF Wiki
Jump to navigation Jump to search

Introduction

All authenticators (mechanism by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impacts the lifecycle in many ways. For example passwords tend to expire and have to adhere to complexity requirements and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times but more complex requirements for replacing (ie. show up at the badge office, fill out some paperwork, verify your identity, have a new credential issued, etc.). The lifecycle also necessarily includes the very initial provisioning of the credential. For low assurance level services, this is often a simple online sign-up process with an email address verification and nothing more. For more secure credentialing it is often an in-person process with biometric capture and verification, like a fingerprint scan and photo taken for a driver's license.

FIDO has two primary standards/use cases known as U2F (universal second factor) and UAF (universal authentication framework). While some of the topics contained here can apply to both U2F and UAF, the focus is on UAF. Additionally, there is a FIDO2 standard that was handed over to W3C and renamed [webAuthn]. This standard is still very new, but rapid adoption by browsers hints at longterm viability. This standard consolidates UAF and U2F functionality and supports both use cases.

Issuance

FIDO UAF authenticators can be used for both high assurance and low assurance, depending on the process used to issue the credential. For a FIDO UAF mobile credential to be considered an AAL2 or AAL3 credential, it must be issued as part of a high assurance identity proofing process, IAL2 or IAL3 respectively.

Enrollment

The most direct method for establishing a higher assurance level FIDO credential on a user's mobile device is for them to have the device on them when they finish going through the identity proofing process, and the authenticator is bound during this process. This would require the user to use their phone during this process to generate a FIDO credential that is bound to the online identity created during the enrollment. While this process is effective at establishing a strong credential, it may lack resiliency do to the potential loss or replacement of the mobile device.

Redundancy

Redundant authenticators can be issued during enrollment, such as a username and password for low assurance operations, or physical tokens for higher assurance interactions. Redundancy can be costly to implement and can yield even more potential failure points if there are insufficient self-service capabilities to remedy issues. For larger systems with significant self-service capabilities, redundancy can become critically important for using those self-service capabilities. Supporting multiple authentication methods and multiple authenticators can be costly, but it can be beneficial for large providers and moderate providers hoping to reduce the cost to scale up.

Add-on

It can be useful to have processes where a user can add an additional authenticator to their user account. Add-on authenticators are constrained by the assurance level of the authenticator used to add the authenticator. When adding a FIDO UAF credential to an existing account, it would be considered AAL1 if it is added to an account via an existing username/password. This may still be a useful use case if the FIDO UAF credential can be still be used even when it's assurance level is low. An authenticator that has been added on with a low assurance authenticator can still be elevated using external processes, so for example a FIDO UAF authenticator could be added to a username/password account, and then that authenticator could be further bound at a higher AAL via an out of band verification and approval process.

Use Cases

Lost Authenticator

A common occurrence for any authenticator is the possibility of loss, and so it is critical for a provider to have clear and readily available instructions for their users on what to do in the case of their authenticator being lost. In the case of a FIDO UAF credential on a mobile device, loss would include any situation where the user no longer possesses the device (stolen, lost, replaced, etc). In the case of FIDO UAF credentials, the provider may revoke the credential on the FIDO server, but this may not be necessary depending on various factors, such as was the device stolen or not and what mechanism was used to protect the key material on the device (if a sufficiently strong biometric was used, the key may not be recoverable). The provider must make a risk based decision whether to revoke the credential of a lost device.

Reissuance

For FIDO UAF to be used at higher assurance levels, reissuance may be handled by having the user go through the initial issuance process again. If a provider issues multiple strong credentials to users, this may enable a user to use a strong back-up credential to self enroll a new FIDO device. This is not a typical use case for small providers as supporting many different authenticators can be cost prohibitive.

Expiration

There are two aspects to expiration, one is the authenticator expiring (such as a password expiring or a certificate expiring) and an online account expiring, a common occurrence do to lack of use. FIDO UAF credentials generally have no expiration issues, as it uses strong public key cryptography for the keys with expected lifetimes of the devices being shorter than the strength window of the key material. In the case of an expired account rendering a FIDO UAF credential inoperative, the user would need to go through the issuance process again to enable a new account or to re-enable their existing account. As with reissuance, this reactivation would need to happen at an appropriate assurance level process to ensure the FIDO UAF credential maintained AAL2.

Revocation

  • Mark credential as no longer valid.
  • For FIDO/ThumbSignIn this is done within the ThumbSignIn control panel.