Subject: [Unbearable] Include-Referred-Token-Binding-ID redirects within a domain

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2016 13:30:57 -0600

What is the expected behavior when a browser receives a redirect with the
Include-Referred-Token-Binding-ID but is from and to URIs in the same TLD+1
and everyone is able to negotiate Token Binding? I don't think the
situation is explicitly covered in HTTPSTB.

For example, when a request made to https://application.example.com
receives an HTTP 302 that has Include-Referred-Token-Binding-ID:true with
https://idp.example.com as the location. Is only the provided token binding
sent by the browser to https://idp.example.com? Or are a provided and
referred token binding both sent (with the same token binding id)? Or
something else?

This situation is fairly common in federated SSO deployments today and,
depending on how things work from the HTTPSTB perspective, the referred
token binding alone might not be enough of a signal to the token provider
about what token binding ID to bind into the SSO token. The initial draft
of TB for OpenID Connect,
<http://self-issued.info/docs/openid-connect-token-bound-authentication-1_0-00.html>
for example, relies on the presence of the Referred Token Binding being
sent.

I guess I'm suggesting, so federated protocols that use HTTPSTB don't have
to have special treatment of this situation, that HTTPSTB explicitly say
that a redirect with the Include-Referred-Token-Binding-ID header signals
to the browser that it is to send a referred token binding on the resulting
request even when both resources fall under the same same TLD+1 and the
provided and referred token bindings would be the same.

---

From: Nick Harper <[email-masked]>
Date: Thu, 28 Jul 2016 22:12:06 -0700

On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell <[email-masked]
> wrote:

> https://idp.example.com as the location. Is only the provided token
> binding sent by the browser to https://idp.example.com? Or are a provided
> and referred token binding both sent (with the same token binding id)? Or
> something else?
>

It should send both. If it doesn't send both, then the idp has to check
other signals (e.g. Referer header) when it receives only a provided TB to
determine whether it should issue an unbound token or a token bound to the
provided (and in effect the referred) TB. I think it's easier for both the
client and the server if the client sends a referred TB even when the
eTLD+1 is the same.

> provided and referred token bindings would be the same.

This is how Chrome currently behaves, and matches what the the HTTPSTB spec
says, since the spec doesn't call for any special treatment when the token
bindings would be the same. I don't have any objections to the spec
clarifying this point.

>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 29 Jul 2016 14:37:10 -0600

Thanks for the response, Nick. Sounds like we're on the same page about how
it should work. While you already interpret the spec text in that way, I do
think there's some room for a different interpretation with the current
text. And a clarifying the point would help ensure consistent behavior from
different browsers. I'll put an issue in the github repo.

On Thu, Jul 28, 2016 at 11:12 PM, Nick Harper <[email-masked]> wrote:

>
> On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell <
> [email-masked]> wrote:
>
>> binding sent by the browser to https://idp.example.com? Or are a
>> provided and referred token binding both sent (with the same token binding
>> id)? Or something else?
>>
>
>> about what token binding ID to bind into the SSO token. The initial
>> draft of TB for OpenID Connect,
>> I guess I'm suggesting, so federated protocols that use HTTPSTB don't
>> have to have special treatment of this situation, that HTTPSTB explicitly
>> say that a redirect with the Include-Referred-Token-Binding-ID header
>> signals to the browser that it is to send a referred token binding on the
>> resulting request even when both resources fall under the same same TLD+1
>> and the provided and referred token bindings would be the same.
>>
>
> This is how Chrome currently behaves, and matches what the the HTTPSTB
> spec says, since the spec doesn't call for any special treatment when the
> token bindings would be the same. I don't have any objections to the spec
> clarifying this point.
>
>>