Subject: Re: [security-services] Token binding
I was thinking SubjectConfirmation however I do recall hearing that multiple confirmations blow up some implimentations.
One thing to remember is that the IdP won't get the refered token binding unless the SP actively sets the headder as part of the request (currently the request needs to be GET and not POST) so the IdP will know if the SP is expecting a token bound response.
Adding the logic to trigger the token binding might give people the chance to fix SubjectConfirmation, however we should probably poll people.
On 8/30/16, 1:50 PM, "John Bradley" <email@example.com> wrote:
> I am happy to contribute to standardizing it for SAML as well.
> I can’t say that it will be on Pings short term roadmap for SAML unless other SAML
> implementations pick it up.
There are various ways it might be done, so I would prefer other implementers planning to do it provide feedback on what they'd prefer.
As an example, we could obviously use SubjectConfirmation (either exclusively or in addition to Bearer), but if people tell me that their implementations (incorrectly) fail on multiple confirmations, then that's maybe not ideal.
Shibboleth is likely to support both SubjectConfirmation and the ChannelBinding extension eventually.