Correct and qualify uses of "device"

index.bs

@@ -3146,8 +3146,8 @@ the [=authenticator=] MUST:
             |  17 6c 92 bb 8e 36 c0 41  98 a2 7b 90 9b 6e 8f 13
         ```
 
-        Note: As CTAP1/U2F devices are already producing signatures values in this format, CTAP2
-        devices will also produce signatures values in the same format, for consistency reasons.
+        Note: As CTAP1/U2F [=authenticators=] are already producing signatures values in this format, CTAP2
+        [=authenticators=] will also produce signatures values in the same format, for consistency reasons.
         It is recommended that any new attestation formats defined not use ASN.1 encodings,
         but instead represent signatures as equivalent fixed-length byte arrays without internal structure,
         using the same representations as used by COSE signatures as defined in [[!RFC8152]] and [[!RFC8230]].
@@ -4414,7 +4414,7 @@ This extension enables use of a user verification index.
 
     As an example, the UVI could be computed as SHA256(KeyID || SHA256(rawUVI)), where `||` represents concatenation, and the
     rawUVI reflects (a) the biometric reference data, (b) the related OS level user ID and (c) an identifier which changes
-    whenever a factory reset is performed for the device, e.g. rawUVI = biometricReferenceData || OSLevelUserID ||
+    whenever a factory reset is performed for the [=authenticator=], e.g. rawUVI = biometricReferenceData || OSLevelUserID ||
     FactoryResetCounter.
 
     Example of [=authenticator data=] containing one UVI extension
@@ -4683,8 +4683,8 @@ IANA "WebAuthn Extension Identifier" registry established by [[!WebAuthn-Registr
 - Specification Document: Section [[#sctn-uvi-extension]] of this specification
     <br/><br/>
 - WebAuthn Extension Identifier: loc
-- Description: The location [=registration extension=] and [=authentication extension=] provides the client device's current
-    location to the [=[WRP]=], if supported by the client device and subject to [=user consent=].
+- Description: The location [=registration extension=] and [=authentication extension=] provides the [=client device=]'s current
+    location to the [=[WRP]=], if supported by the [=client platform=] and subject to [=user consent=].
 - Specification Document: Section [[#sctn-location-extension]] of this specification
     <br/><br/>
 - WebAuthn Extension Identifier: uvm
@@ -4989,7 +4989,7 @@ The following are possible situations in which decommissioning a credential migh
 handled on the server side and do not need support from the API specified here.
 
 - Possibility #1 -- user reports the credential as lost.
-    * User goes to server.example.net, authenticates and follows a link to report a lost/stolen device.
+    * User goes to server.example.net, authenticates and follows a link to report a lost/stolen [=authenticator=].
     * Server returns a page showing the list of registered credentials with friendly names as configured during registration.
     * User selects a credential and the server deletes it from its database.
     * In future, the [=[RP]=] script does not specify this credential in any list of acceptable credentials, and assertions
@@ -5000,8 +5000,8 @@ handled on the server side and do not need support from the API specified here.
     * In the future, the [=[RP]=] script does not specify this credential in any list of acceptable credentials, and assertions
         signed by this credential are rejected.
 
-- Possibility #3 -- user deletes the credential from the device.
-    * User employs a device-specific method (e.g., device settings UI) to delete a credential from their device.
+- Possibility #3 -- user deletes the credential from the [=authenticator=].
+    * User employs a [=authenticator=]-specific method (e.g., device settings UI) to delete a credential from their [=authenticator=].
     * From this point on, this credential will not appear in any selection prompts, and no assertions can be generated with it.
     * Sometime later, the server deregisters this credential due to inactivity.
 
@@ -5042,7 +5042,7 @@ therefore be at least 16 bytes long.
 
 A 3-tier hierarchy for attestation certificates is RECOMMENDED (i.e., Attestation Root, Attestation Issuing CA, Attestation
 Certificate). It is also RECOMMENDED that for each WebAuthn Authenticator device line (i.e., model), a separate issuing CA is
-used to help facilitate isolating problems with a specific version of a device.
+used to help facilitate isolating problems with a specific version of an authenticator model.
 
 If the attestation root certificate is not dedicated to a single WebAuthn Authenticator device line (i.e., AAGUID), the AAGUID
 SHOULD be specified in the attestation certificate itself, so that it can be verified against the [=authenticator data=].
@@ -5052,7 +5052,7 @@ SHOULD be specified in the attestation certificate itself, so that it can be ver
 
 When an intermediate CA or a root CA used for issuing attestation certificates is compromised, WebAuthn [=authenticator=]
 attestation keys are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
-has recorded the public attestation keys for their devices can issue new attestation certificates for these keys from a new
+has recorded the public attestation keys for their [=authenticator=] models can issue new attestation certificates for these keys from a new
 intermediate CA or from a new root CA. If the root CA changes, the [=[WRPS]=]  MUST update their trusted root certificates
 accordingly.
 
@@ -5227,11 +5227,11 @@ instead of revealing the biometric data itself to the [=[RP]=].
 Attestation keys can be used to track users or link various online identities of the same user together. This can be mitigated
 in several ways, including:
 
-- A WebAuthn [=authenticator=] manufacturer may choose to ship all of their devices with the same (or a fixed number of)
+- A WebAuthn [=authenticator=] manufacturer may choose to ship all of their [=authenticators=] with the same (or a fixed number of)
     attestation key(s) (called [=Basic Attestation=]). This will anonymize the user at the risk of not being able to revoke a
     particular attestation key if its private key is compromised.
 
-    [[UAFProtocol]] requires that at least 100,000 devices share the same attestation certificate in order to produce
+    [[UAFProtocol]] requires that at least 100,000 [=authenticator=] devices share the same attestation certificate in order to produce
     sufficiently large groups. This may serve as guidance about suitable batch sizes.
 
 - A WebAuthn [=authenticator=] may be capable of dynamically generating different attestation keys (and requesting related