WIP: Extract Authenticator Taxonomy section and define 1st/2nd factor…

… authnr/cred

index.bs

@@ -400,12 +400,13 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 : <dfn>Client-side-resident Credential Private Key</dfn>
 :: A [=Client-side-resident Credential Private Key=] is stored either on the client platform, or in some cases on the
-    authenticator itself, e.g., in the case of a discrete first-factor roaming authenticator. Such <dfn>client-side credential
-    private key storage</dfn> has the property that the authenticator is able to select the [=credential private key=] given
-    only an [=RP ID=], possibly with user assistance (e.g., by providing the user a pick list of credentials associated with the RP
-    ID). By definition, the private key is always exclusively controlled by the Authenticator. In the case of a
-    [=Client-side-resident Credential Private Key=], the Authenticator might offload storage of wrapped key material to the
-    client platform, but the client platform is not expected to offload the key storage to remote entities (e.g. RP Server).
+    authenticator itself, e.g., in the case of a discrete [=first-factor authenticator|first-factor=] [=roaming authenticator=].
+    By definition, the private key is always exclusively controlled by the Authenticator.
+    In the case of a [=Client-side-resident Credential Private Key=], the Authenticator might offload storage of wrapped key
+    material to the client platform, but the client platform is not expected to offload the key storage to remote entities (e.g.
+    RP Server).
+
+    A [=client-side-resident credential private key=] is the defining characteristic of a [=first-factor credential=].
 
 : <dfn>Conforming User Agent</dfn>
 :: A user agent implementing, in conjunction with the underlying platform, the [=Web Authentication API=] and algorithms
@@ -431,6 +432,32 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     attestation=], the [=credential key pair=] is also used as the [=attestation key pair=], see [=self attestation=]
     for details.
 
+: <dfn>First-Factor Authenticator</dfn>
+:: A [=first-factor authenticator=] is an [=authenticator=] that is capable of creating [=first-factor credentials=]. An
+    [=authenticator=] has this capability if and only if it satisfies all of the following criteria:
+
+    - It is capable of [=user verification=].
+    - It can store and retrieve the [=user handles=] associated with its [=public key credential|credentials=].
+    - It is capable of generating an [=assertion=] given only an [=RP ID=]. In particular, this means it is capable of creating
+        [=client-side-resident credential private keys=].
+
+    A [=first-factor authenticator=] might also be capable of creating [=second-factor credentials=].
+
+: <dfn>First-Factor Credential</dfn>
+:: A [=first-factor credential=] is a [=public key credential source=] created by a [=first-factor authenticator=], and whose
+    [=credential private key=] is a [=client-side-resident credential private key=]. A [=first-factor credential=] therefore has
+    the property that the [=authenticator=] is able to select the [=credential private key=] given only an [=RP ID=], possibly
+    with user assistance (e.g., by providing the user a pick list of credentials associated with the [=RP ID=]).
+
+    [=First-factor credentials=] enable an [=authentication=] scenario where the [=first-factor credential=] is used to both
+    identify and authenticate the user in a single step, possibly without other user input. For this reason, use of a
+    [=first-factor credential=] always requires [=user verification=] so that mere possession of the [=authenticator=] is not
+    sufficient to complete an [=authentication ceremony=].
+
+    Because each [=first-factor credential=] requires a [=client-side-resident credential private key=], [=first-factor
+    authenticators=] might have limited storage capacity for [=first-factor credentials=]. Management of such storage is beyond
+    the scope of this specification.
+
 : <dfn>Human Palatability</dfn>
 :: An identifier that is [=human palatability|human-palatable=] is intended to be rememberable and reproducible by typical human
     users, in contrast to identifiers that are, for example, randomly generated sequences of bits [[EduPersonObjectClassSpec]].
@@ -536,6 +563,21 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
         [=document.domain=]'s setter provides.
     </div>
 
+: <dfn>Second-Factor Authenticator</dfn>
+:: A [=second-factor authenticator=] is an [=authenticator=] that is not a [=first-factor authenticator=], and therefore can only
+    create [=second-factor credentials=]. In particular, a [=second-factor authenticator=] typically requires being given a
+    [=credential ID=] in order to generate an [=assertion=].
+
+: <dfn>Second-Factor Credential</dfn>
+:: In contrast to [=first-factor credentials=], a [=second-factor credential=] can only be used if the [=authenticator=] is also
+    given the [=credential ID=] for the requested [=second-factor credential=]. This is the case when the [=authenticator=]
+    implements [=credential=] storage by using the encrypted [=public key credential source=] as the [=credential ID=], which also
+    means that such an [=authenticator=] has unlimited storage capacity for [=second-factor credentials=].
+
+    Because a [=second-factor credential=] requires a [=credential ID=] to be used, the [=authentication ceremony=] needs to be
+    done in two steps: the user first needs to provide some identification, such as a [=username=] and/or password, and only then
+    can the [=[RP]=] look up the user's [=credential IDs=] and request an [=assertion=] proving the claimed identity.
+
 : <dfn>Test of User Presence</dfn>
 :: A [=test of user presence=] is a simple form of [=authorization gesture=] and technical process where a user interacts with
     an [=authenticator=] by (typically) simply touching it (other modalities may also exist), yielding a boolean result. Note
@@ -1745,32 +1787,8 @@ attributes.
     };
 </pre>
 
-Clients can communicate with authenticators using a variety of mechanisms. For example, a client MAY use a platform-specific
-API to communicate with an authenticator which is physically bound to a platform. On the other hand, a client can use a
-variety of standardized cross-platform transport protocols such as Bluetooth (see [[#transport]]) to discover and
-communicate with [=cross-platform attached=] authenticators. Therefore, we use {{AuthenticatorAttachment}} to describe an
-[=authenticator=]'s <dfn>attachment modality</dfn>. We define authenticators that are part of the client's
-platform as having a [=platform attachment=], and refer to them as <dfn>platform authenticators</dfn>. While those that
-are reachable via cross-platform transport protocols are defined as having [=cross-platform attachment=], and refer to
-them as <dfn>roaming authenticators</dfn>.
-
-<ul>
-    <li><dfn>platform attachment</dfn> - the respective authenticator is attached
-        using platform-specific transports.  Usually, authenticators of
-        this class are non-removable from the platform. A [=public key credential=] bound to a [=platform authenticator=] is
-        called a <dfn>platform credential</dfn>.
-    <li><dfn lt="cross-platform attached|cross-platform attachment">cross-platform attachment</dfn> - the respective
-        authenticator is attached using cross-platform transports. Authenticators of this class are removable from, and can
-        "roam" among, client platforms. A [=public key credential=] bound to a [=roaming authenticator=] is called a <dfn>roaming
-        credential</dfn>.
-</ul>
-
-This distinction is important because there are use-cases where only [=platform authenticators=] are acceptable to a [=[RP]=], and
-conversely ones where only [=roaming authenticators=] are employed. As a concrete example of the former, a [=platform credential=]
-may be used by [=[RPS]=] to quickly and conveniently reauthenticate the user with a minimum of friction, e.g., the user will not
-have to dig around in their pocket for their key fob or phone. 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 asked to use a [=roaming credential=] which was originally
-registered with the [=[RP]=] using a different client.
+This enumeration is used to describe the [=[RP]=]'s preferred [=attachment modality=] of the [=authenticator=] to use to create a
+[=public key credential|credential=].
 
 Note: An [=attachment modality=] selection option is available only in the {{PublicKeyCredential/[[Create]](origin, options,
 sameOriginWithAncestors)}} operation. The [=[RP]=] may use it to, for example, ensure the user has a [=roaming credential=] for
@@ -2274,6 +2292,66 @@ Authenticators:
 - should ensure that the [=signature counter=] value does not 
     accidentally decrease  (e.g., due to hardware failures).
 
+
+## Authenticator taxonomy ## {#sctn-authenticator-taxonomy}
+
+[=Authenticators=] are divided into four primary categories based on two independent primary characteristics: the [=attachment
+modality=], and the [=first-factor capability=]. The combinations of these characteristics enable different kinds of use cases.
+
+- A <dfn>second-factor platform authenticator</dfn> is a [=platform authenticator=] that is also a [=second-factor authenticator=].
+    This enables use cases where a particular device, such as a laptop computer or smartphone, is registered as a "trusted device"
+    and available for use as a second authentication factor in future [=authentication ceremonies=]. The authentication factors in
+    these use cases are typically a password (something you know) and the registered device (something you have).
+
+- A <dfn>second-factor roaming authenticator</dfn> is a [=roaming authenticator=] that is also a [=second-factor authenticator=].
+    This enables use cases where the [=authenticator=] can be used with any [=client=] on any device, for example for the first
+    login with a particular [=client=]. The authentication factors in this use case are typically a password (something you know)
+    and the [=authenticator=] (something you have).
+
+- A <dfn>first-factor platform authenticator</dfn> is a [=platform authenticator=] that is also a [=first-factor authenticator=].
+    In combination with the use cases of a [=second-factor platform authenticator=], this enables "passwordless login" use cases
+    where the user does not need to provide a [=username=] or password. The user might instead only need to enter a PIN, or scan a
+    fingerprint on a smartphone or laptop computer.
+
+- A <dfn>first-factor roaming authenticator</dfn> is a [=roaming authenticator=] that is also a [=first-factor authenticator=].
+    In combination with the use cases of a [=second-factor roaming authenticator=], this enables "passwordless login" use cases
+    where the user does not need to provide a [=username=] or password. The user might instead only need to connect the
+    [=authenticator=] and enter a PIN, or scan a fingerprint on a sensor integrated into the [=authenticator=].
+
+
+### <dfn>Attachment Modality</dfn> ### {#sctn-authenticator-attachment-modality}
+
+[=Clients=] can communicate with [=authenticators=] using a variety of mechanisms. For example, a [=client=] MAY use a
+platform-specific API to communicate with an [=authenticator=] which is physically bound to a platform. On the other hand, a
+[=client=] can use a variety of standardized cross-platform transport protocols such as Bluetooth (see [[#transport]]) to discover
+and communicate with cross-platform attached [=authenticators=]. We refer to [=authenticators=] that are part of the [=client=]'s
+platform as <dfn>platform authenticators</dfn>, while those that are reachable via cross-platform transport protocols are referred
+to as <dfn>roaming authenticators</dfn>.
+
+<ul>
+    <li>A [=platform authenticator=] is attached using a platform-specific transport, and is usually not removable from the
+        platform. A [=public key credential=] bound to a [=platform authenticator=] is called a <dfn>platform credential</dfn>.
+    <li>A [=roaming authenticator=] is attached using cross-platform transports. Authenticators of this class are removable from,
+        and can "roam" among, client platforms. A [=public key credential=] bound to a [=roaming authenticator=] is called a
+        <dfn>roaming credential</dfn>.
+</ul>
+
+This distinction is important because there are use-cases where [=platform authenticators=] are preferred by a [=[RP]=], and
+conversely ones where only [=roaming authenticators=] are employed. As a concrete example of the former, a [=platform credential=]
+may be used by [=[RPS]=] to quickly and conveniently reauthenticate the user with a minimum of friction, e.g., the user will not
+have to dig around in their pocket for their key fob or phone. 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 asked to use a [=roaming credential=] which was originally
+registered with the [=[RP]=] using a different [=client=].
+
+
+### <dfn>First-Factor Capability</dfn> ### {#sctn-authenticator-first-factor-capability}
+
+The [=first-factor capability=] of an [=authenticator=] is determined by whether the [=authenticator=] is a [=first-factor
+authenticator=] or a [=second-factor authenticator=]. A [=first-factor authenticator=] is capable of creating [=first-factor
+credentials=] and MAY be capable of creating [=second-factor credentials=], while a [=second-factor authenticator=] is capable of
+creating [=second-factor credentials=] only.
+
+
 ## <dfn>Authenticator operations</dfn> ## {#authenticator-ops}
 
 A [=[WAC]=] MUST connect to an authenticator in order to invoke any of the operations of that authenticator. This connection
@@ -4391,7 +4469,7 @@ It also registers identifiers for ECDAA algorithms.
 In this section, we walk through some events in the lifecycle of a [=public key credential=], along with the corresponding
 sample code for using this API. Note that this is an example flow and does not limit the scope of how the API can be used.
 
-As was the case in earlier sections, this flow focuses on a use case involving an external first-factor [=authenticator=]
+As was the case in earlier sections, this flow focuses on a use case involving an external [=first-factor authenticator=]
 with its own display. One example of such an authenticator would be a smart phone. Other authenticator types are also supported
 by this API, subject to implementation by the platform. For instance, this flow also works without modification for the case of
 an authenticator that is embedded in the client platform. The flow also works for the case of an authenticator without