Address @selfissued's review comments

index.bs

@@ -1527,12 +1527,12 @@ This [=internal method=] accepts no arguments.
 
 </div>
 
-### Availability of [=User Verifying Platform Authenticator=] - PublicKeyCredential's `isUserVerifyingPlatformAuthenticatorAvailable()` method ### {#isUserVerifyingPlatformAuthenticatorAvailable}
+### Availability of [=User-Verifying Platform Authenticator=] - PublicKeyCredential's `isUserVerifyingPlatformAuthenticatorAvailable()` method ### {#isUserVerifyingPlatformAuthenticatorAvailable}
 
 <div link-for-hint="WebAuthentication/isUserVerifyingPlatformAuthenticatorAvailable">
 
-[=[RPS]=] use this method to determine whether they can create a new credential using a [=user verifying platform authenticator=].
-Upon invocation, the [=client=] employs a platform-specific procedure to discover available [=user verifying platform authenticators=].
+[=[RPS]=] use this method to determine whether they can create a new credential using a [=user-verifying platform authenticator=].
+Upon invocation, the [=client=] employs a platform-specific procedure to discover available [=user-verifying platform authenticators=].
 If any are discovered, the promise is resolved with the value of [TRUE].
 Otherwise, the promise is resolved with the value of [FALSE].
 Based on the result, the [=[RP]=] can take further actions to guide the user to create a credential.
@@ -2444,10 +2444,10 @@ The following defines names for some [=authenticator types=]:
             <th> <dfn>Second-factor platform authenticator</dfn> </th>
             <td> [=platform attachment|platform=] </td>
             <td> [=remote storage modality|Remote=] </td>
-            <td> [=single factor capable|Single factor=] </td>
+            <td> [=single-factor capable|Single-factor=] </td>
         </tr>
         <tr>
-            <th> <dfn>User verifying platform authenticator</dfn> </th>
+            <th> <dfn>User-verifying platform authenticator</dfn> </th>
             <td> [=platform attachment|platform=] </td>
             <td> [=remote storage modality|Remote=] </td>
             <td> [=multi-factor capable|Multi-factor=] </td>
@@ -2462,10 +2462,10 @@ The following defines names for some [=authenticator types=]:
             <th> <dfn>Second-factor roaming authenticator</dfn> </th>
             <td> [=cross-platform attachment|cross-platform=] </td>
             <td> [=remote storage modality|Remote=] </td>
-            <td> [=single factor capable|Single factor=] </td>
+            <td> [=single-factor capable|Single-factor=] </td>
         </tr>
         <tr>
-            <th> <dfn>User verifying roaming authenticator</dfn> </th>
+            <th> <dfn>User-verifying roaming authenticator</dfn> </th>
             <td> [=cross-platform attachment|cross-platform=] </td>
             <td> [=remote storage modality|Remote=] </td>
             <td> [=multi-factor capable|Multi-factor=] </td>
@@ -2524,15 +2524,14 @@ An [=authenticator=] can store a [=credential private key=] in one of two ways:
 
     A [=credential private key=] stored in this way is a [=client-side-resident credential private key=].
 
- 1. By encrypting the [=credential private key=] such that only this [=authenticator=] can decrypt it, and letting the resulting
+ 1. By encrypting the [=credential private key=] such that only this [=authenticator=] can decrypt it and letting the resulting
     ciphertext be the [=credential ID=] for the [=public key credential source=]. The [=credential ID=] is stored by the [=[RP]=]
     and returned to the [=authenticator=] via the {{PublicKeyCredentialRequestOptions/allowCredentials}} option of
     {{CredentialsContainer/get()}}, which allows the [=authenticator=] to decrypt and use the [=credential private key=].
 
-
-
     This enables the [=authenticator=] to have unlimited storage capacity for [=credential private keys=], since the encrypted
-    [=credential private keys=] are stored by the [=[RP]=] instead of by the [=authenticator=], but it means that a [=credential=]
+    [=credential private keys=] are stored by the [=[RP]=] instead of by the [=authenticator=] - but it means that a
+    [=credential=] stored in this way must be retrieved from the [=[RP]=] before the [=authenticator=] can use it.
 
 Which of these storage strategies an [=authenticator=] supports defines the [=authenticator=]'s <dfn>storage modality</dfn> as
 follows:
@@ -2552,7 +2551,7 @@ though subject to the {{AuthenticatorSelectionCriteria/requireResidentKey}} opti
 ### <dfn>Authentication factor capability</dfn> ### {#sctn-authentication-factor-capability}
 
 There are three broad classes of [=authentication factors=] that can be used to prove an identity during an [=authentication
-ceremony=]: [=something you have=], [=something you know=] and [=something you are=]. Examples include a physical key, a password
+ceremony=]: [=something you have=], [=something you know=] and [=something you are=]. Examples include a physical key, a password,
 and a fingerprint, respectively.
 
 This specification is mainly concerned with the [=something you have=] class - an [=authenticator=] containing a [=credential
@@ -2563,7 +2562,7 @@ as one or two additional kinds of [=authentication factor=]. For example, if the
 Since the [=authenticator=] itself is [=something you have=], this means that an [=authenticator=] that supports [=user
 verification=] can act as more than one kind of [=authentication factor=] - possibly all three kinds. Therefore, an
 [=authenticator=] that supports [=user verification=] is <dfn>multi-factor capable</dfn>. Conversely, an [=authenticator=] that is
-not [=multi-factor capable=] is <dfn>single factor capable</dfn>.
+not [=multi-factor capable=] is <dfn>single-factor capable</dfn>.
 
 Although [=user verification=] is performed locally on the [=authenticator=] and not by the [=[RP]=], the [=authenticator=]
 indicates if [=user verification=] was performed by setting the [=UV=] [=flag=] in the signed response returned to the [=[RP]=].
@@ -4780,10 +4779,10 @@ The sample code for generating and registering a new key follows:
       });
 </pre>
 
-## Registration Specifically with User Verifying Platform Authenticator ## {#sample-registration-with-platform-authenticator}
+## Registration Specifically with User-Verifying Platform Authenticator ## {#sample-registration-with-platform-authenticator}
 
 This is flow for when the [=[RP]=] is specifically interested in creating a public key credential with
-a [=user verifying platform authenticator=].
+a [=user-verifying platform authenticator=].
 
 1. The user visits example.com and clicks on the login button, which redirects the user to login.example.com.