Re: [whatwg/fetch] Update Fetch to support Token Binding. (#325)

equalsJeffH commented on this pull request.



> +  <dfn export id=concept-token-binding-key-parameters>token-binding key parameters</dfn>) in a
+  <code>token_binding</code> Client Hello Extension, as described in
+  <a href="https://tools.ietf.org/html/draft-ietf-tokbind-negotiation#section-2">section 2</a>
+  of the Token Binding Negotiation spec [[!TOKBIND-NEGOTIATION]].
+  If Token Binding Negotiation succeeds, indicating client-server agreement on protocol version
+  and <a for=/>token-binding key parameters</a>, update metadata for the TLS connection with the
+  results of the negotiation.
+
+  <p class="note no-backref">
+  The user agent will use <a for=/>Token Binding</a> for any <a for=/>request</a> sent over
+  a TLS connection for which Token Binding Negotiation was successful.
+  Since <a for=/>Token Binding</a> is used only when <var>credentials</var> is true, such a
+  connection will not be pooled with connections that have <var>credentials</var> is
+  false. Also, <a for=/>Token Binding</a> is compatible with connection reuse - HTTP/2 requests to
+  different origin servers coalesced over the same connection will use different
+  <a for=/>token-binding key</a>s if needed.

Why would tokbind be negotiated only when |credentials| is true?  there are use cases, of which webauthn is one (fido UAF is another), where the protocol running over HTTP is including a Token Binding ID in its (signed) messages, and whether or not cookies are also being used is a completely separate thing (they may not be (unlikely, but possible) and we shouldn't mess that up). 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/325#discussion_r114879583