[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Errata item? Clarifying [Want]AuthnRequestsSigned metadata setting
|
During the SAML 2.0 dry run in In Metadata, the IDPSSODescriptor has the setting called “WantAuthnRequestsSigned”
and the SPSSODescriptor has the setting called “AuthnRequestsSigned”.
But it’s ambiguous about “how” this signing is to be done.
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 is the Assertion XML element itself that is signed. I
don’t believe the same approach is what folks expect for the AuthnRequest
settings however. I think it is ambiguous and needs to be clarified. 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. 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. 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… Rob Philpott |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]