RE: [security-services] comments: sstc-saml-holder-of-key-browser-sso-draft-03

["Scott Cantor" <cantor.2@osu.edu>]

> Well, for what it's worth, I reviewed Core and the schema yesterday,
> and there didn't seem to be anything that precluded an empty h-o-k
> SubjectConfirmation element.

The text I was speaking of is in profiles. The definition of HoK says "one
or more", and there's nothing in core that gets around that in some way.

I kind of think that's unfortunate, and without having read it lately, the
SAML Token Service profile might even be violating it. But for purposes of
the current discussion, I wanted to note that I don't think it's strictly
legal right now. Maybe something to fix.

> That's my point, an RP *can* examine the certificate further, there's
> nothing to prevent them from doing that.  They're not required to do
> so, however, and if they choose to do so, they risk interop for sure.

I think we can and should have something stronger than that. I don't pretend
to know exactly the right language, but it needs to clarify that the role of
a *SAML implementation* of the profile is to stop at the key. If an
application wants to do more, that's fine, but we shouldn't encourage the
SAML implementations to give people the rope to hang themselves.

-- Scott