Merge pull request #1270 from w3c/issue-1231-improve-authenticator-ta…

…xonomy

Improve authenticator taxonomy section

index.bs

@@ -220,6 +220,9 @@ spec: RFC4949; urlPrefix: https://tools.ietf.org/html/rfc4949
 spec: SP800-800-63r3; urlPrefix: https://pages.nist.gov/800-63-3/sp800-63-3.html
     type: dfn
         text: authentication factor; url: af
+        text: multi-factor; url: af
+        text: second-factor; url: af
+        text: single-factor; url: sf
         text: something you know; url: af
         text: something you have; url: af
         text: something you are; url: af
@@ -3155,10 +3158,32 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti
 
 ## Authenticator Taxonomy ## {#sctn-authenticator-taxonomy}
 
-[=Authenticator=] types vary along several different dimensions: [=authenticator attachment modality=], employed [[#enum-transport|transport(s)]],
-[=credential storage modality=], and [=authentication factor capability=]. The combination of these dimensions defines an
-[=authenticator=]'s <dfn>authenticator type</dfn>, which in turn determines the broad use cases the [=authenticator=] supports.
-[Table 2](#table-authenticatorTypes) defines names for some [=authenticator types=].
+Many use cases are dependent on the capabilities of the [=authenticator=] used.
+This section defines some terminology for those capabilities, their most important combinations,
+and which use cases those combinations enable.
+
+For example:
+
+- When authenticating for the first time on a particular [=client device=], a [=roaming authenticator=] is typically needed
+    since the user doesn't yet have a [=platform credential=] on that [=client device=].
+- For subsequent re-authentication on the same [=client device=], a [=platform authenticator=] is likely the most convenient
+    since it's built directly into the [=client device=] rather than being a separate device that the user may have to locate.
+- For [=second-factor=] authentication in addition to a traditional username and password, any [=authenticator=] can be used.
+- Passwordless [=multi-factor=] authentication requires an [=authenticator=]
+    capable of [=user verification=], and in some cases also [=resident credential capable=].
+- A laptop computer might support connecting to [=roaming authenticators=] via USB and Bluetooth,
+    while a mobile phone might only support NFC.
+
+The above examples illustrate the the primary <dfn>authenticator type</dfn> characteristics:
+
+- Whether the [=authenticator=] is a [=roaming authenticator|roaming=] or [=platform authenticator|platform=] authenticator
+    &mdash; the [=authenticator attachment modality=].
+    A [=roaming authenticator=] can support one or more [[#enum-transport|transports]] for communicating with the [=client=].
+- Whether the authenticator is capable of [=user verification=] &mdash; the [=authentication factor capability=].
+- Whether the authenticator is [=resident credential capable=] &mdash; the [=credential storage modality=].
+
+These characteristics are independent and may in theory be combined in any way,
+but [Table 2](#table-authenticatorTypes) lists and names some [=authenticator types=] of particular interest.
 
 <figure id="table-authenticatorTypes" class="table">
     <table class="data">
@@ -3172,40 +3197,28 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti
         </thead>
         <tbody>
             <tr>
-                <th> Second-factor platform authenticator </th>
+                <th> <dfn>Second-factor platform authenticator</dfn> </th>
                 <td> [=platform attachment|platform=] </td>
-                <td> [=server-side credential storage modality|Server-side storage=] </td>
-                <td> [=single-factor capable|Single-factor=] </td>
+                <td> Either </td>
+                <td> [=Single-factor capable=] </td>
             </tr>
             <tr>
                 <th> <dfn>User-verifying platform authenticator</dfn> </th>
                 <td> [=platform attachment|platform=] </td>
-                <td> [=server-side credential storage modality|Server-side storage=] </td>
-                <td> [=multi-factor capable|Multi-factor=] </td>
-            </tr>
-            <tr>
-                <th> First-factor platform authenticator </th>
-                <td> [=platform attachment|platform=] </td>
-                <td> [=client-side credential storage modality|Client-side storage=] </td>
-                <td> [=multi-factor capable|Multi-factor=] </td>
+                <td> Either </td>
+                <td> [=Multi-factor capable=] </td>
             </tr>
             <tr>
-                <th> Second-factor roaming authenticator </th>
+                <th> <dfn>Second-factor roaming authenticator</dfn> </th>
                 <td> [=cross-platform attachment|cross-platform=] </td>
                 <td> [=server-side credential storage modality|Server-side storage=] </td>
-                <td> [=single-factor capable|Single-factor=] </td>
-            </tr>
-            <tr>
-                <th> User-verifying roaming authenticator </th>
-                <td> [=cross-platform attachment|cross-platform=] </td>
-                <td> [=server-side credential storage modality|Server-side storage=] </td>
-                <td> [=multi-factor capable|Multi-factor=] </td>
+                <td> [=Single-factor capable=] </td>
             </tr>
             <tr>
                 <th> <dfn>First-factor roaming authenticator</dfn> </th>
                 <td> [=cross-platform attachment|cross-platform=] </td>
                 <td> [=client-side credential storage modality|Client-side storage=] </td>
-                <td> [=multi-factor capable|Multi-factor=] </td>
+                <td> [=Multi-factor capable=] </td>
             </tr>
         </tbody>
     </table>
@@ -3214,9 +3227,36 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti
     </figcaption>
 </figure>
 
-These types can be further broken down into subtypes, such as which [[#enum-transport|transport(s)]] a [=roaming authenticator=]
-supports. The following sections define the terms [=authenticator attachment modality=], [=credential storage modality=] and
-[=authentication factor capability=].
+A [=second-factor platform authenticator=] is convenient to use for re-authentication on the same [=client device=],
+and can be used to add an extra layer of security both when initiating a new session and when resuming an existing session.
+A [=second-factor roaming authenticator=] is more likely to be used
+to authenticate on a particular [=client device=] for the first time,
+or on a [=client device=] shared between multiple users.
+
+[=User-verifying platform authenticators=] and [=first-factor roaming authenticators=]
+enable passwordless [=multi-factor=] authentication.
+In addition to the proof of possession of the [=credential private key=],
+these authenticators support [=user verification=] as a second [=authentication factor=],
+typically a PIN or [=biometric recognition=].
+The [=authenticator=] can thus act as two kinds of [=authentication factor=],
+which enables [=multi-factor=] authentication while eliminating the need to share a password with the [=[RP]=].
+
+The four combinations not named in [Table 2](#table-authenticatorTypes) have less distinguished use cases:
+
+- The [=credential storage modality=] is less relevant for a [=platform authenticator=] than for a [=roaming authenticator=],
+    since users using a [=platform authenticator=] can typically be identified by a session cookie or the like
+    (i.e., ambient credentials).
+- A [=roaming authenticator=] that is [=resident credential capable=] but not [=multi-factor capable=]
+    can be used for [=single-factor=] authentication without a username,
+    where the user is automatically identified by the [=user handle=]
+    and possession of the [=credential private key=] is used as the only [=authentication factor=].
+    This can be useful in some situations, but makes the user particularly vulnerable to theft of the [=authenticator=].
+- A [=roaming authenticator=] that is [=multi-factor capable=] but not [=resident credential capable=]
+    can be used for [=multi-factor=] authentication, but requires the user to be identified first
+    which risks leaking [PII]; see [[#sctn-credential-id-privacy-leak]].
+
+The following subsections define the aspects [=authenticator attachment modality=],
+[=credential storage modality=] and [=authentication factor capability=] in more depth.
 
 
 ### <dfn>Authenticator Attachment Modality</dfn> ### {#sctn-authenticator-attachment-modality}
@@ -3232,22 +3272,28 @@ transport protocols are referred to as <dfn>roaming authenticators</dfn>.
     device=]. A [=public key credential=] [=bound credential|bound=] to a [=platform authenticator=] is called a <dfn>platform credential</dfn>.
 
 - A [=roaming authenticator=] is attached using cross-platform transports, called <dfn>cross-platform attachment</dfn>. Authenticators of this class are removable from, and
-    can "roam" among, [=client devices=]. A [=public key credential=] [=bound credential|bound=] to a [=roaming authenticator=] is called a <dfn>roaming
+    can "roam" between, [=client devices=]. A [=public key credential=] [=bound credential|bound=] to a [=roaming authenticator=] is called a <dfn>roaming
     credential</dfn>.
 
 Some [=platform authenticators=] could possibly also act as [=roaming authenticators=] depending on context. For example, a
 [=platform authenticator=] integrated into a mobile device could make itself available as a [=roaming authenticator=] via
-Bluetooth. In this case the [=client=] would recognize it only as a [=roaming authenticator=], and not as a [=platform
-authenticator=].
-
-A primary use case for [=platform authenticators=] is to register a particular [=client device=] as a "trusted device" available
-as a [=something you have=] [=authentication factor=] for future [=authentication=]. This gives the user the convenience benefit
+Bluetooth.
+In this case [=clients=] running on the mobile device would recognise the authenticator as a [=platform authenticator=],
+while [=clients=] running on a different [=client device=] and communicating with the same authenticator via Bluetooth
+would recognize it as a [=roaming authenticator=].
+
+The primary use case for [=platform authenticators=] is to register a particular [=client device=] as a "trusted device",
+so the [=client device=] itself acts as a [=something you have=] [=authentication factor=] for future [=authentication=].
+This gives the user the convenience benefit
 of not needing a [=roaming authenticator=] for future [=authentication ceremonies=], e.g., the user will not have to dig around in
 their pocket for their key fob or phone.
 
-A primary use case for [=roaming authenticators=] is for initial [=authentication=] on a new [=client device=], or on [=client
-devices=] that are rarely used or do not include a [=platform authenticator=]; or when policy or preference dictates that the
-[=authenticator=] be kept separate from the [=clients=] it is used with. A [=roaming authenticator=] can also be used to hold
+Use cases for [=roaming authenticators=] include:
+[=authentication|authenticating=] on a new [=client device=] for the first time,
+on rarely used [=client devices=], [=client devices=] shared between multiple users,
+or [=client devices=] that do not include a [=platform authenticator=];
+and when policy or preference dictates that the [=authenticator=] be kept separate from the [=client devices=] it is used with.
+A [=roaming authenticator=] can also be used to hold
 backup [=public key credential|credentials=] in case another [=authenticator=] is lost.
 
 
@@ -6093,6 +6139,9 @@ leakage due to such an attack:
         ceremony by invoking {{CredentialsContainer/get()|navigator.credentials.get()}} using a syntactically valid
         {{PublicKeyCredentialRequestOptions}} object that is populated with plausible imaginary values.
 
+        This approach could also be used to mitigate privacy leakage via {{PublicKeyCredentialRequestOptions/allowCredentials}};
+        see [[#sctn-credential-id-privacy-leak]].
+
         Note: The username may be "provided" in various [=[RP]=]-specific fashions: login form, session cookie, etc.
 
         Note: If returned imaginary values noticeably differ from actual ones, clever attackers may be able to discern them and
@@ -6104,6 +6153,41 @@ 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=]
+        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=].
+
+In this case the {{PublicKeyCredentialRequestOptions/allowCredentials}} argument risks leaking [PII],
+if the user can initiate an [=authentication ceremony=] by only providing a username.
+[=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.
+
+The simplest ways to prevent this information leak
+is to not support [=single-factor=] authentication with [=non-resident credentials=],
+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=].
+- Requiring [=resident credentials=] for [=single-factor=] authentication,
+    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,
+the [=[RP]=] could mitigate the privacy leak using the same approach of returning imaginary [=credential IDs=]
+as discussed in [[#sctn-username-enumeration]].
+
 
 # Acknowledgements # {#sctn-acknowledgements}
 We thank the following people for their reviews of, and contributions to, this specification: