Add privacy considerations about credential IDs

index.bs

@@ -6001,9 +6001,9 @@ leakage due to such an attack:
     - When verifying an {{AuthenticatorAssertionResponse}} response from the [=authenticator=], make it indistinguishable whether
           verification failed because the signature is invalid or because no such user or credential is registered.
 
-    - Perform a different authentication step, such as username and password authentication,
-        before initiating the WebAuthn [=authentication ceremony=].
-        This moves the username enumation problem from the WebAuthn [=authentication ceremony=]
+    - Perform a multi-step [=authentication ceremony=], e.g., beginning with supplying username and password or a session cookie,
+        before initiating the WebAuthn [=ceremony=] as a subsequent step.
+        This moves the username enumation problem from the WebAuthn step
         to the preceding authentication step, where it may be easier to solve.
 
 
@@ -6026,8 +6026,8 @@ is to not support [=single-factor=] authentication with [=non-resident credentia
 for example by:
 
 - Performing a separate authentication step,
-    such as username and password authentication, before initiating the WebAuthn [=authentication ceremony=]
-    and exposing the user's [=credential IDs=].
+    such as username and password authentication or session cookie authentication,
+    before initiating the WebAuthn [=authentication ceremony=] and exposing the user's [=credential IDs=].
 - Requiring [=resident credentials=] for [=single-factor=] authentication,
     so the {{PublicKeyCredentialRequestOptions/allowCredentials}} argument is not needed.