On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana <[email protected]>wrote:
> Oh I wasn't try to divert stuff with you dude .. I definitely know you > well enough for that. > > Neither am I at all proposing default behavior - I think the only "fix" is > to have an option to serialize without losing anything. I don't see any > issue with that. > I doubt this specific issue is directly related to canonicalization - when we sign the message [in this case SAML Assertion] - only the Assertion element is canonicalized.. and not aware of the duplicate namespaces present in parent element.. In Charith's case the Assertion element present is canonicalized properly - but the issue is the duplicate namespace being added to Envelope.. So - if we are removing duplicate namespaces as a way of optimizing, +1 for making it optional.. Thanks & regards, -Prabath > > On the specific issue- I'm looking for clarification .. I've started a > thread with James Clark (who wrote the XPath spec and helped with the NS > spec and knows a lot of this stuff much better than I ever will) to get it > clarified. Will report back shortly (and I'm usually wrong with him so I'm > expecting there's some flaw in my logic / reading of the spec). > > Sanjiva. > > > On Wed, Nov 23, 2011 at 12:52 AM, Andreas Veithen < > [email protected]> wrote: > >> Sanjiva, >> >> I think that you know me well enough by now to know that neither >> authority arguments nor diversions work with me. You made an assertion >> and I challenge you to prove it. You are not going to get away that >> easily ;-) >> >> Note that I think that removing a redundant namespace declaration may >> indeed cause problems with canonicalization, but only if several >> conditions are met. I would like to understand when this occurs and if >> the case that Charith encountered is an example of this or if the >> issue is caused by a broken client, a broken back-end service or an >> incorrect security policy. >> >> To answer your question: yes, removing redundant namespace >> declarations has been the default behavior in Axiom for a long time >> (even before I started to work on Axiom) and it should stay the >> default behavior. There are a couple of reasons for that. I will >> explain them to you once you come up with a correct argument >> supporting your point of view. We can then confront these arguments to >> see what is the correct solution for the problem. >> >> Andreas >> >> On Tue, Nov 22, 2011 at 18:21, Sanjiva Weerawarana >> <[email protected]> wrote: >> > Andreas independent of the C14N aspect, with Axiom if you read a doc and >> > write it back out the XML will be different. Is that what we want the >> > default behavior to be? >> > The spec has a convoluted set of guidelines on when its ok to drop >> stuff .. >> > I will try to give you a concrete example but I think the above >> question is >> > far simpler. >> > Sanjiva. >> > >> > On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen < >> [email protected]> >> > wrote: >> >> >> >> Well, the problem is that that specification actually contradicts what >> >> you are saying. You can find the relevant quote in section 2.1 "Data >> >> Model": >> >> >> >> "An element E has namespace nodes that represent its namespace >> >> declarations as well as any namespace declarations made by its >> >> ancestors that have not been overridden in E's declarations, the >> >> default namespace if it is non-empty, and the declaration of the >> >> prefix xml." >> >> >> >> Removing a redundant namespace declaration therefore doesn't change >> >> the data model because that declaration is "restored" by virtue of the >> >> second part of that definition. Therefore the output of the >> >> canonicalization (and hence the signature) doesn't change. >> >> >> >> Andreas >> >> >> >> Note: the superfluous namespace declarations implied by this >> >> definition are eliminated by the following rule specified in section >> >> 2.3 "Processing Model": >> >> >> >> "A namespace node N is ignored if the nearest ancestor element of the >> >> node's parent element that is in the node-set has a namespace node in >> >> the node-set with the same local name and value as N. Otherwise, >> >> process the namespace node N in the same way as an attribute node, >> >> except assign the local name xmlns to the default namespace node if it >> >> exists (in XPath, the default namespace node has an empty URI and >> >> local name)." >> >> >> >> On Tue, Nov 22, 2011 at 13:31, Sanjiva Weerawarana >> >> <[email protected]> wrote: >> >> > http://www.w3.org/TR/xml-c14n >> >> > >> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> Please look at the C14N spec. >> >> >> >> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen >> >> >> <[email protected]> wrote: >> >> >>> >> >> >>> Sanjiva, >> >> >>> >> >> >>> Can you substantiate these claims by references to the spec or >> >> >>> concrete examples? >> >> >>> >> >> >>> Andreas >> >> >>> >> >> >>> On Tue, Nov 22, 2011 at 03:51, Sanjiva Weerawarana >> >> >>> <[email protected]> wrote: >> >> >>> > Thanks for the clear writeup Andreas. >> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen >> >> >>> > <[email protected]> wrote: >> >> >>> >> >> >> >>> >> removal of redundant namespace declarations? I don't know the >> C14N >> >> >>> >> specs well enough to answer that question, but I've seen that >> these >> >> >>> >> specs make provisions to preserve the namespace context of the >> >> >>> >> element >> >> >>> >> and also define an algorithm to remove redundant namespace >> >> >>> >> declarations (search for "superfluous" or "unnecessary" >> namespace >> >> >>> >> declarations through the specs). >> >> >>> > >> >> >>> > Simple answer is that yes the spec is sensitive to any nodes >> being >> >> >>> > removed, >> >> >>> > including seemingly redundant namespace nodes. As Alek noted, >> with >> >> >>> > the >> >> >>> > advent of XPath, its now possible for a namespace declaration >> that >> >> >>> > looks >> >> >>> > redundant to an XML parser to actually be required. However this >> >> >>> > case >> >> >>> > is >> >> >>> > simpler- the element is signed and removing the node breaks the >> >> >>> > signature. >> >> >>> > I think we need to have a way to say "don't mess with the XML >> >> >>> > serialization >> >> >>> > AT ALL" .. that is what we want in the case of Synapse is not >> just >> >> >>> > an >> >> >>> > infoset preserving serialization but rather the EXACT >> serialization. >> >> >>> > Sanjiva. >> >> >>> > -- >> >> >>> > Sanjiva Weerawarana, Ph.D. >> >> >>> > Founder, Director & Chief Scientist; Lanka Software Foundation; >> >> >>> > http://www.opensource.lk/ >> >> >>> > Founder, Chairman & CEO; WSO2; http://wso2.com/ >> >> >>> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >> >> >>> > Member; Apache Software Foundation; http://www.apache.org/ >> >> >>> > Visiting Lecturer; University of Moratuwa; >> http://www.cse.mrt.ac.lk/ >> >> >>> > >> >> >>> > Blog: http://sanjiva.weerawarana.org/ >> >> >>> > >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> To unsubscribe, e-mail: [email protected] >> >> >>> For additional commands, e-mail: [email protected] >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Sanjiva Weerawarana, Ph.D. >> >> >> Founder, Director & Chief Scientist; Lanka Software Foundation; >> >> >> http://www.opensource.lk/ >> >> >> Founder, Chairman & CEO; WSO2; http://wso2.com/ >> >> >> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >> >> >> Member; Apache Software Foundation; http://www.apache.org/ >> >> >> Visiting Lecturer; University of Moratuwa; >> http://www.cse.mrt.ac.lk/ >> >> >> >> >> >> Blog: http://sanjiva.weerawarana.org/ >> >> > >> >> > >> >> > >> >> > -- >> >> > Sanjiva Weerawarana, Ph.D. >> >> > Founder, Director & Chief Scientist; Lanka Software Foundation; >> >> > http://www.opensource.lk/ >> >> > Founder, Chairman & CEO; WSO2; http://wso2.com/ >> >> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >> >> > Member; Apache Software Foundation; http://www.apache.org/ >> >> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >> >> > >> >> > Blog: http://sanjiva.weerawarana.org/ >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > >> > >> > -- >> > Sanjiva Weerawarana, Ph.D. >> > Founder, Director & Chief Scientist; Lanka Software Foundation; >> > http://www.opensource.lk/ >> > Founder, Chairman & CEO; WSO2; http://wso2.com/ >> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >> > Member; Apache Software Foundation; http://www.apache.org/ >> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >> > >> > Blog: http://sanjiva.weerawarana.org/ >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2; http://wso2.com/ > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > > -- Thanks & Regards, Prabath http://blog.facilelogin.com http://RampartFAQ.com
