Re: XPath Transforms Deprecated in SAML 2.0

Thanx Michael for your prompt reply!

>I am not sure I understand. I don't see XPath mentioned there at all. I 
>assume you are referring to the statement:

Sorry if I was unclear.

>"Verifiers of signatures MAY reject signatures that contain other 
>transform algorithms as invalid. If they do not, verifiers MUST ensure 
>that no content of the SAML message is excluded from the signature. This 
>can be accomplished by establishing out-of-band agreement as to what 
>transforms are acceptable, or by applying the transforms manually to the 
>content and reverifying the result as consisting of the same SAML 
>message."

Yes. indeed this was the section that caused my concern.

>Are you looking to deprecate XPath as a transform algorithm? 

Absolutely not.  It seemed that OASIS SAML TC did that. More or less.

>I think SAML's requirements for signatures over assertions and messages - 
>while typical of many scenarios - do not cover all of the important 
>scenarios for XML Signatures. The SAML protocol does not allow any 
>transformation of an assertion or message between its generation and its 
>consumption. Other protocols (e.g. SOAP, workflows, etc.) require 
>allowance for these intermediate transformations of explicitly selected 
>subsets. We should also take these scenarios into account.

Absolutely.

>> I have one question though: Can anybody explain what InclusuveAttributes
>> does and what happens if it is not specified?  What prefixes should 
>> be specified?  Those that are a part of the signed message?

>I don't know the term InclusiveAttributes, do you mean 
>InclusiveNamespaces? If so, Section 3 of 
>http://www.w3.org/TR/xml-exc-c14n/ explains the processing in some detail 
>and Section 9.5 of 
>http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html makes an 
>attempt at interpreting what is expected to be placed into the PrefixList.

I screw up but you understood me anyway :-)

I must say that XML canonicalization must be one of the fuzziest things
I have ever read.  The description is probably just perfect, I'm just too
dumb to fully understand what's going on here:

<soap:Body
        xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
        wsu:Id='TheBody'  xmlns:bar="http://bar.com">
    <m:SomeElement xmlns:m='http://example.org/ws' foo='bar:none'/>
</soap:Body>

According to the ws-i doc, "bar" should be in InclusiveNamespaces but not "m".
Since both are declared, and referred to by the signed object (Body), this is not
entirely obvious unless you have a PhD in canonicalization.

Luckily enough, it seems that my design features no fancy XML, that could screw up,
so I believe I don't need InclusiveNamespaces.  But "dead-sure" is not the word I would
use at this stage.  In case you have an abundance of time, I enclosed a real signature
currently lacking InclusiveNamespaces.  The "only" thing I hope is that such signatures
can be stuffed in arbitrary other XML wrappers and still validate without requiring
"XML slicing".

I will add your name to "Acknowledgments" in case you don't mind.

regards
Anders Rundgren