RE: [security-services] Errata item? Clarifying [Want]AuthnRequestsSigned metadata setting

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

> Note that the SP can also define "WantAssertionsSigned", 
> where it means that the SP wants the IDP to sign the 
> Assertion XML element by including a <ds:Signature> element 
> in the assertion.  That is, I do NOT believe it means that 
> the assertion can also be "signed by inclusion" by putting it 
> (unsigned) inside a <samlp:Response> element and signing that 
> element.

It doesn't.

> At the interop, folks were using a true setting for 
> [Want]AuthnRequestsSigned to mean that the AuthnRequest 
> message is signed only in the context of the HTTP Redirect 
> Binding where the total URL with parameters is signed using 
> the mechanism specified in that binding. The AuthnRequest XML 
> element is NOT expected to contain a <ds:Signature> element.  

That's a requirement of that binding, yes.

>  Now I don't think this interpretation would necessarily be 
> the same if the message was carried in the POST or Artifact 
> bindings.  I assume that in those cases, the XML element 
> itself would be signed and include the ds:Signature> element.

Correct, although it's not clear that requesting signing is all that
valuable with artifact. Not impossible, I suppose, if you wanted a permanent
record of the request with signature.

> So the interpretation of the setting appears to be dependent 
> on which binding is being used.  This is clearly not the case 
> for the WantAssertionsSigned setting.  So we should at least 
> clarify this for folks.  That is, unless folks have a 
> different interpretation of what the settings mean.

What you wrote was my intent. The meaning of "sign" is in general not
binding dependent except for the special case of redirect where you would of
course not want to actually implement it by signing first, then removing it,
and re-signing the URL. But you could and it would be correct. ;-)

The assertion flag has nothing to do with bindings at all because bindings
generally carry protocol messages, not assertions.

-- Scott