FIDO Credential Lifecycle Guide - Revision history

Matthew.moyer at 21:06, 24 April 2019

2019-04-24T21:06:35Z

← Older revision		Revision as of 21:06, 24 April 2019
Line 1:		Line 1:
	==Introduction==		==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~~.		All authenticators (i.e., mechanisms by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impact its lifecycle in many ways. For example, passwords tend to expire, must satisfy minimum complexity requirements, and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times, but they also have more complex requirements for replacement (i.e., appear in person before the issuing official, fill out some paperwork, verify your identity, have a new credential issued, etc.) The credential lifecycle also necessarily includes the initial provisioning of the credential. For lower-assurance credentials, this is often a simple online sign-up process with an email address verification and nothing more. But for higher-assurance credentials, it is often an in-person process with biometric capture and verification, such as a fingerprint scan and/or photograph of the user.

	FIDO has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here ~~can~~ apply to both U2F and UAF, this document's focus is UAF. ~~Additionally, there is~~ a FIDO2 standard ~~that was~~ developed through W3C and is named [https://www.w3.org/TR/webauthn/ webAuthn]. This standard is still very new as of Spring 2019, but rapid adoption by browsers ~~so far~~ hints at its long-term viability. ~~This~~ standard consolidates UAF and U2F functionality and supports both use cases.		The Fast Identity Online (FIDO) 1.0 specification has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here apply to both U2F and UAF, this document's focus is UAF. Note also that a "FIDO2" standard has been developed through W3C, and is named [https://www.w3.org/TR/webauthn/ webAuthn]. This standard is still very new as of Spring 2019, but rapid adoption by browsers up to this point hints at its long-term viability. The FIDO2 standard consolidates UAF and U2F functionality and supports both use cases.

	==Issuance==		==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.		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 in accordance with [https://pages.nist.gov/800-63-3/sp800-63b.html NIST SP 800-63B], it must be issued through a high-assurance identity proofing process, e.g., in accordance with [https://pages.nist.gov/800-63-3/sp800-63a.html NIST SP 800-63A] IAL2 or IAL3, respectively.

	===Enrollment===		===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.		The most direct method for establishing a high-assurance FIDO credential on a user's mobile device is for the user to have the device present at the time when the user finishes going through the identity proofing process, so that the authenticator can be issued and bound to the device during this in-person event. This requires the user to use their phone during this process and 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 is somewhat costly, inconvenient, and unscalable. It also lacks resiliency due to the potential loss or replacement of the mobile device.

	===Redundancy===		===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~~.		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 subsequent credential management issues that may arise. 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-scale providers and moderate-scale providers hoping to reduce their scaling costs.

	===Add-on===		===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.		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 to access resources despite having a lower assurance level. An add-on authenticator with a low assurance authenticator can be elevated through external processes. 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==		==Use Cases==

	===Lost Authenticator===		===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. This may typically include a phone number or email address for the user to ~~make~~ contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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 whether the the device was stolen 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.		A common occurrence for any authenticator is the possibility of loss, 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. This may typically include a phone number or email address for the user to contact and notify an administrator. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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 (e.g, due to theft, loss or device replacement/upgrade). In such case, the provider can revoke the credential on the FIDO server, thereby assuring that the credential can never be used to authenticate. But this may not be necessary; it depends on various factors, such as whether the the device was stolen 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 as to whether to revoke a credential on a lost, stolen, or replaced device.

	===Reissuance===		===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.		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. Note that this is not a typical use case for small providers, as supporting many different authenticators can be cost-prohibitive.

	===Expiration===		===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.		There are two aspects to expiration. One is authenticator expiration (such as a password expiring or a certificate expiring) and the other is online account expiration, which is a common occurrence due to lack of use. FIDO UAF credentials generally have no expiration issues, as FIDO uses strong public key cryptography for the keys with expected lifetime of the device being shorter than the expected lifetime 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===		===Revocation===
	Revocation is a mechanism ~~by where~~ the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. ~~This would be akin to a temporary one time password replacing a user's existing password (so the old password is no longer accepted).~~ For FIDO UAF the public and private key system does not involve certificates issued by an authority so revocation does not use typical X.509 mechanics. With FIDO every public/private keypair is unique to a single credential, so revocation is handled within the FIDO UAF Server simply by deleting the credential for the user, thus forcing them to go through the registration process again thus generating a new credential at that time.		Revocation is a mechanism whereby the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. For FIDO UAF, revocation is handled within the FIDO UAF Server simply by deleting the credential for the user, thus forcing them to go through the registration process again thus generating a new credential at that time.

Matthew.moyer at 20:43, 24 April 2019

2019-04-24T20:43:23Z

← Older revision		Revision as of 20:43, 24 April 2019
Line 2:		Line 2:
	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.		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~~ [https://www.w3.org/TR/webauthn/ 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.		FIDO has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here can apply to both U2F and UAF, this document's focus is UAF. Additionally, there is a FIDO2 standard that was developed through W3C and is named [https://www.w3.org/TR/webauthn/ webAuthn]. This standard is still very new as of Spring 2019, but rapid adoption by browsers so far hints at its long-term viability. This standard consolidates UAF and U2F functionality and supports both use cases.

	==Issuance==		==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.		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===		===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.		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===		===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.		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.
Line 15:		Line 17:

	==Use Cases==		==Use Cases==

	===Lost Authenticator===		===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. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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 whether the the device was stolen 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.		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. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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 whether the the device was stolen 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.

Matthew.moyer at 20:25, 24 April 2019

2019-04-24T20:25:32Z

← Older revision		Revision as of 20:25, 24 April 2019
Line 16:		Line 16:
	==Use Cases==		==Use Cases==
	===Lost Authenticator===		===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. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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.		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. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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 whether the the device was stolen 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===		===Reissuance===

Jeff.Krug: /* Lost Authenticator */

2019-04-24T19:41:05Z

Lost Authenticator

← Older revision		Revision as of 19:41, 24 April 2019
Line 16:		Line 16:
	==Use Cases==		==Use Cases==
	===Lost Authenticator===		===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.		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. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. 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===		===Reissuance===

Jeff.Krug: /* Introduction */

2019-04-24T19:16:56Z

Introduction

← Older revision		Revision as of 19:16, 24 April 2019
Line 2:		Line 2:
	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.		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 [[https://www.w3.org/TR/webauthn/ 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.		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 [https://www.w3.org/TR/webauthn/ 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==		==Issuance==

Jeff.Krug: /* Revocation */

2019-04-24T19:15:53Z

Revocation

← Older revision		Revision as of 19:15, 24 April 2019
Line 25:		Line 25:

	===Revocation===		===Revocation===
	* Mark credential as no longer ~~valid~~.		Revocation is a mechanism by where the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. This would be akin to a temporary one time password replacing a user's existing password (so the old password is no longer accepted). For FIDO UAF the public and private key system does not involve certificates issued by an authority so revocation does not use typical X.509 mechanics. With FIDO every public/private keypair is unique to a single credential, so revocation is handled within the FIDO UAF Server simply by deleting the credential for the user, thus forcing them to go through the registration process again thus generating a new credential at that time.
	* For FIDO/~~ThumbSignIn this~~ is ~~done~~ within the ~~ThumbSignIn control panel~~.

Jeff.Krug: /* Expiration */

2019-04-24T19:11:20Z

Expiration

← Older revision		Revision as of 19:11, 24 April 2019
Line 22:		Line 22:

	===Expiration===		===Expiration===
	* Trigger reissuance before 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.
	* Credential no longer valid
	* FIDO likely not configured to ~~have~~ expiration.
	** The underlying account (online ~~identity) may~~ have expiration ~~rules independent~~ of the ~~authenticator's expiration rules though~~.
	** Does DI3 have expiration rules? ~~Inactivity leading~~ to ~~automatically disabled accounts?~~

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

Jeff.Krug: /* Redundancy */

2019-04-24T19:04:20Z

Redundancy

← Older revision		Revision as of 19:04, 24 April 2019
Line 9:		Line 9:
	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.		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===		===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.		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===		===Add-on===

Jeff.Krug: /* Reissuance */

2019-04-24T19:01:38Z

Reissuance

← Older revision		Revision as of 19:01, 24 April 2019
Line 19:		Line 19:

	===Reissuance===		===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 ~~level of self service redundant authenticators~~ is ~~viable~~ for ~~large~~ providers ~~and potentially necessary for medium providers to scale up in size, but~~ supporting many different ~~types of~~ authenticators can be ~~prohibitively expensive for smaller providers. If a smaller provider anticipates growth or is trying to grow, it is the type of thing they should plan to support~~.		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===		===Expiration===

Jeff.Krug: /* Reissuance */

2019-04-24T19:00:27Z

Reissuance

← Older revision		Revision as of 19:00, 24 April 2019
Line 19:		Line 19:

	===Reissuance===		===Reissuance===
	* Replace credential		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 level of self service redundant authenticators is viable for large providers and potentially necessary for medium providers to scale up in size, but supporting many different types of authenticators can be prohibitively expensive for smaller providers. If a smaller provider anticipates growth or is trying to grow, it is the type of thing they should plan to support.
	** Near expiration time, may reissue (for example password changes).
	** For FIDO ~~reissuing is likely not an issue, credentials would not have expiration times and backup authenticators likely not strong enough~~ to ~~allow direct enrollment.~~
	* In-person
	** Depending on availability of multiple authenticators, reissuance may ~~require in-person processes~~.
	* Necessitate new enrollment?
	** Without multiple ~~authenticators~~, may ~~necessitate~~ a new ~~enrollment (new online identity / account)~~.
	* Viable via redundant ~~credentials.~~
	** In some cases (and ~~particularly~~ for ~~lower strength~~ authenticators~~), you~~ can ~~reissue an authenticator via~~ a ~~channel established with another authenticator~~.

	===Expiration===		===Expiration===