Add support for federated token binding to fetch about fetch

[annevk]

I filed a couple of issues https://github.com/TokenBinding/Internet-Drafts/issues as some things were not entirely clear to me.

It seems there needs to be integration between Fetch and this draft where Fetch handles redirects (or is Include-Referer-Token-Binding-ID not relevant for the API?), where Fetch goes to the network (and "adds" HTTP headers), and with the API.

So we probably need to decide what bits of the processing model should be in Fetch and what should be handled in those drafts and then how to best divide that.

[balfanz]

Include-Referer-Token-Binding-ID shouldn't be relevant for this API. That's a different way for the RP to signal to the UA to reveal the referred token-binding to the IdP. Federation protocols that use redirects would use the Include-Referer-Token-Binding-ID header, and federation protocols that use XHRs would use whatever capabilities fetch exposes for that - but you wouldn't see RPs use both.

On the other hand, anything on the client that processes redirects should be aware of this new response header - if redirection logic is handled by fetch then I guess that's something that it should be aware of.

We'll have new versions of the Token Binding I-Ds out soon. We'll address the issues you and others have pointed out over there.

[annevk]

Yes, Fetch handles all requesting logic for the entire web platform, including redirects. Redirects are handled in step 4 of https://fetch.spec.whatwg.org/#http-fetch at the moment. Headers such as cookies and Referer are added at the network level here: https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch

I suspect both of these need to be modified somehow to account for Token-Binding. I suspect we want to update the concept of a request somehow with a flag that indicates that Token-Binding needs to be included in the request. (What happens if such a request results in a(nother) redirect?)

[annevk]

@balfanz do you need anything else from me?

[balfanz]

@annevk - any pointers as to how to get this moved to the next stage would be great. Should I attend a meeting somewhere?

As for the redirect question: I think we should include the referred token-binding only in the first request - the one that the 302 redirects to, or the one that the fetch() initially goes to.

[annevk]

We don't have meetings really, but I'm happy to chat if you think that helps.

If you search for "mixed content" in Fetch you'll find how it integrates with the Mixed Content specification. Ideally, we'd have something similar for federated token binding. A set of changes to the Fetch algorithm and API that integrates with the work done at the IETF.

[annevk]

A feature of Token Binding is that it couples requests with their connection. What is the impact of that on efforts to reuse connections across credentialed and non-credentialed requests (see #341)?

cc @vanupam @mikewest @yoavweiss @equalsJeffH @sleevi @jakearchibald

[sleevi]

Token Binding's predecessors (Channel ID, Origin Bound Certs) is why Chrome originally introduced the pooling it did. Token Binding's design (to be at the H/2 Req/Response layer) was particularly trying to address some of these deficiencies and make it easier to reuse the same connection. We have not yet modeled the privacy and security properties of referred Token Binding into the credentialed access case to determine what reuse or separation is needed. Since TB tries to mimic a request-oriented auth flow, hopefully the properties are similar.

[annevk]

Okay, that sounds somewhat promising. I got worried because in the PR there's talk about putting new properties on the connection, but I have not carefully studied the implications.

[annevk]

Closing as per #715 (comment).