backup states in authenticator data

index.bs

@@ -32,6 +32,7 @@ Former Editor: Angelo Liao, w3cid 94342, Microsoft, [email protected]
 Former Editor: Rolf Lindemann, w3cid 84447, Nok Nok Labs, [email protected]
 !Contributors: <a href="mailto:[email protected]">John Bradley</a> (Yubico)
 !Contributors: <a href="mailto:[email protected]">Christiaan Brand</a> (Google)
+!Contributors: <a href="mailto:[email protected]">Tim Cappalli</a> (Microsoft)
 !Contributors: <a href="mailto:[email protected]">Adam Langley</a> (Google)
 !Contributors: <a href="mailto:[email protected]">Giridhar Mandyam</a> (Qualcomm)
 !Contributors: <a href="mailto:[email protected]">Matthew Miller</a> (Cisco)
@@ -971,6 +972,16 @@ 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 Eligibility</dfn>
+:: 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 <dfn>multi-device credential</dfn> whereas a credential that is not
+   eligible for backup is referred to as a <dfn>single-device credential</dfn>. Backup can occur via mechanisms including but not 
+   limited to peer-to-peer sync, cloud sync, local network sync, and manual import/export.
+
+: <dfn>Backup State</dfn>
+:: The current [=backup state=] of a <dfn>multi-device credential</dfn> as determined by the [=managing authenticator=]. This state
+   can change over time.
+
 : <dfn>Biometric Recognition</dfn>
 :: The automated recognition of individuals based on their biological and behavioral characteristics [[ISOBiometricVocabulary]].
 
@@ -3544,7 +3555,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=].
+                    - `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=].
+                    - `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 +3674,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 [=Authenticator data|authenticator data=] bits `3` and `4` as 
+defined in <a href="#table-authData">Table <span class="table-ref-following"/></a>.
+
+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=]. <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>Bit 3 value</th>
+            <th>Bit 4 value</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>
+        [=Authenticator data=] bits 3 and 4 combinations 
+    </figcaption>
+</figure>
+
+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.
@@ -4580,6 +4681,13 @@ 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 credential [=backup eligibility=] is used as part of Relying Party business logic or policy, evaluate the 
+    [=backup eligibility=] bit of the <code>[=flags=]</code> 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 <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 +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 <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>