W3C home > Mailing lists > Public > public-xmlsec@w3.org > March 2009

Re: Transform Note Design Decisions

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 30 Mar 2009 15:09:17 -0700
Message-ID: <49D1430D.4080404@oracle.com>
To: Scott Cantor <cantor.2@osu.edu>
CC: "'Frederick Hirsch'" <frederick.hirsch@nokia.com>, "'Thomas Roessler'" <tlr@w3.org>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
We don't have a requirement for pure inclusive C14N, but we have some 
WSS interop scenarios where all the prefixes are listed in the 
InclusiveNamespacePrefixList , so it kind of becomes Inclusive C14N.

Because of this requirement to support exclusive C14N with some 
inclusive prefixes, we need to distinguish between namespaces that are 
explicitly declared and those that inherited from nodes outside the 
document subset. So the optimization of the input tree having all 
namespaces, and none extra would not really work.

Pratik

Scott Cantor wrote:
> Pratik Datta wrote on 2009-03-30:
>   
>> E.g. consider a signed SAML assertion.   The declaration for the saml
>> namespace may be in the <saml:Assertion> itself, or in the
>> <wsse:Security> ancestor element. Also the wsse:Security element may
>> include other namespace declaration that are not used inside the SAML
>> assertion.   The saml assertion should be movable from one message to
>> another without breaking the signature.
>>
>> So we need to support all the namespace complexity with Exclusive C14N,
>> Exclusive C14N with InclusivePrefixList and Inclusive.
>>     
>
> Just curious, is there any actual use case for Inclusive once you've been
> forced to support Exclusive?
>
> Separate question...is there an optimization possible if one were to require
> that the input tree (or trees) was already carrying the right set of
> namespace declarations (and none that shouldn't be there)?
>
> -- Scott
>
>
>
>   
Received on Monday, 30 March 2009 22:10:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:57 GMT