#1692 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)
@@ -3544,7 +3545,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:
+                    - `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: 
+                    - `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 +3664,86 @@ 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 values of bits 3 and 4 may change over time based on the state of the [=authenticator=]. <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.