OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] question on namespace definitions from ancestor element

Kyle Meadors wrote on 2009-07-15:
> Must an Assertion element be constructed so that it can be validated as a
> standalone element, outside of the enclosing Response element, with
> to its namespace definition?

No. It's a nice thing to do, but the only place there's any formal advice
about it is when you encrypt XML, the input is preferably well-formed.

> Or, should the SP be able to obtain the
> namespace definition from the Response ancestor if the prefix is defined
> PrefixList attribute of the InclusiveNamespaces element.

The PrefixList has nothing to do with SAML. That's a function of signature
integrity and has no meaning outside the context of signing or verification.
> One of the parties
> involved cited section 5.4.3 of SAML Core that the assertion should be
> validated independent of the Response.

I don't see how, and I would say that text is probably worded too strongly
anyway. Exclusive c14n doesn't "ensure" anything. It's necessary, but not
sufficient, for extraction and rewrapping to work, but so is proper
serialization of the content being repackaged (this case being an example).

In any case, whether assertions are intended to be usable beyond their
initial context is a profile function more than anything else. It would be
reasonable for such a profile to make suggestions or have requirements about
that kind of thing, but as a matter of implementation, it would be na´ve and
lazy in the extreme to expect that you could extract an assertion blindly
and have it "just work". It's just not that easy.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]