editorial nits

Co-authored-by: Emil Lundberg <[email protected]>

index.bs

@@ -405,7 +405,7 @@ Beyond that, the intended audiences for this document are the following main gro
 The below use case scenarios illustrate use of two very different types of [=authenticators=] and credentials across two common deployment types, 
 as well as outline further scenarios. Additional scenarios, including sample code, are given later in [[#sctn-sample-scenarios]].
 
-### Consumers and Multi-Device Credentials ### {#sctn-usecase-consumer-mdc}
+### Consumer with Multi-Device Credentials ### {#sctn-usecase-consumer-mdc}
 
 #### Registration #### {#sctn-usecase-consumer-mdc-reg}
 
@@ -423,13 +423,13 @@ as well as outline further scenarios. Additional scenarios, including sample cod
 - On a laptop or desktop:
     * User navigates to example.com in a browser and initiates signing in.
     * If the [=multi-device credential=] (commonly referred to as a synced [=passkey=]) is available on the device:
-        * the browser or operating system prompts the user for a previously configured [=authorization gesture=] (PIN, biometric, etc.); 
+        * The browser or operating system prompts the user for a previously configured [=authorization gesture=] (PIN, biometric, etc.); 
             the user provides this.
         * Web page shows that the selected user is signed in, and navigates to the signed-in page.
     * If the synced [=passkey=] is not available on the device:
-        * the browser or operating system prompts the user for an external authenticator,
+        * The browser or operating system prompts the user for an external authenticator,
             such as a phone or security key.
-        * the user selects a previously linked phone.
+        * The user selects a previously linked phone.
 
 - Next, on their phone:
     * User sees a discrete prompt or notification, "Sign in to example.com."
@@ -441,7 +441,7 @@ as well as outline further scenarios. Additional scenarios, including sample cod
     * Web page shows that the selected user is signed in, and navigates to the signed-in page.
 
 
-### Workforce and Single-Device Credentials ### {#sctn-usecase-workforce-sdc}
+### Workforce with Single-Device Credentials ### {#sctn-usecase-workforce-sdc}
 
 This use case scenario illustrates how a workforce-centric [=[RP]=] can leverage a combination of a [=roaming authenticator=] (e.g., a USB security
 key) and a [=platform authenticator=] (e.g., a built-in fingerprint sensor) such that the user has:
@@ -450,13 +450,13 @@ key) and a [=platform authenticator=] (e.g., a built-in fingerprint sensor) such
     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=], or
   - a means to strong re-authenticate on [=client devices=] having [=passkey platform authenticators=] which do not support [=single-device credentials=]
-    (commonly referred to as device-bound [=passkeys=])
+    (commonly referred to as device-bound [=passkeys=]).
 
 #### Registration #### {#sctn-usecase-workforce-sdc-reg}
 
 In this example, the user's employer mails a security key which is preconfigured with a device-bound [=passkey=].
 
-A temporary PIN was sent to the user out of band (ex: via an RCS message).
+A temporary PIN was sent to the user out of band (e.g., via an RCS message).
 
 #### Authentication #### {#sctn-usecase-workforce-sdc-auth}