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

On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell <bcampbell@pingidentity.com
> wrote:

> 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?
>

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.

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

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
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>
>