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

Brian Campbell <bcampbell@pingidentity.com> Wed, 27 July 2016 19:31 UTC

MIME-Version: 1.0
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2016 13:30:57 -0600
Message-ID: <CA+k3eCQBubC1Cfzo2gtO_7ntw_pOVF7UQAukr-DcACkra-ivLA@mail.gmail.com>
To: IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fb6b03f93820538a3100f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/xMDHXYjH8WW2N-hifODLPqAa17w>
Subject: [Unbearable] Include-Referred-Token-Binding-ID redirects within a domain
Precedence: list

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.

Re: [Unbearable] Include-Referred-Token-Binding-I… Brian Campbell
Re: [Unbearable] Include-Referred-Token-Binding-I… Nick Harper
[Unbearable] Include-Referred-Token-Binding-ID re… Brian Campbell