Re: [security-services] question re saml-channel-binding-ext

[Rainer Hoerbe <rainer@hoerbe.at>]

> So the basic use case is to extend SAML to handle message content that allows SAML SSO over TLS to actually authenticate the TLS endpoints. If that's done, then a client and server actually know they're talking to each other, if they trust the SAML exchange, and the rest of the application session can be associated strongly with a TLS session if you don't put a bunch of TLS offloading hardware in the middle.

The problem of the abstract formulation that is required to cover general use cases is that it hides the intended short-term purpose. Both the Introduction (1) and Overview (2.2) are written from a HOW perspective, not addressing the WHY. 

Including your answer describing a use case (or may be a few more) would be quite helpful to add a viewpoint.

> 
> The profile that's actually in the document is a different animal of a specialized nature. I only included it as a thought experiment and because XML Encryption was such a mess that having a way to figure out if you have a confidential channel before you return data seemed like a nice trick.
> 
>> Also people might find it useful to get an overview of the use of channel
>> binding with respect to holder-of-key and bearer tokens.
> 
> Channel binding is too low level for that, it's a building block for other profiles to use. It doesn't directly involve assertions in and of themselves.

My understanding was that HoK-Borwser-SSO allows you to bind the assertion the the TLS channel. I see that binding the subject to a certificate is different to binding a secure channel, but on the use case level both look like competing approaches. 

- Rainer