Authenticator taxonomy: Attachment modality (replaces #842)

index.bs

@@ -468,7 +468,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     those [=ceremonies=].
 
 : <dfn>Client</dfn>
-:: See [=WebAuthn Client=], [=Conforming User Agent=].
+:: See [=[WAC]=], [=Conforming User Agent=].
 
 : <dfn>Client-Side</dfn>
 :: This refers in general to the combination of the user's platform device, user agent, authenticators, and everything gluing
@@ -581,8 +581,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 :: The process (also known as throttling) by which an authenticator implements controls against brute force attacks by limiting
     the number of consecutive failed authentication attempts within a given period of time. If the limit is reached, the
     authenticator should impose a delay that increases exponentially with each successive attempt, or disable the current
-    authentication modality and offer a different [=authentication factor=] if available. Rate limiting is often implemented as an
-    aspect of [=user verification=].
+    authentication modality and offer a different [=authentication factor=] if available. [=Rate limiting=] is often implemented
+    as an aspect of [=user verification=].
 
 : <dfn>Registration</dfn>
 : <dfn>Registration Ceremony</dfn>
@@ -938,64 +938,8 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
 1. Start |lifetimeTimer|.
 
-          1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{authenticatorAttachment}}</code> is
-            [=present|present=] and its value is not equal to |authenticator|'s [=attachment modality=], [=iteration/continue=].
-          1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{requireResidentKey}}</code> is set to
-            `true` and the |authenticator| is not capable of storing a [=Client-Side-Resident Credential Private Key=],
-            [=iteration/continue=].
-          1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{AuthenticatorSelectionCriteria/userVerification}}</code> is
-            set to {{UserVerificationRequirement/required}} and the |authenticator| is not capable of performing [=user
-            verification=], [=iteration/continue=].
-
-    1. Let |userVerification| be the <dfn>effective user verification requirement for credential creation</dfn>, a Boolean value,
-        as follows. If
-        <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{AuthenticatorSelectionCriteria/userVerification}}</code>
-
-            <dl class="switch">
-
-                :   is set to {{UserVerificationRequirement/required}}
-                ::  Let |userVerification| be `true`.
-
-                :   is set to {{UserVerificationRequirement/preferred}}
-                ::  If the |authenticator|
-
-                    <dl class="switch">
-                        :   is capable of [=user verification=]
-                        ::  Let |userVerification| be `true`.
-
-                        :   is not capable of [=user verification=]
-                        ::  Let |userVerification| be `false`.
-                    </dl>
-
-                :   is set to {{UserVerificationRequirement/discouraged}}
-                ::  Let |userVerification| be `false`.
-
-            </dl>
-
-    1. Let |userPresence| be a Boolean value set to the inverse of |userVerification|.
-
-    1. Let |excludeCredentialDescriptorList| be a new [=list=].
-
-    1. [=list/For each=] credential descriptor |C| in <code>|options|.{{PublicKeyCredentialCreationOptions/excludeCredentials}}</code>:
-        1. If <code>|C|.{{transports}}</code> [=list/is not empty=], and |authenticator| is connected over a transport not
-            mentioned in <code>|C|.{{transports}}</code>, the client MAY [=continue=].
-        1. Otherwise, [=list/Append=] |C| to |excludeCredentialDescriptorList|.
-
-<!-- @@EDITOR-ANCHOR-01A: KEEP THIS LIST SYNC'D WITH THE LIST UP AT @@EDITOR-ANCHOR-01B -->
-    1. Invoke the [=authenticatorMakeCredential=] operation on |authenticator| with
-        |clientDataHash|,
-        <code>|options|.{{PublicKeyCredentialCreationOptions/rp}}</code>, <code>|options|.{{PublicKeyCredentialCreationOptions/user}}</code>,
-        <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{AuthenticatorSelectionCriteria/requireResidentKey}}</code>,
-        |userPresence|,
-        |userVerification|,
-        |credTypesAndPubKeyAlgs|,
-        |excludeCredentialDescriptorList|,
-        and |authenticatorExtensions| as parameters.
-
-    1. [=set/Append=] |authenticator| to |issuedRequests|.
-
-1. [=While=] |lifetimeTimer| has not expired, perform the following actions depending upon |lifetimeTimer| and responses from the
-    authenticators:
+1. [=While=] |lifetimeTimer| has not expired, perform the following actions depending upon |lifetimeTimer|,
+    and the state and response [=set/for each=] |authenticator| in |authenticators|:
     <dl class="switch">
         :   If |lifetimeTimer| expires,
         ::  [=set/For each=] |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation on |authenticator|
@@ -1013,7 +957,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
             1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}</code> is [=present=]:
 
                   1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{authenticatorAttachment}}</code> is
-                    [=present|present=] and its value is not equal to |authenticator|'s attachment modality, [=iteration/continue=].
+                    [=present|present=] and its value is not equal to |authenticator|'s [=attachment modality=], [=iteration/continue=].
                   1. If <code>|options|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{requireResidentKey}}</code> is set to
                     [TRUE] and the |authenticator| is not capable of storing a [=Client-Side-Resident Credential Private Key=],
                     [=iteration/continue=].
@@ -1892,6 +1836,10 @@ attributes.
     };
 </xmp>
 
+This enumeration is used to describe the [=attachment modality=] of an [=authenticator=] used to create a [=public key
+credential|credential=] - either by the [=[RP]=] to express a preferred [=attachment modality=], or by the [=client=] to report
+the [=attachment modality=] of an [=authenticator=] that was used.
+
 <div dfn-type="enum-value" dfn-for="AuthenticatorAttachment">
     :   <dfn>platform</dfn>
     ::  This value indicates [=platform attachment=].
@@ -1900,9 +1848,6 @@ attributes.
     ::  This value indicates [=cross-platform attachment=].
 </div>
 
-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
 authenticating using other [=clients=]; or to specifically register a [=platform credential=] for easier reauthentication using a
@@ -2472,9 +2417,10 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti
 
 ## Authenticator taxonomy ## {#sctn-authenticator-taxonomy}
 
-Different kinds of [=authenticators=] enable different use cases along two independent dimensions: the [=authentication ceremony
-structure=] and the [=authenticator=]'s [=attachment modality=]. The [figure below](#fig-authData) illustrates how the use cases
-relate to different kinds of [=authenticators=].
+[=Authenticator=] types vary along several different dimensions: [=attachment modality=], employed [=transport=](s), whether they
+are [=user verification=]-capable or only [=test of user presence|detect any user's presence=], and whether they support
+[=client-side-resident credential private keys=] or not. These dimensions enable various use cases known as [=authentication
+ceremony structures=].
 
 <figure id="fig-authenticator-taxonomy">
     <img src="images/authenticator-taxonomy.svg"/>
@@ -2497,10 +2443,7 @@ The following discussion assumes that the [=[RP]=] can verify the security guara
 [=attestation statements=] generated by the [=authenticator=]. In particular, the [=[RP]=] cannot trust that the [=authenticator=]
 can verify [=something you know=] or [=something you are=] unless these properties can be derived from the [=attestation
 statement=]. Thus, an [=authenticator=] that cannot provide such an [=attestation statement=] can only enable the [=second-factor
-use case=].
-
-Issue: Add "See also 'Ignoring attestation'" to the preceding paragraph if/when PR
-[#829](https://github.com/w3c/webauthn/pull/829) is merged. Delete this issue if PR #829 is closed.
+use case=]. See also [[#sctn-no-attestation-security-attestation]].
 
 - In the <dfn>second-factor use case</dfn> the user initiates an [=authentication ceremony=] by entering their [=username=] and
     password. The [=[RP]=] then looks up the [=credential IDs=] registered for this user, requests an [=assertion=] by one of
@@ -2543,17 +2486,16 @@ Issue: Add "See also 'Ignoring attestation'" to the preceding paragraph if/when
 [=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>
+and communicate with [=cross-platform attachment|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>.
+
+- 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>.
+
+- 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>.
 
 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