Re: [security-services] Token binding

[John Bradley <ve7jtb@ve7jtb.com>]

I am not against the channel binding extension. 

We need to discuss what we want out of this.

In general the SP won’t know at the start of a SP initiated flow what the token binding ID is for the IdP, so it will be difficult to put that in a signed request.    

You could put the token binding ID for the SP in the signed request and then compare that to the referred token binding ID.  
That would have some value over just using the referred value, but I suspect people are as likely to do that as sign requests:)

The main SSO use case is for SP initiated where the SP includes a HTTP header to the browser that causes the browser to include the token binding ID for the SP in the token binding header sent to the IdP.

We could use either method to return that token binding ID back to the SP as part of the assertion.

Token binding the request will be a challenge, as well as token binding a IdP initiated SSO flow.

One way or another we will need to document something like a new SSO profile I suspect.

John B.

> On Sep 6, 2016, at 12:55 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> 
>> We are in favor of doing this in SAML. We will implement it. I can help out.
> 
> Thanks. I think if we use SubjectConfirmation we really don't have much choice but to create a new SSO profile, so it is a somewhat heavyweight approach.
> 
> -- Scott
> 
>