use Vijay's examples

index.bs

@@ -664,20 +664,22 @@ authorizing an authenticator with which to complete the operation.
 
 <div dfn-for="Attachment">
     Clients may communicate with authenticators using a variety of mechanisms.
-    For example, a client may use a platform-specific API to communicate with
+    For example, a client may use a platform-specific mechanism to communicate with
     an authenticator which is physically bound do a platform.  On the other
     hand, a client may use a variety of transports such as Bluetooth
     (see [[#transport]] to discover and communicate with authenticators.
     We define authenticators that are part of the client's platform as having
     a |platform| attachment, while those that are reachable via standardized
     cross-platform protocols are defined as having |cross_platform| attachment.
     This distinction is important because some [RPS] are known to have
-    use-cases where only a |platform| attached authenticator is acceptable 
-    (or use-cases where only |cross_platform| attachment may be used).  As
-    concrete example for the former, [RPS] that offer accounts whereby a
-    webauthn authenticator may be used as the only valid second factor will not
-    want to allow users to use platform-attached authenticators -- as this will
-    lead to user lockout.
+    use-cases where only a |platform| attached authenticator is acceptable (or
+    use-cases where only |cross_platform| attachment may be used).  As a
+    concrete example of the former, a credential on a platform authenticator
+    may be used by [RPS] to quickly and conveniently reauthentication the user
+    with a minimum of friction.  As a concrete example of the latter, when the
+    user is accessing the [RP] from a given client for the first time, they may
+    be required to use a cross-platform authenticator which was originally set
+    up on a different client.
 
     <ul>
         <li><dfn>platform</dfn> - the respective authenticator is attached