"Scott Cantor" <[log in to unmask]> writes:
>> Scott, I'm happy to work with you to figure out if channel binding
>> support is possible in your approach.
>
> I plan to take you up on it. To ease the process of comparing the
> approaches, I think it's easiest to produce a simple draft initially, which
> highlights some of the issues you mentioned, but leaves things as is for the
> same compatibility reasons that Klaas had. The result may be a merging of
> the proposals, or not.
>
> Related to this, for example, I'm in favor of supporting a way to tie the
> SAML assertion in the response to a key at the TLS layer (holder of key via
> client TLS, in other words). That's an addition to the SAML profile I'm
> basing this work on, which is why I'm not starting there, to simplify the
> compatibility story. I probably will go back to OASIS to get a HoK version
> of the ECP profile created, and then I can just reference it.
I would prefer if channel bindings is done in a GS2 compatible way, to
allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
By using the GS2 prefix, you also get support for authorization
identities.
If authors are interested here, I could help with the GS2 prefix part so
that it causes minimal confusion for non-GSS-API people and still allows
that variant. I made this suggestion for the OpenID SASL mechanism as
well.
/Simon
|