From 0c740551dcdb60b91f63e4132b88c6c28d7e9cc7 Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Tue, 8 Feb 2022 16:31:44 +0000 Subject: [PATCH 1/9] #1692 backup states in authenticator data --- index.bs | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 87 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 06bcd0af9..e005beb53 100644 --- a/index.bs +++ b/index.bs @@ -32,6 +32,7 @@ Former Editor: Angelo Liao, w3cid 94342, Microsoft, huliao@microsoft.com Former Editor: Rolf Lindemann, w3cid 84447, Nok Nok Labs, rolf@noknok.com !Contributors: John Bradley (Yubico) !Contributors: Christiaan Brand (Google) +!Contributors: Tim Cappalli (Microsoft) !Contributors: Adam Langley (Google) !Contributors: Giridhar Mandyam (Qualcomm) !Contributors: Matthew Miller (Cisco) @@ -3544,7 +3545,13 @@ laid out as shown in Table Table . + +The values of bits 3 and 4 may change over time based on the state of the [=authenticator=]. Table below defines +valid combinations and their meaning. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit 3 valueBit 4 valueDescription
`0``0` + The credential is a single-device credential and cannot become a multi-device credential +
`0``1` + This combination is not allowed +
`1``0` + The credential is currently a single-device credential but may become a multi-device credential in the future +
`1``1` + The credential is a multi-device credential +
+
+ [=Authenticator data=] bits 3 and 4 combinations +
+
+ +It is recommmended that [=Relying Party|Relying Parties=] store the last value of these bits with the user account for future evaluation. + +The following is a non-normative, non-exhaustive list of how [=Relying Party|Relying Parties=] may utilize these bits: + + - Requiring additional [=authenticators=]: + When bit 3 is set to `0`, the [=authenticator=] will never allow the credential to transition from a single-device credential to + a multi-device credential. + + A single-device credential is not durable and cannot survive single device loss. [=Relying Party|Relying Parties=] + should ensure that an account has additional [=authenticators=] enrolled and/or an account recovery process in place. + + For example, the user could be prompted to set up a single-device credential on a [=roaming authenticator=], like a + security key, or another [=authenticator=] that is capable of holding multi-device credentials. + + - Upgrading a user to a password-free account: + When bit 4 changes from `0` to `1`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] + is durable (it has been backed up and is protected from single device loss). This is often referred to as a multi-device credential. + + A [=Relying Party=] may decide to prompt the user to upgrade their account security and remove their password. + + - Adding an additional factor after a state change: + When bit 4 changes from `1` to `0`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] + is no longer durable (not backed up and is not protected from single device loss). This could be the result of the user deleting the + credential, deleting a backup account, an issue with the backup service, or another undefined error condition. + + When this transition occurs, the credential is no longer durable and a [=Relying Party=] should guide the user through a process to + validate their other sign in factors. If the user does not have another durable credential for their account, they should be guided + through adding an additional authentication factor to ensure they do not lose access to their account. An example would be prompting + the user to set up a single-device credential on a [=roaming authenticator=], like a security key, or another [=authenticator=] that + is capable of holding multi-device credentials. + ## Authenticator Taxonomy ## {#sctn-authenticator-taxonomy} Many use cases are dependent on the capabilities of the [=authenticator=] used. From aa68aba8b656ca9bb1595f9b24408410949ff945 Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Tue, 8 Feb 2022 19:59:27 +0000 Subject: [PATCH 2/9] Bit 3 MUST NOT change and formatting fixes in list --- index.bs | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index e005beb53..338fc6633 100644 --- a/index.bs +++ b/index.bs @@ -3669,7 +3669,9 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti Credential backup eligibility and current backup state is conveyed by [=Authenticator data|authenticator data=] bits `3` and `4` as defined in Table . -The values of bits 3 and 4 may change over time based on the state of the [=authenticator=]. Table below defines +The value of bit 3 is set during [=authenticatorMakeCredential=] operation and MUST NOT change. + +The value of bit 4 may change over time based on the current state of the [=Public Key Credential Source|credential source=]. Table below defines valid combinations and their meaning.
@@ -3718,6 +3720,7 @@ It is recommmended that [=Relying Party|Relying Parties=] store the last value o The following is a non-normative, non-exhaustive list of how [=Relying Party|Relying Parties=] may utilize these bits: - Requiring additional [=authenticators=]: + When bit 3 is set to `0`, the [=authenticator=] will never allow the credential to transition from a single-device credential to a multi-device credential. @@ -3728,12 +3731,14 @@ The following is a non-normative, non-exhaustive list of how [=Relying Party|Rel security key, or another [=authenticator=] that is capable of holding multi-device credentials. - Upgrading a user to a password-free account: + When bit 4 changes from `0` to `1`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] is durable (it has been backed up and is protected from single device loss). This is often referred to as a multi-device credential. A [=Relying Party=] may decide to prompt the user to upgrade their account security and remove their password. - Adding an additional factor after a state change: + When bit 4 changes from `1` to `0`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] is no longer durable (not backed up and is not protected from single device loss). This could be the result of the user deleting the credential, deleting a backup account, an issue with the backup service, or another undefined error condition. From e796fae0690435ff1f5c976ac473b7abe668cbf2 Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Wed, 9 Mar 2022 13:46:35 +0000 Subject: [PATCH 3/9] definitions for backup eligibility and state --- index.bs | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/index.bs b/index.bs index 338fc6633..c010814cb 100644 --- a/index.bs +++ b/index.bs @@ -972,6 +972,16 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S consent=] for (i.e., authorizes) a [=ceremony=] to proceed. This MAY involve [=user verification=] if the employed [=authenticator=] is capable, or it MAY involve a simple [=test of user presence=]. +: Backup Eligibility +:: The [=managing authenticator=] controls whether a [=Public Key Credential Source|credential source=] is allowed to be backed up. + A credential that is eligible for backup is referred to as a multi-device credential whereas a credential that is not + eligible for backup is referred to as a single-device credential. Backup can occur via mechanisms including but not + limited to peer-to-peer sync, cloud sync, local network sync, and manual import/export. + +: Backup State +:: The current [=backup state=] of a multi-device credential as determined by the [=managing authenticator=]. This state + can change over time. + : Biometric Recognition :: The automated recognition of individuals based on their biological and behavioral characteristics [[ISOBiometricVocabulary]]. From 41380b637e057a5f837291f45a1cbe57abf7d1be Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Wed, 9 Mar 2022 14:59:42 +0000 Subject: [PATCH 4/9] reference new definitions in authData bit mapping table --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index c010814cb..341803fe5 100644 --- a/index.bs +++ b/index.bs @@ -3555,10 +3555,10 @@ laid out as shown in Table |options|.{{PublicKeyCredentialCreationOptions/pubKeyCredParams}}. @@ -4848,6 +4855,9 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o 1. If [=user verification=] is required for this assertion, verify that the [=User Verified=] bit of the [=flags=] in |authData| is set. +1. If the credential [=backup state=] is used as part of Relying Party business logic or policy, compare the previously stored + value with the [=backup state=] bit of the [=flags=] in |authData|, perform evaluation, and then store the new value. + 1. Verify that the values of the [=client extension outputs=] in |clientExtensionResults| and the [=authenticator extension outputs=] in the [=authdataextensions|extensions=] in |authData| are as expected, considering the [=client extension input=] values that were given in |options|.{{PublicKeyCredentialRequestOptions/extensions}} From 8bfe78a94972878b831f242620db0173fdf8485f Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Tue, 5 Apr 2022 20:11:06 +0000 Subject: [PATCH 6/9] Incorporated @emlum and @equalsJeffH feedback --- index.bs | 87 ++++++++++++++++++++++++++++++++------------------------ 1 file changed, 50 insertions(+), 37 deletions(-) diff --git a/index.bs b/index.bs index 78a39be8f..f022cf38b 100644 --- a/index.bs +++ b/index.bs @@ -972,15 +972,23 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S consent=] for (i.e., authorizes) a [=ceremony=] to proceed. This MAY involve [=user verification=] if the employed [=authenticator=] is capable, or it MAY involve a simple [=test of user presence=]. +: Backup +: Backed Up +:: [=Public Key Credential Sources=] may be [=backed up=] in some fashion such that they may become present on an authenticator other + than their [=generating authenticator=]. [=Backup=] can occur via mechanisms including but not limited to peer-to-peer sync, + cloud sync, local network sync, and manual import/export. See also [[#sctn-credential-backup]]. + : Backup Eligibility -:: The [=managing authenticator=] controls whether a [=Public Key Credential Source|credential source=] is allowed to be backed up. - A credential that is eligible for backup is referred to as a multi-device credential whereas a credential that is not - eligible for backup is referred to as a single-device credential. Backup can occur via mechanisms including but not - limited to peer-to-peer sync, cloud sync, local network sync, and manual import/export. +: Backup Eligible +:: A [=Public Key Credential Source=]'s [=generating authenticator=] determines at creation time whether the [=public key credential source=] + is allowed to be [=backed up=]. [=Backup eligibility=] is signaled in [=authenticator data=]'s [=flags=] along with the current [=backup state=]. + [=Backup eligibility=] is a [=credential property=] and is permanent for a given [=public key credential source=].A [=backup eligible=] [=public key credential source=] + is referred to as a multi-device credential whereas one that is not [=backup eligible=] is referred to as a single-device credential. + See also [[#sctn-credential-backup]]. : Backup State -:: The current [=backup state=] of a multi-device credential as determined by the [=managing authenticator=]. This state - can change over time. +:: The current [=backup state=] of a [=multi-device credential=] as determined by the current [=managing authenticator=]. [=Backup state=] is + signaled in [=authenticator data=]'s [=flags=] and can change over time. See also [=backup eligibility=] and [[#sctn-credential-backup]]. : Biometric Recognition :: The automated recognition of individuals based on their biological and behavioral characteristics [[ISOBiometricVocabulary]]. @@ -1108,6 +1116,12 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S :: A [=credential property=] is some characteristic property of a [=public key credential source=], such as whether it is a [=client-side discoverable credential=] or a [=server-side credential=]. +: Generating Authenticator +:: The [=Generating Authenticator=] is the authenticator involved in the [=authenticatorMakeCredential=] operation resulting + in the creation of a given [=pubic key credential source=]. The [=generating authenticator=] is the same as the [=managing authenticator=] + for [=single-device credentials=]. For [=multi-device credentials=], the [=generating authenticator=] may or may not be the same as the + current [=managing authenticator=] participating in a given [=authentication=] operation. + : Human Palatability :: An identifier that is [=human palatability|human-palatable=] is intended to be rememberable and reproducible by typical human users, in contrast to identifiers that are, for example, randomly generated sequences of bits [[EduPersonObjectClassSpec]]. @@ -3555,10 +3569,10 @@ laid out as shown in Table Table . +Credential [=backup eligibility=] and current [=backup state=] is conveyed by the `BE` and `BS` [=flags=] in the [=authenticator data=], as +defined in Table . -The value of bit 3 is set during [=authenticatorMakeCredential=] operation and MUST NOT change. +The value of the `BE` [=flag=] is set during [=authenticatorMakeCredential=] operation and MUST NOT change. -The value of bit 4 may change over time based on the current state of the [=Public Key Credential Source|credential source=]. Table below defines +The value of the `BS` [=flag=] may change over time based on the current state of the [=Public Key Credential Source|credential source=]. Table below defines valid combinations and their meaning.
- - + +
Bit 3 valueBit 4 value`BE``BS` Description
`0` `0` - The credential is a single-device credential and cannot become a multi-device credential + The credential is a [=single-device credential=] and cannot become a [=multi-device credential=].
`0` `1` - This combination is not allowed + This combination is not allowed.
`1` `0` - The credential is currently a single-device credential but may become a multi-device credential in the future + The credential is currently a [=single-device credential=] but may become a [=multi-device credential=] in the future.
`1` `1` - The credential is a multi-device credential + The credential is a [=multi-device credential=].
- [=Authenticator data=] bits 3 and 4 combinations + `BE` and `BS` [=flag=] combinations
-It is recommmended that [=Relying Party|Relying Parties=] store the last value of these bits with the user account for future evaluation. +It is RECOMMENDED that [=[RPS]=] store the most recent value of these [=flags=] with the [=user account=] for future evaluation. -The following is a non-normative, non-exhaustive list of how [=Relying Party|Relying Parties=] may utilize these bits: +The following is a non-normative, non-exhaustive list of how [=[RPS]=] might utilize these [=flags=]: - Requiring additional [=authenticators=]: - When bit 3 is set to `0`, the [=authenticator=] will never allow the credential to transition from a single-device credential to - a multi-device credential. + When `BE` [=flag=] is set to `0`, the [=generating authenticator=] will never allow the credential to transition from a + [=single-device credential=] to a [=multi-device credential=]. - A single-device credential is not durable and cannot survive single device loss. [=Relying Party|Relying Parties=] - should ensure that an account has additional [=authenticators=] enrolled and/or an account recovery process in place. + A [=single-device credential=] is not durable and cannot survive single device loss. [=[RPS]=] should ensure that a [=user account=] + has additional [=authenticators=] [=registration ceremony|registered=] and/or an account recovery process in place. - For example, the user could be prompted to set up a single-device credential on a [=roaming authenticator=], like a - security key, or another [=authenticator=] that is capable of holding multi-device credentials. + For example, the user could be prompted to set up an additional [=authenticator=], such as a [=roaming authenticator=] or an + [=authenticator=] that is capable of [=multi-device credentials=]. - Upgrading a user to a password-free account: - When bit 4 changes from `0` to `1`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] - is durable (it has been backed up and is protected from single device loss). This is often referred to as a multi-device credential. + When the `BS` [=flag=] changes from `0` to `1`, the [=authenticator=] is signaling that the [=credential=] is backed up and is protected from single device loss. + This is often referred to as a [=multi-device credential=] A [=Relying Party=] may decide to prompt the user to upgrade their account security and remove their password. - Adding an additional factor after a state change: - When bit 4 changes from `1` to `0`, the [=authenticator=] is signaling that the [=Public Key Credential Source|credential source=] - is no longer durable (not backed up and is not protected from single device loss). This could be the result of the user deleting the - credential, deleting a backup account, an issue with the backup service, or another undefined error condition. + When the `BS` [=flag=] changes from `1` to `0`, the [=authenticator=] is signaling that the [=credential=] is no longer backed up, + and no longer protected from single device loss. This could be the result of the user actions, such as disabling the backup service, + or errors, such as issues with the backup service. When this transition occurs, the credential is no longer durable and a [=Relying Party=] should guide the user through a process to - validate their other sign in factors. If the user does not have another durable credential for their account, they should be guided + validate their other sign in factors. If the user does not have another credential for their account, they should be guided through adding an additional authentication factor to ensure they do not lose access to their account. An example would be prompting the user to set up a single-device credential on a [=roaming authenticator=], like a security key, or another [=authenticator=] that is capable of holding multi-device credentials. @@ -4681,12 +4695,11 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo 1. If [=user verification=] is required for this registration, verify that the [=User Verified=] bit of the [=flags=] in |authData| is set. -1. If the credential [=backup eligibility=] is used as part of Relying Party business logic or policy, evaluate the +1. If the [=[RP]=] uses the credential's [=backup eligibility=] to inform its user experience flows and/or policies, evaluate the [=backup eligibility=] bit of the [=flags=] in |authData|. -1. If the credential [=backup state=] is used as part of Relying Party business logic or policy, evaluate the [=backup state=] - bit of the [=flags=] in |authData|, and then store the value for evaluation in future - [=authentication ceremony|authentication ceremonies=]. +1. If the [=[RP]=] uses the credential's [=backup state=] to inform its user experience flows and/or policies, evaluate the [=backup state=] + bit of the [=flags=] in |authData|, and then store the value for evaluation in future [=authentication ceremony|authentication ceremonies=]. 1. Verify that the "alg" parameter in the [=credentialPublicKey|credential public key=] in |authData| matches the {{PublicKeyCredentialParameters/alg}} attribute of one of the [=list/items=] in From 2ccd99b577bc348a66e6530b73e5d96d333fbf5a Mon Sep 17 00:00:00 2001 From: Tim Cappalli Date: Mon, 11 Apr 2022 13:17:23 +0000 Subject: [PATCH 7/9] incorporated most of emlun's 2022-04-08 feedback --- index.bs | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/index.bs b/index.bs index f022cf38b..43c8df48c 100644 --- a/index.bs +++ b/index.bs @@ -982,9 +982,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S : Backup Eligible :: A [=Public Key Credential Source=]'s [=generating authenticator=] determines at creation time whether the [=public key credential source=] is allowed to be [=backed up=]. [=Backup eligibility=] is signaled in [=authenticator data=]'s [=flags=] along with the current [=backup state=]. - [=Backup eligibility=] is a [=credential property=] and is permanent for a given [=public key credential source=].A [=backup eligible=] [=public key credential source=] - is referred to as a multi-device credential whereas one that is not [=backup eligible=] is referred to as a single-device credential. - See also [[#sctn-credential-backup]]. + [=Backup eligibility=] is a [=credential property=] and is permanent for a given [=public key credential source=]. + A [=backup eligible=] [=public key credential source=] is referred to as a multi-device credential whereas one that is not + [=backup eligible=] is referred to as a single-device credential. See also [[#sctn-credential-backup]]. : Backup State :: The current [=backup state=] of a [=multi-device credential=] as determined by the current [=managing authenticator=]. [=Backup state=] is @@ -3569,10 +3569,10 @@ laid out as shown in Table