Adds authenticator attachement to credential options (w3c#243)

* Adds authenticator attachement to credential options

Closes issue w3c#213

* use Vijay's examples

* addressed Jeff's comments

* put back vijay's suggestion that got dropped

* addressed Jeff's comments

* closing div needed in dfn for Attachment. See w3c#243

* editorial tweak as per Jeff's comments

index.bs

@@ -428,13 +428,19 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
 9. Initialize |issuedRequests| to an empty list.
 
-10. For each authenticator currently available on this platform: asynchronously invoke the <a>authenticatorMakeCredential</a>
+10. If {{ScopedCredentialOptions/attachment}} is specified, let |attachment| be
+    {{ScopedCredentialOptions/attachment}}.  If |attachment| is null or empty,
+    reject |promise| with a DOMException whose name is "InvalidArgumentError".
+    Otherwise, only consider authenticators whose attachment is mentioned in
+    |attachment|.
+
+11. For each available authenticator: asynchronously invoke the <a>authenticatorMakeCredential</a>
     operation on that authenticator with |rpIdHash|, <a>clientDataHash</a>, {{accountInformation}}, |normalizedParameters|,
     {{ScopedCredentialOptions/excludeList}} and |clientExtensions| as parameters. Add a corresponding entry to |issuedRequests|.
     - For each credential C in {{ScopedCredentialOptions/excludeList}} that has a non-empty |transports| list, optionally use
         only the specified transports to test for the existence of C.
 
-11. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses
+12. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses
     from the authenticators:
     - If the |adjustedTimeout| timer expires, then for each entry in |issuedRequests| invoke the <a>authenticatorCancel</a>
         operation on that authenticator and remove its entry from the list.
@@ -621,8 +627,9 @@ authorizing an authenticator with which to complete the operation.
     dictionary ScopedCredentialOptions {
         unsigned long                             timeoutSeconds;
         USVString                                 rpId;
-        sequence < ScopedCredentialDescriptor >  excludeList;
+        sequence < ScopedCredentialDescriptor >   excludeList;
         WebAuthnExtensions                        extensions;
+        Attachment                                attachment;
     };
 </pre>
 
@@ -645,6 +652,50 @@ authorizing an authenticator with which to complete the operation.
         the credential, or that additional information be returned in the attestation statement. Alternatively, the caller may
         specify an additional message that they would like the authenticator to display to the user. Extensions are defined in
         [[#extensions]].
+
+    - The <dfn>attachment</dfn> parameter contains authenticator attachment descriptions, which are used as an additional
+        constraint on which authenticators are eligible to participate in a [[#makeCredential]] or [[#getAssertion]] operation.
+        See [[#attachment]] for a description of the attachment values and their meanings.
+
+</div>
+
+### Credential Attachment enumeration (enum <dfn enum>Attachment</dfn>) ### {#attachment}
+
+<pre class="idl">
+    enum Attachment {
+        "platform",
+        "cross_platform"
+    };
+</pre>
+
+<div dfn-for="Attachment">
+    Clients may 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 may use a variety of cross-platform transport
+    protocols such as Bluetooth (see [[#transport]] to discover and communicate
+    with authenticators.  We define authenticators that are part of the
+    client's platform as having a |platform| attachment, while those that are
+    reachable via standardized cross-platform transport protocols are defined
+    as having |cross_platform| attachment.  This distinction is important
+    because there are use-cases where only |platform| attached authenticators
+    are acceptable to a [RP], and conversely ones where only |cross_platform|
+    attached authenticators are employed.  As a concrete example of the former,
+    a credential on a platform authenticator may be used by [RPS] to quickly
+    and conveniently reauthenticate the user with a minimum of friction.  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 required to use a
+    cross-platform authenticator which was originally set up on a different
+    client.
+
+    <ul>
+        <li><dfn>platform</dfn> - the respective authenticator is attached
+            using platform-specific transports.  Usually, authenticators of
+            this class are non-removable from the platform.
+        <li><dfn>cross_platform</dfn> - the respective authenticator is attached
+            using cross-platform transports.  Authenticators of this class are
+            removable from the platform.
+    </ul>
 </div>