Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] XML Transformation

From: "Anishek Agarwal" <anishek@-----.--->
To: xml-dev@-----.---.---
Date: 8/7/2008 12:36:00 PM
Hello,

I am already using c14n canocalizer for transforming the xml. I am not
sure if the other party is using it though. When i transform the xml
though the namespace prefix "dsig" is removed from the inner
<signture> tag and its child nodes as there is a defalut
namespace (xmlns="http://www.w3.org/2000/09/xmldsig#") already defined for that nodeSo according to c14n is this correct way of transforming or 


wrong. My partner says that no matter transformer you use you should
not remove the "dsig" prefix. My argument is signature is always
calculated after transforming using c14n. 



The product i am is a federation product and even according to the SAML
2.0 specification for signing the c14n transformer has to be used. 

The point of contention is that he says he has calculated the sig with the "dsig'" namespace(though he claims that he too has used c14n) and when i am doing the transformation it removes ???

Michael, 

I am not sure i will be able to post the exact xml here due to organizational policies here but let me find that out. As for XSLT i am not too familiar with that. As i had said earlier a SAXParser is used to read the socket input stream in axis/xmlsec(we are using these lib for xml related operations) to get the document node.



Additionally the xml is received over a SOAP channel managed by axis. I havent written any code for parsing or verifying signatures, we are using third party libs for xml operations.


Please let me know if you need some more data.


Thanks

Anishek





On Thu, Aug 7, 2008 at 5:45 PM, Richard Salz <rsalz@u...> wrote:

You mean "I don't see why the inner... *cannot be* or *is not* removed"



It can.  Having it there, or not, does not change the semantics of the

XML.  It's just a side-effect of whatever implementation you are using.



If you really care about this -- for example, doing XML Digital Signatures

-- then you need something like xml c14n.  Otherwise I would not worry

about it.



        /r$



--

STSM, DataPower Chief Programmer

WebSphere DataPower SOA Appliances

http://www.ibm.com/software/integration/datapower/









"Anishek Agarwal" <anishek@g...>

08/07/2008 08:02 AM



To

xml-dev@l...

cc



Subject

Re: [xml-dev] XML Transformation













I still did not get the reply for this. Can someone please comment.



Anishek



On Wed, Aug 6, 2008 at 2:50 PM, Anishek Agarwal <anishek@g...> wrote:

According to the xml specification though

http://www.w3.org/TR/REC-xml-names/#scoping-defaulting the inner scope

definition overrides the parent one if the NSAttName is the same. In our

case of the xml above it is the same as its the default namespace. So i

dont see why the inner scope namespace declaration element be removed and

use the parent namespace.





Anishek





On Wed, Aug 6, 2008 at 2:30 PM, Andrew Welch <andrew.j.welch@g...>

wrote:

> For better or worse, the digital signature mechanisms follow XML

> Canonicalization by deciding that namespace prefixes are significant:

see

>

> http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting

>

> for discussion.



!  That's good to know...



I guess it all comes down the fact that the prefix isn't expanded to

the URI.... which is the root cause of the problem of XPath requiring

the prefixes to be mapped elsewhere.



I guess there is an argument for dropping the URI altogether, and just

using the prefix.  Some things would get harder, but many more would

get a lot easier.





--

Andrew Welch

http://andrewjwelch.com

Kernow: http://kernowforsaxon.sf.net/


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent