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

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

> First, the HoK Web Browser SSO Profile specifies (lines 384--385) that
> the <samlp:AuthnRequest> element MAY be signed, yet Core specifies
> (lines 2012--2013) that the <samlp:AuthnRequest> element SHOULD be
> signed.

I think core is seriously overstating the case. It's a binding-specific or
even profile-specific question. I'd have to look, but it's probably text
inherited from ID-FF.

> "If the <samlp:AuthnRequest> is not authenticated and integrity
> protected, the information in it MUST NOT be trusted except as
> advisory."

That's the problem. An IdP rarely if ever "trusts" a request so it's kind of
moot.

> Sorry, I do not understand the above requirement.  To make matters
> worse, the HoK Web Browser SSO Profile specifically recommends against
> signing in the section on Security and Privacy Considerations (lines
> 522--523).  How do we reconcile this apparent discrepancy with regard
> to request signing?  What are the proper requirements with respect to
> signing the AuthnRequest?

Well, I don't know if I'd go so far as to recommend against it, but I
haven't ever seen a particularly compelling reason to do it either, at least
not front-channel.

> I know the language in the HoK Web Browser SSO Profile is
> intentionally similar to that in the ordinary Web Browser SSO Profile,
> but is there really a use case for multiple <saml:AuthnStatement>
> elements?

One issue is that you don't really gain much by limiting it. The challenge
is dealing with the fact that you can get multiple assertions and multiple
confirmation methods, and limiting the statements doesn't fix that.

In retrospect, I think the changes involving the Statement/Subject
relationship and the explicit requirement that every assertion refer to the
same principal has mitigated some of the original motivation for being so
loose about this in the text. It started more complex, got simplifiable, but
then was never actually simplified. But I would stand by the point that it
doesn't get much simpler anyway.

-- Scott