atom feed8 messages in org.oasis-open.lists.security-servicesRe: [security-services] Token binding
FromSent OnAttachments
Cantor, ScottAug 30, 2016 9:44 am 
John BradleyAug 30, 2016 10:50 am 
Cantor, ScottAug 30, 2016 3:58 pm 
John BradleyAug 30, 2016 8:34 pm 
Hal LockhartSep 6, 2016 8:00 am 
Cantor, ScottSep 6, 2016 8:55 am 
John BradleySep 6, 2016 11:18 am 
Cantor, ScottSep 6, 2016 11:33 am 
Subject:Re: [security-services] Token binding
From:John Bradley (ve7@ve7jtb.com)
Date:Sep 6, 2016 11:18:48 am
List:org.oasis-open.lists.security-services

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