> What I believe is that the first half of this (metadata acceptance) will
> be significantly easier to implement in existing SAML software than the
> second part (application of the derived keys for SAML crypto). I'm not a
> SAML implementer, so I would be interested to hear the opinions of those
> of you who are!
I don't know if there are any others on the list yet, but it's definitely
true in my case, and I'm fairly sure it's true in the Java code the IdP
uses.
Though I would note that it's important to motivate the former with the
latter. Which is to say that if all you're trying to do is externalize the
signature from the document, there are other ways to accomplish that. XML
Signature supports detached signatures, for example, and SAML doesn't
preclude such things, it merely dictates how its own enveloped signatures
work.
A major advance (to some anyway) might be to come up with a model where some
of the information can be signed and some left to local control, but a
straight hash wouldn't do it.
-- Scott
PS. Something you also have to keep in mind is that the hash would either
have to be c14n-based, or tied to the (probably non-XML) transport encoding
of the metadata.
|