ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Redundant names space removal when Serializing - AXIOM
Date Wed, 23 Nov 2011 22:42:36 GMT
Dude, if you had not started to make questionable statements about the
specs, we could have come to the conclusions much earlier...

Of course, adding an option to Axiom to disable the removal of
redundant namespace declarations is a perfectly reasonable
requirement. I would even go a step further and also allow to disable
namespace repairing altogether. In fact, if one parses an XML document
and later serializes it again without doing any structural
modifications, then it will automatically be well formed with respect
to namespaces. In that case, namespace repairing is just unnecessary
overhead. IMHO this is an even more relevant requirement because the
redundant namespace thing is only important when interacting with
broken services.

However, I wouldn't speak about "serialize back to the EXACT xml"
(certainly not in upper case letters...) because the serialized XML
will almost never be exactly the same.

Andreas
On Wed, Nov 23, 2011 at 16:39, Sanjiva Weerawarana
<sanjiva@opensource.lk> wrote:
> Andreas, independent of the discussion on whether what Axiom's serializer is
> doing is affecting C14N or not, it is a perfectly reasonable requirement to
> be able to serialize back to the EXACT xml from which the Axiom model was
> built.
> No one is asking for this to change default behavior. This is about making
> Axiom more useful for a wider group of people and hence a perfectly
> reasonable thing to do!
>
> Sanjiva.
>
> On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen <andreas.veithen@gmail.com>
> 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?
>>
>> Andreas
>>
>> On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <prabath@wso2.com>
>> wrote:
>> >
>> >
>> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> > <sanjiva@opensource.lk>
>> > 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
>> >> <andreas.veithen@gmail.com> 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
>> >>> <sanjiva@opensource.lk> 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
>> >>> > <andreas.veithen@gmail.com>
>> >>> > 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
>> >>> >> <sanjiva@opensource.lk> wrote:
>> >>> >> > http://www.w3.org/TR/xml-c14n
>> >>> >> >
>> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >>> >> > <sanjiva@opensource.lk>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Please look at the C14N spec.
>> >>> >> >>
>> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >>> >> >> <andreas.veithen@gmail.com> 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
>> >>> >> >>> <sanjiva@opensource.lk> wrote:
>> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas
Veithen
>> >>> >> >>> > <andreas.veithen@gmail.com> 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: dev-unsubscribe@ws.apache.org
>> >>> >> >>> For additional commands, e-mail: dev-help@ws.apache.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/
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > --
>> >>> >> > 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: dev-unsubscribe@ws.apache.org
>> >>> >> For additional commands, e-mail: dev-help@ws.apache.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: dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: dev-help@ws.apache.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/
>> >
>> >
>> >
>> > --
>> > Thanks & Regards,
>> > Prabath
>> >
>> > http://blog.facilelogin.com
>> > http://RampartFAQ.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message