Merge pull request #993 from w3c/resident-key-terminology-2

Replace resident key terminology as proposed in #905

index.bs

@@ -479,13 +479,15 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 :: This refers in general to the combination of the user's [=client device=], user agent, [=authenticators=], and everything gluing
     it all together.
 
-: <dfn>Client-side-resident Credential Private Key</dfn>
-:: A [=Client-side-resident Credential Private Key=] is stored either on the [=client device=], or in some cases on the
-    [=authenticator=] itself, e.g., in the case of a discrete [=first-factor roaming authenticator=]. Such <dfn>client-side credential
-    private key storage</dfn> requires an [=authenticator=] with [=local credential storage modality=] and has the property that the [=authenticator=] is able to select the [=credential private key=] given
+: <dfn>Resident Credential</dfn>
+: <dfn>Client-side-resident Public Key Credential Source</dfn>
+:: A [=Client-side-resident Public Key Credential Source=], or [=Resident Credential=] for short, is a [=public key credential
+    source=] whose [=credential private key=] is stored in the [=authenticator=], [=client=] or [=client device=]. Such
+    [=client-side=] storage requires a [=local storage capable=] [=authenticator=] and has the property that the [=authenticator=]
+    is able to select the [=credential private key=] given
     only an [=RP ID=], possibly with user assistance (e.g., by providing the user a pick list of [=public key credential|credentials=] associated with the [=RP ID=]).
     By definition, the [=credential private key=] is always exclusively controlled by the [=authenticator=]. In the case of a
-    [=Client-side-resident Credential Private Key=], the [=authenticator=] might offload storage of wrapped key material to the
+    [=resident credential=], the [=authenticator=] might offload storage of wrapped key material to the
     [=client device=], but the [=client device=] is not expected to offload the key storage to remote entities (e.g., [=[WRP]=] Server).
 
 : <dfn>Conforming User Agent</dfn>
@@ -984,7 +986,7 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
                   1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{authenticatorAttachment}}</code> is
                     [=present|present=] and its value is not equal to |authenticator|'s [=authenticator attachment modality=], [=iteration/continue=].
                   1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{requireResidentKey}}</code> is set to
-                    [TRUE] and the |authenticator| is not capable of storing a [=Client-Side-Resident Credential Private Key=],
+                    [TRUE] and the |authenticator| is not capable of storing a [=client-side-resident public key credential source=],
                     [=iteration/continue=].
                   1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{AuthenticatorSelectionCriteria/userVerification}}</code> is
                     set to {{UserVerificationRequirement/required}} and the |authenticator| is not capable of performing [=user
@@ -1829,9 +1831,9 @@ attributes.
         specified [[#attachment]].
 
     :   <dfn>requireResidentKey</dfn>
-    ::  This member describes the [=[RPS]=]' requirements regarding availability of the [=Client-side-resident Credential
-        Private Key=]. If the parameter is set to [TRUE], the authenticator MUST create a
-        [=Client-side-resident Credential Private Key=] when creating a [=public key credential=].
+    ::  This member describes the [=[RPS]=]' requirements regarding [=resident credentials=].
+        If the parameter is set to [TRUE], the authenticator MUST create a
+        [=client-side-resident public key credential source=] when creating a [=public key credential=].
 
     :   <dfn>userVerification</dfn>
     ::  This member describes the [=[RP]=]'s requirements regarding [=user verification=] for the
@@ -2533,10 +2535,10 @@ backup [=public key credential|credentials=] in case another [=authenticator=] i
 
 ### Credential Storage Modality ### {#sctn-credential-storage-modality}
 
-An [=authenticator=] can store a [=credential private key=] in one of two ways:
+An [=authenticator=] can store a [=public key credential source=] in one of two ways:
 
  1. In persistent storage embedded in the [=authenticator=], [=client=] or [=client device=], e.g., in a secure element. A
-    [=credential private key=] stored in this way is a [=client-side-resident credential private key=].
+    [=public key credential source=] stored in this way is a [=resident credential=].
 
  1. By encrypting (i.e., wrapping) the [=credential private key=] such that only this [=authenticator=] can decrypt (i.e., unwrap) it and letting the resulting
     ciphertext be the [=credential ID=] for the [=public key credential source=]. The [=credential ID=] is stored by the [=[RP]=]
@@ -2550,8 +2552,8 @@ An [=authenticator=] can store a [=credential private key=] in one of two ways:
 Which of these storage strategies an [=authenticator=] supports defines the [=authenticator=]'s <dfn>credential storage
 modality</dfn> as follows:
 
-- An [=authenticator=] has the <dfn>local credential storage modality</dfn> if it supports [=client-side-resident credential
-    private keys=]. An [=authenticator=] with [=local credential storage modality=] is also called <dfn>local storage capable</dfn>.
+- An [=authenticator=] has the <dfn>local credential storage modality</dfn> if it supports [=resident credentials=]. An
+    [=authenticator=] with [=local credential storage modality=] is also called <dfn>local storage capable</dfn>.
 
 - An [=authenticator=] has the <dfn>remote credential storage modality</dfn> if it does not have the [=local credential storage
     modality=], i.e., it only supports storing [=credential private keys=] as a ciphertext in the [=credential ID=].
@@ -2659,8 +2661,8 @@ When this operation is invoked, the [=authenticator=] MUST perform the following
             ::  return an error code equivalent to "{{NotAllowedError}}" and terminate the operation.
         </dl>
 
-1. If |requireResidentKey| is [TRUE] and the authenticator cannot store a [=Client-side-resident Credential
-    Private Key=], return an error code equivalent to "{{ConstraintError}}" and terminate the operation.
+1. If |requireResidentKey| is [TRUE] and the authenticator cannot store a [=client-side-resident public key credential source=],
+    return an error code equivalent to "{{ConstraintError}}" and terminate the operation.
 1. If |requireUserVerification| is [TRUE] and the authenticator cannot perform [=user verification=], return an error code
     equivalent to "{{ConstraintError}}" and terminate the operation.
 
@@ -2700,7 +2702,7 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
             : [=otherUI=]
             :: Any other information the authenticator chooses to include.
         </dl>
-    1. If |requireResidentKey| is [TRUE] or the authenticator chooses to create a [=Client-side-resident Credential Private Key=]:
+    1. If |requireResidentKey| is [TRUE] or the authenticator chooses to create a [=client-side-resident public key credential source=]:
         1. Let |credentialId| be a new [=credential id=].
         1. Set |credentialSource|.[=public key credential source/id=] to |credentialId|.
         1. Let |credentials| be this authenticator's [=credentials map=].
@@ -5195,7 +5197,7 @@ authentication, they are designed to be minimally identifying and not shared bet
     or a small group of [=authenticators=]. This is detailed further in [[#sec-attestation-privacy]]. A pair of malicious
     [=[RPS]=] thus cannot correlate users between their systems by tracking individual [=authenticators=].
 
-Additionally, a [=public key credential=] with a [=Client-side-resident Credential Private Key=] can optionally include a [=user
+Additionally, a [=client-side-resident public key credential source=] can optionally include a [=user
 handle=] specified by the [=[RP]=]. The [=public key credential|credential=] can then be used to both identify and
 [=authentication|authenticate=] the user. This means that a privacy-conscious [=[RP]=] can allow the user to create an account
 without a traditional username, further improving non-correlatability between [=[RPS]=].