Add privacy considerations about credential IDs (#1250)

* Apply suggestions from code review

Co-Authored-By: =JeffH <jdhodges@google.com>

* Fix whitespace

* Suggest session cookie as mitigation

* Fix pluralisation

* Add note of identifying authenticator owner from credential IDs

* Address @manger's comment about 'single-factor'

* Make reason for credID privacy leak more precise and general

* Focus privacy leak more on second-factor than non-resident keys

index.bs

@@ -6618,38 +6618,40 @@ 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 enumeration 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.
 
 
 ### Privacy leak via credential IDs ### {#sctn-credential-id-privacy-leak}
 
 [INFORMATIVE]
 
-This privacy consideration applies to [=[RPS]=] supporting [=single-factor=] authentication with [=non-resident credentials=].
+This privacy consideration applies to [=[RPS]=] that support [=authentication ceremonies=]
+with a non-[=list/empty=] {{PublicKeyCredentialRequestOptions/allowCredentials}} argument as the first authentication step.
+For example, if using authentication with [=non-resident credentials=] as the first authentication step.
 
 In this case the {{PublicKeyCredentialRequestOptions/allowCredentials}} argument risks leaking [PII],
-if the user can initiate an [=authentication ceremony=] by only providing a username.
+since it exposes the user's [=credential IDs=] to an unauthenticated caller.
 [=Credential IDs=] are designed to not be correlatable between [=[RPS]=],
 but the length of a [=credential ID=] might be a hint as to what type of [=authenticator=] created it.
 It is likely that a user will use the same username and set of [=authenticators=] for several [=[RPS]=],
 so the number of [=credential IDs=] in {{PublicKeyCredentialRequestOptions/allowCredentials}} and their lengths
 might serve as a global correlation handle to de-anonymize the user.
+Knowing a user's [=credential IDs=] also makes it possible to confirm guesses about the user's identity
+given only momentary physical access to one of the user's [=authenticators=].
 
-The simplest ways to prevent this information leak
-is to not support [=single-factor=] authentication with [=non-resident credentials=],
-for example by:
+In order to prevent such information leakage, the [=[RP]=] could for example:
 
-- Performing a separate authentication step,
-    such as username and password authentication, before initiating the WebAuthn [=authentication ceremony=]
-    and exposing the user's [=credential IDs=].
-- Requiring [=resident credentials=] for [=single-factor=] authentication,
+- Perform a separate authentication step,
+    such as username and password authentication or session cookie authentication,
+    before initiating the WebAuthn [=authentication ceremony=] and exposing the user's [=credential IDs=].
+- Use [=resident credentials=],
     so the {{PublicKeyCredentialRequestOptions/allowCredentials}} argument is not needed.
 
-If [=single-factor=] authentication with [=non-resident credentials=] is a requirement,
-i.e., {{PublicKeyCredentialRequestOptions/allowCredentials}} needs to be exposed given only a username,
+If the above prevention measures are not available,
+i.e., if {{PublicKeyCredentialRequestOptions/allowCredentials}} needs to be exposed given only a username,
 the [=[RP]=] could mitigate the privacy leak using the same approach of returning imaginary [=credential IDs=]
 as discussed in [[#sctn-username-enumeration]].