backup states in authenticator data

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: <a href="mailto:WebAuthn@ve7jtb.com">John Bradley</a> (Yubico)
 !Contributors: <a href="mailto:cbrand@google.com">Christiaan Brand</a> (Google)
+!Contributors: <a href="mailto:tim.cappalli@microsoft.com">Tim Cappalli</a> (Microsoft)
 !Contributors: <a href="mailto:agl@google.com">Adam Langley</a> (Google)
 !Contributors: <a href="mailto:mandyam@qti.qualcomm.com">Giridhar Mandyam</a> (Qualcomm)
 !Contributors: <a href="mailto:mattmil3@cisco.com">Matthew Miller</a> (Cisco)
@@ -971,6 +972,24 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     consent=] for (i.e., <em>authorizes</em>) 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=].
 
+: <dfn>Backup</dfn>
+: <dfn>Backed Up</dfn>
+:: [=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]].
+
+: <dfn>Backup Eligibility</dfn>
+: <dfn>Backup Eligible</dfn>
+:: 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 <dfn>multi-device credential</dfn> whereas one that is not [=backup eligible=] is referred to as a <dfn>single-device credential</dfn>. 
+   See also [[#sctn-credential-backup]].
+
+: <dfn>Backup State</dfn>
+:: 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]].
+
 : <dfn>Biometric Recognition</dfn>
 :: The automated recognition of individuals based on their biological and behavioral characteristics [[ISOBiometricVocabulary]].
 
@@ -1097,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=].
 
+: <dfn>Generating Authenticator</dfn>
+:: 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.
+
 : <dfn>Human Palatability</dfn>
 :: 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]].
@@ -3544,7 +3569,13 @@ laid out as shown in <a href="#table-authData">Table <span class="table-ref-foll
                 - Bit 2: [=User Verified=] ([=UV=]) result.
                     - `1` means the user is [=user verified|verified=].
                     - `0` means the user is not [=user verified|verified=].
-                - Bits 3-5: Reserved for future use (`RFU2`).
+                - Bit 3: [=Backup Eligibility=] ([=BE=].
+                    - `1` means the [=Public Key Credential Source|credential source=] is allowed to be backed up 
+                    - `0` means the [=Public Key Credential Source|credential source=] is not allowed to be backed up
+                - Bit 4: [=Backup State=] ([=BS=].
+                    - `1` means the [=Public Key Credential Source|credential source=] is currently backed up
+                    - `0` means the [=Public Key Credential Source|credential source=] is not currently backed up
+                - Bits 5: Reserved for future use (`RFU2`).
                 - Bit 6: [=Attested credential data=] included (`AT`).
                     - Indicates whether the authenticator added [=attested credential data=].
                 - Bit 7: Extension data included (`ED`).
@@ -3657,7 +3688,91 @@ This is because the first 37 bytes of the signed data in a FIDO U2F authenticati
 <code>[=authDataExtensions|extensions=]</code> are never present. FIDO U2F authentication signatures can therefore be verified by
 the same procedure as other [=assertion signatures=] generated by the [=authenticatorGetAssertion=] operation.
 
+### Credential Backup State ### {#sctn-credential-backup}
+
+Credential [=backup eligibility=] and current [=backup state=] is conveyed by the `BE` and `BS` [=flags=] in the [=authenticator data=], as 
+defined in <a href="#table-authData">Table <span class="table-ref-previous"/></a>.
+
+The value of the `BE` [=flag=] is set during [=authenticatorMakeCredential=] operation and MUST NOT change.
+
+The value of the `BS` [=flag=] may change over time based on the current state of the [=Public Key Credential Source|credential source=]. <a href="#table-backupStates">Table <span class="table-ref-following"/></a> below defines
+valid combinations and their meaning.
+
+<figure id="table-backupStates" class="table">
+    <table class="complex data longlastcol">
+            <tr>
+            <th>`BE`</th>
+            <th>`BS`</th>
+            <th>Description</th>
+        </tr>
+        <tr>
+            <td>`0`</td>
+            <td>`0`</td>
+            <td>
+                The credential is a [=single-device credential=] and cannot become a [=multi-device credential=].
+            </td>
+        </tr>
+        <tr>
+            <td>`0`</td>
+            <td>`1`</td>
+            <td>
+                This combination is not allowed.
+            </td>
+        </tr>
+        <tr>
+            <td>`1`</td>
+            <td>`0`</td>
+            <td>
+                The credential is currently a [=single-device credential=] but may become a [=multi-device credential=] in the future.
+            </td>
+        </tr>
+        <tr>
+            <td>`1`</td>
+            <td>`1`</td>
+            <td>
+                The credential is a [=multi-device credential=].
+            </td>
+        </tr>
+    </table>
+    <figcaption>
+        `BE` and `BS` [=flag=] combinations
+    </figcaption>
+</figure>
+
+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 [=[RPS]=] might utilize these [=flags=]:
+
+    - Requiring additional [=authenticators=]:
+
+        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. [=[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 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 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 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 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.
@@ -4580,6 +4695,12 @@ 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 <code>[=flags=]</code>
     in |authData| is set.
 
+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 <code>[=flags=]</code> in |authData|.
+
+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 <code>[=flags=]</code> 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
     <code>|options|.{{PublicKeyCredentialCreationOptions/pubKeyCredParams}}</code>.
@@ -4747,6 +4868,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 <code>[=flags=]</code> 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 <code>[=flags=]</code> 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 <code>[=authdataextensions|extensions=]</code> in |authData| are as expected, considering the [=client
     extension input=] values that were given in <code>|options|.{{PublicKeyCredentialRequestOptions/extensions}}</code>