Introduce WebAuthn Client Device term

index.bs

@@ -220,12 +220,12 @@ infrastructure which allows those credentials to be used with {{CredentialsConta
 {{CredentialsContainer/get()|navigator.credentials.get()}}. The former is used during [=Registration=], and the
 latter during [=Authentication=].
 
-Broadly, compliant [=authenticators=] protect [=public key credentials=], and interact with user agents to implement the
-[=Web Authentication API=]. Some authenticators MAY run on the same computing device (e.g., smart phone, tablet, desktop PC) as
-the user agent is running on. For instance, such an authenticator might consist of a Trusted Execution Environment (TEE) applet,
-a Trusted Platform Module (TPM), or a Secure Element (SE) integrated into the computing device in conjunction with some means
-for [=user verification=], along with appropriate platform software to mediate access to these components' functionality. Other
-authenticators MAY operate autonomously from the computing device running the user agent, and be accessed over a transport such
+Broadly, compliant [=authenticators=] protect [=public key credentials=], and interact with user agents to implement the [=Web
+Authentication API=]. Some authenticators MAY run on the same [=client device=] (e.g., smart phone, tablet, desktop PC) as the
+user agent is running on. For instance, such an authenticator might consist of a Trusted Execution Environment (TEE) applet, a
+Trusted Platform Module (TPM), or a Secure Element (SE) integrated into the [=client device=] in conjunction with some means for
+[=user verification=], along with appropriate platform software to mediate access to these components' functionality. Other
+authenticators MAY operate autonomously from the [=client device=] running the user agent, and be accessed over a transport such
 as Universal Serial Bus (USB), Bluetooth Low Energy (BLE) or Near Field Communications (NFC).
 
 
@@ -268,9 +268,9 @@ scenarios. Additional scenarios, including sample code, are given later in [[#sa
 This use case scenario illustrates how a [=[RP]=] can leverage a combination of a [=roaming authenticator=] (e.g., a USB security
 key fob) and a [=platform authenticator=] (e.g., a built-in fingerprint sensor) such that the user has:
 
-  - a "primary" [=roaming authenticator=] that they use to authenticate on new-to-them devices (e.g., laptops, desktops) or on
-        such devices that lack a [=platform authenticator=], and
-  - a low-friction means to strongly re-authenticate on devices having [=platform authenticators=].
+  - a "primary" [=roaming authenticator=] that they use to authenticate on new-to-them [=client devices=] (e.g., laptops,
+    desktops) or on such [=client devices=] that lack a [=platform authenticator=], and
+  - a low-friction means to strongly re-authenticate on [=client devices=] having [=platform authenticators=].
 
 Note: This approach of registering multiple [=authenticators=] for an account is also useful in account recovery use cases.
 
@@ -430,8 +430,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 : <dfn>Authentication</dfn>
 : <dfn>Authentication Ceremony</dfn>
-:: The [=ceremony=] where a user, and the user's computing device(s) (containing at least one [=authenticator=]) work in
-    concert to cryptographically prove to a [=[RP]=] that the user controls the [=credential private key=] associated with a
+:: The [=ceremony=] where a user, and the user's [=client=] (containing at least one [=authenticator=]) work in concert to
+    cryptographically prove to a [=[RP]=] that the user controls the [=credential private key=] associated with a
     previously-registered [=public key credential=] (see [=Registration=]). Note that this includes a [=test of user presence=] or
     [=user verification=].
 
@@ -471,8 +471,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 :: See [=[WAC]=], [=Conforming User Agent=].
 
 : <dfn>Client-Side</dfn>
-:: This refers in general to the combination of the user's platform device, user agent, authenticators, and everything gluing
-    it all together.
+:: 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 platform, or in some cases on the
@@ -586,9 +586,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 : <dfn>Registration</dfn>
 : <dfn>Registration Ceremony</dfn>
-:: The [=ceremony=] where a user, a [=[RP]=], and the user's computing device(s) (containing at least one
-    [=authenticator=]) work in concert to create a [=public key credential=] and associate it with the user's [=[RP]=] account.
-    Note that this includes employing a [=test of user presence=] or [=user verification=].
+:: The [=ceremony=] where a user, a [=[RP]=], and the user's [=client=] (containing at least one [=authenticator=]) work in
+    concert to create a [=public key credential=] and associate it with the user's [=[RP]=] account.  Note that this includes
+    employing a [=test of user presence=] or [=user verification=].
 
 : <dfn>[RP]</dfn>
 :: The entity whose web application utilizes the [=Web Authentication API=] to register and authenticate users. See
@@ -662,6 +662,17 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 : <dfn>[WAC]</dfn>
 :: Also referred to herein as simply a [=client=]. See also [=Conforming User Agent=]. A [=[WAC]=] is an intermediary entity typically implemented in the user agent (in whole, or in part). Conceptually, it underlies the [=Web Authentication API=] and embodies the implementation of the {{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} and {{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} [=internal methods=]. It is responsible for both marshalling the inputs for the underlying [=authenticator operations=], and for returning the results of the latter operations to the [=Web Authentication API=]'s callers.
 
+    The [=[WAC]=] runs on, and is distinct from, a [=[WAC] Device=].
+
+: <dfn>Client Device</dfn>
+: <dfn>[WAC] Device</dfn>
+:: The hardware device on which the [=[WAC]=] runs, for example a smartphone, a laptop computer or a desktop computer. Also
+    referred to herein as the "platform" or "client platform".
+
+    The distinction between this and the [=client=] is that multiple [=clients=], i.e., browser implementations, may run on the
+    same [=client device=] and have access to the same [=authenticators=] available on that [=client device=]; and that [=platform
+    authenticators=] are bound to a [=[WAC] Device=] rather than a [=[WAC]=].
+
 
 # <dfn>Web Authentication API</dfn> # {#api}
 
@@ -1850,10 +1861,11 @@ the [=attachment modality=] of an [=authenticator=] that was used.
 
 Note: An [=attachment modality=] selection option is available only in the {{PublicKeyCredential/[[Create]](origin, options,
 sameOriginWithAncestors)}} operation. The [=[RP]=] may use it to, for example, ensure the user has a [=roaming credential=] for
-authenticating using other [=clients=]; or to specifically register a [=platform credential=] for easier reauthentication using a
-particular [=client=]. The {{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}}
-operation has no [=attachment modality=] selection option, so the [=[RP]=] should accept any of the user's registered [=public key
-credential|credentials=]. The [=client=] and user will then use whichever is available and convenient at the time.
+authenticating on another [=client device=]; or to specifically register a [=platform credential=] for easier reauthentication
+using a particular [=client=]. The {{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options,
+sameOriginWithAncestors)}} operation has no [=attachment modality=] selection option, so the [=[RP]=] should accept any of the
+user's registered [=public key credential|credentials=]. The [=client=] and user will then use whichever is available and
+convenient at the time.
 
 
 ### <dfn>Attestation Conveyance</dfn> Preference enumeration (enum <dfn enum>AttestationConveyancePreference</dfn>) ### {#attestation-convey}
@@ -2504,15 +2516,15 @@ Some [=platform authenticators=] could possibly also act as [=roaming authentica
 Bluetooth. In this case the [=client=] would identify it only as a [=roaming authenticator=], and not as a [=platform
 authenticator=].
 
-The primary use case for [=platform authenticators=] is to register a particular device as a "trusted device" available as a
-[=something you have=] [=authentication factor=] for future [=authentication=]. This gives the user the convenience benefit of not
-needing a [=roaming authenticator=] for future [=authentication ceremonies=], e.g., the user will not have to dig around in their
-pocket for their key fob or phone.
+The primary use case for [=platform authenticators=] is to register a particular [=client device=] as a "trusted device" available
+as a [=something you have=] [=authentication factor=] for future [=authentication=]. This gives the user the convenience benefit
+of not needing a [=roaming authenticator=] for future [=authentication ceremonies=], e.g., the user will not have to dig around in
+their pocket for their key fob or phone.
 
-The primary use case for [=roaming authenticators=] is for initial [=authentication=] on a new device, or on devices that are
-rarely used or do not include a [=platform authenticator=]; or when policy or preference dictates that the [=authenticator=] be
-kept separate from the [=clients=] it is used with. A [=roaming authenticator=] can also be used to hold backup [=public key
-credential|credentials=] in case another [=authenticator=] is lost.
+The primary use case for [=roaming authenticators=] is for initial [=authentication=] on a new [=client device=], or on [=client
+devices=] that are rarely used or do not include a [=platform authenticator=]; or when policy or preference dictates that the
+[=authenticator=] be kept separate from the [=clients=] it is used with. A [=roaming authenticator=] can also be used to hold
+backup [=public key credential|credentials=] in case another [=authenticator=] is lost.
 
 
 ## <dfn>Authenticator operations</dfn> ## {#authenticator-ops}