Hi Andreas; On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen <[email protected]>wrote:
> Prabath, > > This is yet another assertion that is not based on any kind of proper > argumentation. "not aware of the duplicate namespaces present in > parent element" would imply that WS-Security requires an > implementation to detach the element being signed and to forget the > namespace context associated to its parent element. Where is this > written? > > The SAML Assertion uses Enveloped Signature - not the detached signature - which is covered under the SAML token profile - so, in this case. Assertion element is built, signed and added in to the SOAP Envelope.. Thanks & regards, -Prabath > Andreas > > On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <[email protected]> > wrote: > > > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Thanks & Regards, Prabath http://blog.facilelogin.com http://RampartFAQ.com
