do not use 'synced' user cred term per TimC

index.bs

@@ -6088,7 +6088,7 @@ If the [=client device=] is incapable of generating a [=hardware-bound device ke
 
 The [=hardware-bound device key pair=] is not on its own a [=user credential=] and does not have its own [=credential ID=]. Instead, the returned [=device public key=] is a device-specific contextual attribute of its associated [=user credential=]. That is, when that [=user credential=] is used—along with the [=devicePubKey=] extension—on a particular [=client device=], a particular [=device public key=] is returned by the extension.
 
-Issue(1665): TODO: explicitly add the notion of "synced user credentials" to the spec.
+Issue(1665): TODO: explicitly add the notion of "Synced/multi-device user Credentials" to the spec.
 
 
 ### Relying Party Usage ### {#sctn-device-publickey-extension-usage}
@@ -6097,11 +6097,11 @@ This extension is intended for use by those [=[RPS]=] employing risk-analysis sy
 
 A new [=device public key=] is returned to the [=[RP]=] (along with a new [=credential=]) when the `devicePubKey` extension is used with a {{CredentialsContainer/create()|navigator.credentials.create()}} call. The same [=device public key=] is returned to the [=[RP]=] along with [=assertions=] generated using the latter credential&mdash;i.e., via {{CredentialsContainer/get()|navigator.credentials.get()}} calls&mdash;if those {{CredentialsContainer/get()|get()}} calls occur on the <i>same device</i> as the {{CredentialsContainer/create()|create()}} call that created the credential.
 
-However, when a user's credential is synced to a different device, the [=[RP]=] will receive a new [=device public key=] on the initial {{CredentialsContainer/get()|navigator.credentials.get()}} invocation on the other device. Note that a synced credential will be exercised for authentication on a different device without a {{CredentialsContainer/create()|navigator.credentials.create()}} having been performed on that new device.
+However, when a user's credential is copied or moved to a different device, the [=[RP]=] will receive a new [=device public key=] on the initial {{CredentialsContainer/get()|navigator.credentials.get()}} invocation on the other device. Note that a multi-device credential will be exercised for authentication on a different device without a {{CredentialsContainer/create()|navigator.credentials.create()}} having been performed on that new device.
 
 A usage example is thus:
 
->    Say that a sign-in request appears at a website along with some geolocation signal that has not been seen for this [=user account=] before, and is outside of the typical usage hours observed for the account. The risk may be deemed high enough not to allow the request, even with a synced credential. But if a signature by a [=device-bound  key=] that is well established for this user can also be presented, then that may tip the balance.
+>    Say that a sign-in request appears at a website along with some geolocation signal that has not been seen for this [=user account=] before, and is outside of the typical usage hours observed for the account. The risk may be deemed high enough not to allow the request, even with a multi-device credential. But if a signature by a [=device-bound  key=] that is well established for this user can also be presented, then that may tip the balance.
 
 A [=[RP]=] utilizing this extension will only need to perform thorough verification of the [=device public key=]'s `attObjForDevicePublicKey` once: i.e., the first time a new [=device public key=] is received. "Thorough verification" means verifying the attestation statement `$$attStmtType` (per the [=attestation statement format=]'s "signing procedure", see [[#sctn-generating-an-attestation-object]]) as well as the `sig` value: see [[#sctn-device-publickey-extension-verification]]. Upon successful verification, the [=[RP]=] SHOULD cache the `aaguid`, `dpk`, `scope`, and `$$attStmtType` values. Upon receiving subsequent `devicePubKey` extension output values, the [=[RP]=] can, along with verifying the `sig` value of each extension output occurrence, do binary equality checks of the cached `aaguid`, `dpk`, `scope`, and `$$attStmtType` values against those returned in the extension output.