Address comments from @equalsJeffH

index.bs

@@ -408,9 +408,9 @@ When this method is invoked, the user agent MUST execute the following algorithm
 6. If {{CredentialOptions/extensions}} was specified, process any extensions supported by this client platform, to produce the
     extension data that needs to be sent to the authenticator. Call this data |clientExtensions|.
 
-7. Use {{attestationChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin|, to
-    create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and compute
-    the <a>clientDataJSON</a> and <a>clientDataHash</a>.
+7. Use {{attestationChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin| (if
+    any), to create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and
+    compute the <a>clientDataJSON</a> and <a>clientDataHash</a>.
 
 8. Initialize |issuedRequests| to an empty list.
 
@@ -472,18 +472,19 @@ When this method is invoked, the user agent MUST execute the following algorithm
 4. If {{AssertionOptions/extensions}} was specified, process any extensions supported by this client platform, to produce the
     extension data that needs to be sent to the authenticator. Call this data |clientExtensions|.
 
-5. Use {{assertionChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin|, to
-    create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and compute
-    the <a>clientDataJSON</a> and <a>clientDataHash</a>.
+5. Use {{assertionChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin| (if
+    any), to create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and
+    compute the <a>clientDataJSON</a> and <a>clientDataHash</a>.
 
 6. Initialize |issuedRequests| to an empty list.
 
 7. For each authenticator currently available on this platform, perform the following steps:
     - If <a>allowList</a> is undefined or empty, let |credentialList| be an empty list. Otherwise, execute a platform-specific
-        procedure to determine which of these credentials might be present on this authenticator, and set |credentialList| to
-        this filtered list. If no such filtering is possible, set |credentialList| to an empty list.
+        procedure to determine which, if any, credentials listed in <a>allowList</a> might be present on this authenticator, and
+        set |credentialList| to this filtered list. If no such filtering is possible, set |credentialList| to an empty list.
     - If the above filtering process concludes that none of the credentials on <a>allowList</a> can possibly be on this
-        authenticator, ignore this authenticator and do not perform any of the following per-authenticator steps.
+        authenticator, do not perform any of the following steps for this authenticator, and proceed to the next authenticator
+        (if any).
     - Asynchronously invoke the <a>authenticatorGetAssertion</a> operation on this authenticator with |rpIdHash|,
         <a>clientDataHash</a>, |credentialList|, and |clientExtensions| as parameters.
     - Add an entry to |issuedRequests|, corresponding to this request.
@@ -918,7 +919,7 @@ credential does not change between operations but instead remains the same for t
 validated by the authenticator during the <a>authenticatorGetAssertion</a> operation, by making sure that the RP ID hash
 associated with the requested credential exactly matches the RP ID hash supplied by the client. These differences also explain
 why the RP ID hash is always a SHA-256 hash instead of being crypto-agile like the <a>clientDataHash</a>; for a given RP ID, we
-need the hash to be computed the same way by all clients for all operations so that authenticators can move between clients
+need the hash to be computed the same way by all clients for all operations so that authenticators can roam among clients
 without losing interoperability.
 
 The `TUP` flag SHALL be set if and only if the authenticator detected a user through an authenticator specific gesture. The
@@ -1048,7 +1049,7 @@ Upon receiving an attestation statement, the [RP] shall:
     - Verify `rawData` syntax and that it doesn't contradict the signing algorithm specified in `alg`.
     - The DAA root key is dedicated to a single Authenticator model.
 
-4. Verify the contextual bindings (e.g., channel binding) from the `clientData` (see [[#authenticator-signature]]).
+4. Verify the contextual bindings (e.g., token binding) from the `clientData` (see [[#authenticator-signature]]).
 
 5. Verify that user verification method and other authenticator characteristics related to this authenticator model, match the
     [RP] policy. The FIDO Metadata Service [[FIDOMetadataService]] provides an easy way to access the authenticator
@@ -1450,7 +1451,7 @@ For this attestation format, the {{ClientData}} dictionary is extended in the fo
 </div>
 
 In order to generate an attestation statement, the client MUST create <a>clientDataJSON</a> by UTF8-encoding a structure of type
-AndroidAttestationClientData, and compute <a>clientDataHash</a> as the hash of <a>clientDataJSON</a>. It must then provide
+{{AndroidAttestationClientData}}, and compute <a>clientDataHash</a> as the hash of <a>clientDataJSON</a>. It must then provide
 <a>clientDataHash</a> as the Nonce value when requesting the SafetyNet attestation.