Berin, well I don't know if it is the same reason as for encryption. During the discussion I also asked one of the WSS gurus about the topic. Here is his answer to my question:
<cite> This behaviour is absolutely necessary in order that exclusive canonicalization can function correctly in the case of changes to apex definitions of the default namespace. The canonicalization specifications should both have been defined to always emit apex xmlns=""; this lack introduces abstract security attacks against the default namespace which specifications such as &wsse; and &decrypt; have to work around with these ugly warts. </cite> from Merlin Hughes, Betrusted Does this info helps you? (I'm in no way an expert on this topic). Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Berin Lautenbach [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 28. Mai 2004 12:14 > An: [EMAIL PROTECTED] > Betreff: Re: AW: Question on c14n exclusive > > > Dittmann Werner wrote: > > > <cite> > > * Finally, employ the canonicalization method specified as > a parameter to the transform to > > serialize N to produce the octet stream output of this > transform; but, in place of any > > dereferenced <wsse:SecurityTokenReference> element Ri and > its descendants, > > process the dereferenced node set Ri' instead. During this > step, canonicalization of the > > replacement node set MUST be augmented as follows: > > o Note: A namespace declaration xmlns="" MUST be emitted > with every apex > > element that has no namespace node declaring a value for the default > > namespace; cf. XML Decryption Transform. > > </cite> > > As Raul indicates, this is counter to the c14n spec. > > Having said that - it's also in line with XML encryption, and > is used to > ensure that an encrypted xml "fragment" can be reparsed in > the original > namespace context. > > Is this the same reason here? If so, maybe we should augment > the c14n > class to allow for emmitting a xmlns="" at the apex node(s) > if appropriate? > > (We're going to need to do this sooner or later for xml encryption in > any case.) > > Cheers, > Berin >