We are in favor of doing this in SAML. We will implement it. I can help out.
In general our preference is for the most minimal changes. I will find out about any dev preferences and if we reject multiple confirmation methods.
Hal
-----Original Message-----
From: Cantor, Scott [mailto:cantor.2@osu.edu]
Sent: Tuesday, August 30, 2016 12:44 PM
To: SAML
Subject: [security-services] Token binding
Follow up for Hal, etc.
I'd like to find out what, if any, plans implementers might have for the Token Binding work coming out of IETF that is close to finalization. [1]
The work is a TLS extension that allows supporting HTTP clients to prove possession of a private key, so it can be leveraged by higher level apps on top of HTTP. The initial application is mainly cookies, but it includes support for referred token bindings so that third party token issuers (IdPs) can include bindings in the tokens they issue.
I believe SAML implementations need to support this or become irrelevant because the security benefits of having key-bound tokens are fairly obvious, and I certainly plan to support it, but I'm interested in the how and who of that at this point.
It fits naturally in a couple of different places, one being SubjectConfirmation obviously, but it's also possible to use the ChannelBinding extension I defined. One of my concerns is the work involved in having to produce a new SSO profile in SAML. Getting this defined as a new GSS-API channel binding type in IETF may be less work for me, and I also think it has value to GSS-API anyway.
-- Scott
[1] https://datatracker.ietf.org/wg/tokbind/documents/