Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] XML Transformation

From: "Michael Kay" <mike@--------.--->
To: "'Anishek Agarwal'" <anishek@-----.--->,<xml-dev@-----.---.--->
Date: 8/7/2008 1:55:00 PM
As I explained earlier, namespace prefixes are considered 
significant when calculating signatures, and canonicalizing will not change 
them.
 
If we're going to help you we need to find out how the 
namespace prefixes got changed, which means understanding the processes that 
have transformed the XML, and you seem very unwilling or unable to explain this 
- except that it involves axis/xmlsec which is not a technology I am familiar 
with. Perhaps you need to ask on a forum where there are people who understand 
that technology.
 
Michael Kay
http://www.saxonica.com/
 


  
  
  From: Anishek Agarwal 
  [mailto:anishek@g...] 
Sent: 07 August 2008 13:36
To: 
  xml-dev@l...
Subject: Re: [xml-dev] XML 
  Transformation


  
  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