Merge pull request w3c#1695 from w3c/timcappalli-1692-backup

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,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]].
@@ -3536,7 +3561,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`).
@@ -3649,7 +3680,89 @@ 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=].
+            </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 a [=multi-device credential=] and is not yet backed up.
+            </td>
+        </tr>
+        <tr>
+            <td>`1`</td>
+            <td>`1`</td>
+            <td>
+                The credential is a [=multi-device credential=] and is backed up.
+            </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 use these [=flags=]:
+
+    - Requiring additional [=authenticators=]:
 
+        When `BE` [=flag=] is set to `0`, the credential is a [=single-device credential=] and the [=generating authenticator=] will never 
+        allow the credential to be backed up.
+
+        A [=single-device credential=] is not resilient to 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.
+
+        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 [=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. 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=].
+
 ## Authenticator Taxonomy ## {#sctn-authenticator-taxonomy}
 
 Many use cases are dependent on the capabilities of the [=authenticator=] used.
@@ -4572,6 +4685,12 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
 1. If the [=[RP]=] requires [=user verification=] 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=] (BE) 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=] (BS)
+    bit of the <code>[=flags=]</code> in |authData|, and then store the value for evaluation in future [=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>.
@@ -4739,6 +4858,9 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
 1. If the [=[RP]=] requires [=user verification=] 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=] (BS) 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>