resolve conflicts with the new attachment-specific stuff

README.md

@@ -53,3 +53,5 @@ bikeshed echidna --u USERNAME --p PASSWORD --d DECISION_URL
 ```
 
 This will create a tarball of the HTML and images, and upload to Echidna. Status of the request can be tracked through the W3C API [as described in the Echidna documentation](https://github.com/w3c/echidna/wiki/How-to-use-Echidna). Note that on Windows, this will give an error about failing to delete a temporary file because it is in use by a different process. This error is harmless; it happens after the submission has completed.
+
+Overall info on echidna is here: https://github.com/w3c/echidna/wiki and here https://labs.w3.org/echidna/.

index.bs

@@ -4,6 +4,7 @@ Status: ED
 Prepare for TR: true
 TR: https://www.w3.org/TR/webauthn/
 ED: https://w3c.github.io/webauthn/
+Previous Version: https://www.w3.org/TR/2016/WD-webauthn-20161207/
 Previous Version: https://www.w3.org/TR/2016/WD-webauthn-20160928/
 Previous Version: https://www.w3.org/TR/2016/WD-webauthn-20160902/
 Previous Version: https://www.w3.org/TR/2016/WD-webauthn-20160531/
@@ -432,15 +433,20 @@ When this method is invoked, the user agent MUST execute the following algorithm
     any), to create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and
     compute the <a>clientDataJSON</a> and <a>clientDataHash</a>.
 
-8. Initialize |issuedRequests| to an empty list.
+8. Initialize |issuedRequests| and |currentlyAvailableAuthenticators| to empty lists.
 
-9. For each authenticator currently available on this platform: asynchronously invoke the <a>authenticatorMakeCredential</a>
+9. For each authenticator currently available on this platform, add the authenticator to |currentlyAvailableAuthenticators|
+    unless the {{ScopedCredentialOptions/attachment}} member of {{options}} is <a>present</a>. In that case, let |attachment| be
+    {{ScopedCredentialOptions/attachment}}, and add the authenticator to |currentlyAvailableAuthenticators| if its attachment
+    modality matches |attachment|.
+
+10. For each authenticator in |currentlyAvailableAuthenticators|: 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 the {{ScopedCredentialOptions/excludeList}} member of {{options}} that has a non-empty
-        |transports| list, optionally use only the specified transports to test for the existence of C.
+    - For each credential |C| in the {{ScopedCredentialOptions/excludeList}} member of {{options}} that has a non-empty
+        |transports| list, optionally use only the specified transports to test for the existence of |C|.
 
-10. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses
+11. 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.
@@ -456,7 +462,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
             remove its entry from the list.
         - Resolve |promise| with |value| and terminate this algorithm.
 
-11. Reject |promise| with a <a>DOMException</a> whose name is "NotAllowedError", and terminate this algorithm.
+12. Reject |promise| with a <a>DOMException</a> whose name is "NotAllowedError", and terminate this algorithm.
 
 During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and
 authorizing an authenticator.
@@ -631,6 +637,7 @@ authorizing an authenticator with which to complete the operation.
         unsigned long                           timeoutSeconds;
         USVString                               rpId;
         sequence < ScopedCredentialDescriptor > excludeList = [];
+        Attachment                              attachment;
         WebAuthnExtensions                      extensions;
     };
 </pre>
@@ -654,6 +661,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>
 
 
@@ -1185,6 +1236,34 @@ The authenticator MUST return both the <a>authenticatorData</a> and the raw sign
 MUST return <a>clientDataJSON</a>, <a>authenticatorData</a> and the signature to the RP. The first two are returned in the
 `clientData` and `authenticatorData` members respectively of the {{WebAuthnAssertion}} and {{WebAuthnAttestation}} structures.
 
+### Verifying a signature ### {#authenticator-signature-verification}
+
+This section specifies the algorithm for verifying a signature assertion.
+
+Upon receiving a signature assertion in the form of a {{WebAuthnAssertion}} structure, the [RP] shall:
+
+1. Perform JSON decoding to extract the {{ClientData}} used for the assertion from the {{WebAuthnAssertion/clientData}}.
+
+2. Verify that the {{ClientData/challenge}} in the {{ClientData}} matches the challenge that was sent to the authenticator.
+
+3. Verify that the {{ClientData/origin}} in the {{ClientData}} matches the [RP]'s origin.
+
+4. Verify that the {{ClientData/tokenBinding}} (if present) in the {{ClientData}} matches the token 
+    binding public key for the TLS connection
+    over which the attestation was obtained.
+
+5. Verify that the {{ClientData/extensions}} in the {{ClientData}} is a proper subset of the extensions requested by the RP.
+
+6. Verify that the RP ID hash in the {{WebAuthnAssertion/authenticatorData}} is indeed the SHA-256 hash of the RP ID expected
+    by the RP.
+
+7. Compute the <a>clientDataHash</a>, i.e. hash of {{WebAuthnAssertion/clientData}}.
+
+8. Look up the previously registered public key associated with the credential (see {{makeCredential()}}) and
+    verify the signature in {{WebAuthnAssertion/signature}} computed over the
+    binary concatenation of {{WebAuthnAssertion/authenticatorData}} and <a>clientDataHash</a>.
+
+If all the above steps succeed, then the signature is valid, otherwise it is invalid.
 
 ## Credential Attestation Statements ## {#cred-attestation-stmts}