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

mikewest commented on this pull request.

This is looking good, thanks for taking another pass!

> @@ -1408,18 +1469,50 @@ for each associated <a for="fetch group">fetch record</a> whose
 <a>connection</a> is identified by an <b>origin</b> (an
 <a for=/>origin</a>) and <b>credentials</b> (a boolean).
 
+<h4 id=connection-reuse>HTTP/2 Connection Reuse</h4>

This section can probably be broken out into a separate patch. I think you'll also want to do a little more work on the definition of "connection" above, perhaps changing things such that a connection has a set of origins rather than a single origin. Further, the text in this section could be added as a note rather than a new section, with the change to step 1 of "obtain a connection" below constituting the normative change.

That is, something like:

> A [=connection=] has an <dfn for="connection">origin list</dfn>, which is a [=set=] of [=origins=] for which the connection is valid.
>
> Note: HTTP/2 allows connections to be reused for multiple origin servers, as described in Section 9.1 of HTTP/2.

and 

> 1.  If connection pool contains a connection whose [=connection/origin list=] contains origin, and credentials ...
>
> 2.  ...
>
> 3.  Set |connection|'s [=connection/credentials=] to |credentials|.
>
> 4.  Append |origin| to |connection|'s [=connection/origin list=].
>
> 5.  If |connection| was established using a TLS certificate with multiple `subjectAltName` attributes, then.... (oh no, we need to deal with wildcards this is complicated oh no).

That last bit obviously needs some work, but since it's pretty orthogonal to the rest of this patch, it's worth doing that work in a separate PR. :)


>  
  <li>
   <p>Let <var>connection</var> be the result of establishing an HTTP connection to
-  <var>origin</var>. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]
+  <var>origin</var>. [[!HTTP]] [[!HTTP2]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]
+
+  <p>If <var>credentials</var> is true and if the user agent supports <a for=/>Token Binding</a>,
+  propose the use of <a for=/>Token Binding</a> while setting up a TLS connection by sending the
+  highest supported <a for=/>Token Binding</a> protocol version and supported cryptographic
+  algorithms and parameters (the
+  <dfn export id=concept-token-binding-key-parameters>token-binding key parameters</dfn>) in a

Nit: I'd suggest moving this definition out of this algorithm, and into the "Token Binding" section below. Defining things inline is confusing, and I'd prefer for this section to read more like "If |credentials| is true and the user agent supports [=token binding=], send [=token-binding key parameters=] in a `token_binding` Client Hello Extension, as described in  ..."

>  
  <li>
   <p>Let <var>connection</var> be the result of establishing an HTTP connection to
-  <var>origin</var>. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]
+  <var>origin</var>. [[!HTTP]] [[!HTTP2]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]
+
+  <p>If <var>credentials</var> is true and if the user agent supports <a for=/>Token Binding</a>,
+  propose the use of <a for=/>Token Binding</a> while setting up a TLS connection by sending the
+  highest supported <a for=/>Token Binding</a> protocol version and supported cryptographic
+  algorithms and parameters (the
+  <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.

"update metadata" is still hand-wavey, but as per @annevk's comments at https://github.com/whatwg/fetch/pull/325#discussion_r104139324, I'm not sure we can do much more if we put things on the TLS connection.

For the purposes of clarity in Fetch, would it be reasonable to make this a property on "connection" instead, so that it's clear where the data is coming from when we use it below?

> +  <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.

How about: "Token Binding is only proposed when |credentials| is true, so connections which successfully negotiate a binding will never be pooled with connections that do not include credentials. Also, note that the token-binding key used for a specific request depends on the origin of the request's url, not on the connection. Even if multiple endpoints are coalesced into a single HTTP/2 connection, each will use a distinct token-binding key."

> +user agent. This association mitigates the risk that attackers can steal the token and use it
+themselves, as they will not be able to easily replicate the user agent's secret,
+and therefore cannot replicate the cryptographic binding of the token.
+
+<p>Details are described in TOKBIND-NEGOTIATION, TOKBIND-PROTOCOL and
+TOKBIND-HTTPS and integration is defined here.
+[[TOKBIND-NEGOTIATION]], [[TOKBIND-PROTOCOL]], and [[TOKBIND-HTTPS]].
+
+<p>A <dfn export id=token-binding-id>token binding ID</dfn> is the non-secret representation
+of a <a for=/>token-binding key</a>, as described in
+<a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.2">section 3.2</a>
+of [[TOKBIND-PROTOCOL]].
+
+<p>At a very high level, a user agent negotiates the use of Token Binding with the server when it
+sets up a TLS connection to the server, and saves metadata (the Token Binding protocol version and
+<a for=/>token-binding key parameters</a> resulting from the Token Binding negotiation) for the

As noted above, I'd suggest moving the definition of "token-binding key parameters" here, and pointing off to the ID for detail.

> +(e.g., an identity provider) are presented by the user agent to a different server
+(e.g., a relying party).
+[[TOKBIND-PROTOCOL]] and [[TOKBIND-HTTPS]] describe support for Federated Token Binding.
+
+<p>A <dfn export id=referred-token-binding-id>referred-token-binding ID</dfn> is the
+<a for=/>token binding ID</a> for a server other than the server to which the <a for=/>request</a>
+is being sent.
+
+Script code from an <a for=/>origin</a> can set a <a for=/>request</a>'s
+<a for=request>use-referred-token-binding flag</a> to ask the user agent to send
+the <a for=/>token binding ID</a> for that <a for=/>origin</a> as a
+<a for=/>referred-token-binding ID</a>
+in the <a for=/>Token Binding Message</a> sent to a target server.
+
+Alternately, servers that redirect a user agent to a different server can use the
+`<code>Include-Referred-Token-Binding-ID</code>` <a for=response>header</a>.

Nit: Wrap the header in `<dfn http-header>...</dfn>`

> +<ol>
+ <li><p>Let <var>keyDomainName</var> be null.
+
+ <li><p>If <var>tokenBindingOrigin</var>'s host is an IP address, set <var>keyDomainName</var> to
+ <var>tokenBindingOrigin</var>'s host.
+
+ <p>Otherwise, set <var>keyDomainName</var> to the registrable domain of
+ <var>tokenBindingOrigin</var>'s host, determined by running the steps in the Algorithm section of
+ <a href=https://publicsuffix.org/list/>Public Suffix List</a>
+ [[PUBLIC-SUFFIX]]
+
+ <li><p>Let <var>tokenBindingKeyPair</var> be null.
+
+ <li><p>Set <var>tokenBindingKeyPair</var> to the result of looking up the
+ <a for=/>token-binding key</a> pair for <var>keyDomainName</var> in the
+ <a for=/>token-binding key</a> store.

This store needs to be defined somewhere. Credential Management does this via https://w3c.github.io/webappsec-credential-management/#concept-credential-store. Given that these keys need to be cleared out along with cookies, it might make sense for them to live alongside cookies in network storage (https://storage.spec.whatwg.org/#infrastructure)?

I'm not sure whether that's worth doing here: @annevk might have opinions.

> +`<code>Include-Referred-Token-Binding-ID</code>` <a for=response>header</a> in the redirect
+<a for=/>response</a>, by adding a <a for=/>referred-token-binding ID</a> in the
+<a for=/>Token Binding Message</a> that is created when the <a for=/>request</a>
+is sent to the target server.
+
+<h4 id=getting-token-binding-key>Getting a Token Binding Key</h4>
+
+<p>Get the <a for=/>token-binding key</a> for an <a for=/>origin</a> <var>tokenBindingOrigin</var>
+and <a for=/>token-binding key parameters</a> <var>tokenBindingKeyParameters</var>,
+using the user agent's <a for=/>token-binding key</a> store, by running these substeps:
+
+<ol>
+ <li><p>Let <var>keyDomainName</var> be null.
+
+ <li><p>If <var>tokenBindingOrigin</var>'s host is an IP address, set <var>keyDomainName</var> to
+ <var>tokenBindingOrigin</var>'s host.

Nit: `If |tokenBindingOrigin|'s [=origin/host=] is an [=IPv4 address=] or an [=IPv6 address=], ...`

> +using the user agent's <a for=/>token-binding key</a> store, by running these substeps:
+
+<ol>
+ <li><p>Let <var>keyDomainName</var> be null.
+
+ <li><p>If <var>tokenBindingOrigin</var>'s host is an IP address, set <var>keyDomainName</var> to
+ <var>tokenBindingOrigin</var>'s host.
+
+ <p>Otherwise, set <var>keyDomainName</var> to the registrable domain of
+ <var>tokenBindingOrigin</var>'s host, determined by running the steps in the Algorithm section of
+ <a href=https://publicsuffix.org/list/>Public Suffix List</a>
+ [[PUBLIC-SUFFIX]]
+
+ <li><p>Let <var>tokenBindingKeyPair</var> be null.
+
+ <li><p>Set <var>tokenBindingKeyPair</var> to the result of looking up the

What happens if |tokenBindingKeyParameters| doesn't match the |tokenBindingKeyPair| stored for the origin (e.g. a server decides that it doesn't like a given algorithm anymore)?

> +
+<h4 id=computing-token-binding-header-value>Computing a Token Binding Header Value</h4>
+
+<p>If the user agent supports <a for=/>Token Binding</a>, build the value that can be passed
+in a `<code>Sec-Token-Binding</code>` <a for=/>header</a> for a <a for=/>request</a>
+<var>httpRequest</var> and a <a>connection</a> <var>tlsConnection</var>,
+using the <a for=/>token-binding key</a> store and the
+<a for=connection>connection pool</a>, by running these substeps:
+
+<ol>
+ <li><p>If <var>httpRequest</var>'s <a for=request>use-token-binding flag</a> is not set,
+ then return null.
+
+ <li><p>Initialize <var>tokenBindingMessage</var> to null.
+
+ <li><p>If Token Binding was not negotiated for <var>tlsConnection</var>, return null.

Style nit: I'd write these as "Return null if any of the following are true:" followed by a list. Kinda like step 10 or 17 of https://fetch.spec.whatwg.org/#main-fetch.

> +of the Token Binding over HTTP spec [[TOKBIND-HTTPS]].
+
+<p>By setting the `<code>Include-Referred-Token-Binding-ID</code>` <a for=response>header</a> to
+`<code>true</code>` in the redirect response, the <a for=request>origin</a> that
+sends the redirect <a for=/>response</a> (the "referring <a for=request>origin</a>" in the
+<a for=/>Token Binding</a> sense) tells the user agent to disclose the
+<a for=/>token binding ID</a> used by the user agent for that <a for=request>origin</a>
+to the target <a for=request>origin</a>. The user agent does this while processing the
+`<code>Include-Referred-Token-Binding-ID</code>` <a for=response>header</a> in the redirect
+<a for=/>response</a>, by adding a <a for=/>referred-token-binding ID</a> in the
+<a for=/>Token Binding Message</a> that is created when the <a for=/>request</a>
+is sent to the target server.
+
+<h4 id=getting-token-binding-key>Getting a Token Binding Key</h4>
+
+<p>Get the <a for=/>token-binding key</a> for an <a for=/>origin</a> <var>tokenBindingOrigin</var>

It would be helpful to have `<dfn abstract-op>Get the token-binding key for an origin</dfn>` somewhere in this text so that you can link to it from the algorithms below.

> +using the <a for=/>token-binding key</a> store and the
+<a for=connection>connection pool</a>, by running these substeps:
+
+<ol>
+ <li><p>If <var>httpRequest</var>'s <a for=request>use-token-binding flag</a> is not set,
+ then return null.
+
+ <li><p>Initialize <var>tokenBindingMessage</var> to null.
+
+ <li><p>If Token Binding was not negotiated for <var>tlsConnection</var>, return null.
+
+ <li><p>Let <var>providedTokenBindingKeyPair</var> be the result of getting the
+ <a for=/>token-binding key</a> for the <a for=/>origin</a> of <var>httpRequest</var>'s
+ <a for=request>current url</a> and <var>tlsConnection</var>'s
+ <a for=/>token-binding key parameters</a> metadata, obtained by following the steps in the
+ <a href=#getting-token-binding-key>Getting a Token Binding Key</a> section of this document.

As above, this step can explicitly call out to the "get the token-binding key for an origin" algorithm, which you can do once it's a real `<dfn>`. Then you won't need this indirection of "follow the steps over here".

> + <li><p>Let <var>providedTokenBindingKeyPair</var> be the result of getting the
+ <a for=/>token-binding key</a> for the <a for=/>origin</a> of <var>httpRequest</var>'s
+ <a for=request>current url</a> and <var>tlsConnection</var>'s
+ <a for=/>token-binding key parameters</a> metadata, obtained by following the steps in the
+ <a href=#getting-token-binding-key>Getting a Token Binding Key</a> section of this document.
+
+ <li><p>Let <var>providedTokenBindingId</var> be the result of computing a
+ <a for=/>token binding ID</a> from <var>providedTokenBindingKeyPair</var>,
+ as described in
+ <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.2">section 3.2</a>
+ of [[!TOKBIND-PROTOCOL]].
+
+ <li><p>Let <var>providedTokenBinding</var> be the result of computing a <a for=/>token binding</a>
+ using <var>providedTokenBindingId</var> and type <code>provided_token_binding</code>,
+ containing a signature (using <var>providedTokenBindingKeyPair</var>) over the
+ <var>providedTokenBindingId</var> as well as <var>tlsConnection</var>'s Exported Keying Material,

Perhaps we should list the EKM as a property of "connection". Again, I'll defer to @annevk about how much TLS detail he wants to bring into Fetch.

> +
+ <li><p>Let <var>providedTokenBinding</var> be the result of computing a <a for=/>token binding</a>
+ using <var>providedTokenBindingId</var> and type <code>provided_token_binding</code>,
+ containing a signature (using <var>providedTokenBindingKeyPair</var>) over the
+ <var>providedTokenBindingId</var> as well as <var>tlsConnection</var>'s Exported Keying Material,
+ as described in
+ <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+ of [[!TOKBIND-PROTOCOL]].
+
+ <li><p>Set <var>tokenBindingMessage</var> to a list containing <var>providedTokenBinding</var>
+ as the only <a for=/>token binding</a>.
+
+ <li><p>If <var>httpRequest</var>'s <a for=request>use-referred-token-binding flag</a> is set,
+ then run these substeps:
+  <ol>
+   <li><p>Let <var>referredTlsConnection</var> be the result of getting a TLS connection for

Nit: The algorithm is called "obtain a connection", let's stick with that terminology and link to the algorithm (e.g. "... be the result of [=obtain a connection|obtaining a connection=]").

> + using <var>providedTokenBindingId</var> and type <code>provided_token_binding</code>,
+ containing a signature (using <var>providedTokenBindingKeyPair</var>) over the
+ <var>providedTokenBindingId</var> as well as <var>tlsConnection</var>'s Exported Keying Material,
+ as described in
+ <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+ of [[!TOKBIND-PROTOCOL]].
+
+ <li><p>Set <var>tokenBindingMessage</var> to a list containing <var>providedTokenBinding</var>
+ as the only <a for=/>token binding</a>.
+
+ <li><p>If <var>httpRequest</var>'s <a for=request>use-referred-token-binding flag</a> is set,
+ then run these substeps:
+  <ol>
+   <li><p>Let <var>referredTlsConnection</var> be the result of getting a TLS connection for
+   <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a>
+   with credentials <code>true</code> from the <a for=connection>connection pool</a>.

`for=/`, right? The connection pool is not a property of the connection.

> + as described in
+ <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+ of [[!TOKBIND-PROTOCOL]].
+
+ <li><p>Set <var>tokenBindingMessage</var> to a list containing <var>providedTokenBinding</var>
+ as the only <a for=/>token binding</a>.
+
+ <li><p>If <var>httpRequest</var>'s <a for=request>use-referred-token-binding flag</a> is set,
+ then run these substeps:
+  <ol>
+   <li><p>Let <var>referredTlsConnection</var> be the result of getting a TLS connection for
+   <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a>
+   with credentials <code>true</code> from the <a for=connection>connection pool</a>.
+
+   <li><p>If Token Binding was not negotiated for <var>referredTlsConnection</var>,
+   set <var>referredTokenBinding</var> to null.

Steps like this are an argument for putting the metadata on the connection in Fetch, as we can then just check whether metadata is available, as opposed to hand-waving about whether or not token binding was negotiated.

> + then run these substeps:
+  <ol>
+   <li><p>Let <var>referredTlsConnection</var> be the result of getting a TLS connection for
+   <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a>
+   with credentials <code>true</code> from the <a for=connection>connection pool</a>.
+
+   <li><p>If Token Binding was not negotiated for <var>referredTlsConnection</var>,
+   set <var>referredTokenBinding</var> to null.
+
+   <li><p>If Token Binding was negotiated for <var>referredTlsConnection</var> then:
+    <ol>
+    <li><p>Let <var>referredTokenBindingKeyPair</var> be the result of getting the Token Binding
+    key for <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a>
+    and <var>referredTlsConnection</var>'s <a for=/>token-binding key parameters</a> metadata,
+    obtained by following the steps in the
+    <a href=#getting-token-binding-key>Getting a Token Binding Key</a> section of this document.

Again, we can link to the algorithm as above.

> +
+    <li><p>Let <var>referredTokenBindingId</var> be the result of computing a
+    <a for=/>token binding ID</a> from <var>referredTokenBindingKeyPair</var>,
+    as described in
+    <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.2">section 3.2</a>
+    of [[!TOKBIND-PROTOCOL]].
+
+    <li><p>Let <var>referredTokenBinding</var> be the result of computing a
+    <a for=/>token binding</a> using <var>referredTokenBindingId</var> and type
+    <code>referred_token_binding</code>, containing a signature
+    (using <var>referredTokenBindingKeyPair</var>) over the <var>referredTokenBindingId</var>
+    as well as <var>tlsConnection</var>'s Exported Keying Material,
+    as described in
+    <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+    of [[!TOKBIND-PROTOCOL]].
+    </ol>

Nit: Indentation is off.

> +    <a for=/>token binding ID</a> from <var>referredTokenBindingKeyPair</var>,
+    as described in
+    <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.2">section 3.2</a>
+    of [[!TOKBIND-PROTOCOL]].
+
+    <li><p>Let <var>referredTokenBinding</var> be the result of computing a
+    <a for=/>token binding</a> using <var>referredTokenBindingId</var> and type
+    <code>referred_token_binding</code>, containing a signature
+    (using <var>referredTokenBindingKeyPair</var>) over the <var>referredTokenBindingId</var>
+    as well as <var>tlsConnection</var>'s Exported Keying Material,
+    as described in
+    <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+    of [[!TOKBIND-PROTOCOL]].
+    </ol>
+
+   <li><p>If <var>referredTokenBinding</var> is not null, add it to

s|add|[=list/append=]|g

> +    as well as <var>tlsConnection</var>'s Exported Keying Material,
+    as described in
+    <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+    of [[!TOKBIND-PROTOCOL]].
+    </ol>
+
+   <li><p>If <var>referredTokenBinding</var> is not null, add it to
+   <var>tokenBindingMessage</var>.
+  </ol>
+
+  <li><p>If <var>tokenBindingMessage</var> is not null, compute and return its base64url-encoding
+  [[!RFC4648]]. Otherwise return null.
+</ol>
+Details of how to create a <a for=/>Token Binding Messsage</a> are described in
+<a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3">section 3</a>
+of [[!TOKBIND-PROTOCOL]].

Perhaps you can merge this note with the final step above? That is, "... compute and return its base64url-encoding as described in section 3 of TOKBIND-PROTOCOL."

> @@ -3261,6 +3598,9 @@ steps:
      <li>If <var>cookies</var> is not the empty string, append
      `<code>Cookie</code>`/<var>cookies</var> to <var>httpRequest</var>'s
      <a for=request>header list</a>.
+
+     <li><p>If the user agent supports <a for=/>Token Binding</a>,

I'd drop this, here and elsewhere: user agents that don't support token binding won't set the header because they're not compliant with the spec. The spec shouldn't carve out normative requirements like this.

> @@ -3492,6 +3832,23 @@ steps:
  <li><p>If <var>connection</var> is failure, return a
  <a>network error</a>.
 
+
+  <li><p>If the user agent supports <a for=/>Token Binding</a>, and
+  <var>request</var>'s <a for=request>use-token-binding flag</a> is set,

I think you can drop the `use-token-binding flag` entirely, and just rely on the credentials flag and "user agent is configured to block cookies" here.

> @@ -966,6 +992,41 @@ for other values. If <cite>HTML</cite> changes here, this standard will need cor
 Unless stated otherwise, it is unset.
 
 <p>A <a for=/>request</a> has an associated
+<dfn export for=request id=concept-request-use-token-binding>use-token-binding flag</dfn>.
+Unless stated otherwise, it is unset.
+
+<p class="note no-backref"><a for=/>Request</a>'s <a for=request>use-token-binding flag</a>
+controls whether the user agent will send the <a for=/>token binding ID</a> for the
+<a for=request>origin</a> of the <a for=/>request</a>'s url when it transmits the
+<a for=/>request</a> to the server. The <a for=/>token binding ID</a> can be used by the server to,
+e.g., bind HTTP cookies or OAuth tokens that it issues to the user agent.
+
+<p>A <a for=/>request</a> has an associated
+<dfn export for=request id=concept-request-use-referred-token-binding>use-referred-token-binding flag</dfn>.

Do you need this flag? Could you just set the referred-token-binding origin instead, and branch on it being `null` vs an origin?

-- 
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#pullrequestreview-36247757