W3C home > Mailing lists > Public > public-xmlsec@w3.org > October 2009

Proposed requirements update related to prefix rewriting

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Mon, 19 Oct 2009 12:08:45 -0400
Message-Id: <0458AEFE-1637-48CD-903A-6349CFF6DD29@nokia.com>
To: XMLSec WG Public List <public-xmlsec@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
In my absence I received an action (ACTION-402) to update the  
requirements document for ISSUE-136.

ISSUE-136 states: "Is normalization of prefixes a goal for 2.0 c14n"

The 2.0 proposal supports normalization of prefixes as an option, see  
the prefixRewrite parameter described in the Canonical XML Version 2.0  
editors draft

http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#Canonicalization-Parameters

That document also lists requirements, specifically:
[[

1.4.3 Robustness

Whitespace handling was a common cause of signature breakages. XML  
libraries allow one to "pretty print" an XML document, and most people  
wrongly assume that the white space introduced by pretty printing will  
be removed by canonicalization but that is not the case. This  
specification adds three techniques to improve robustness:

	 Remove leading and trailing whitespace from text nodes,
	 Allow for QNames in content especially in the xsi:type attribute,
	 Rewrite prefixes
]]

To complete ACTION-402, I suggest the following requirements document  
changes to the XML Signature Transform Simplification: Requirements  
document

http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#id83777

(1) Change the section titled "Relax certain guarantees" as follows:

Change section title to "Enable optional prefix rewriting "
Change

"A limited revised version of Canonical XML might be one in which  
namespace prefixes are not guaranteed to be preserved, possibly  
breaking the meaning of QNames."
to

"Canonical XML should support the option of namespace prefix re- 
writing. In this case namespace prefixes are not guaranteed to be  
preserved, possibly breaking the meaning of QNames.  The advantage of  
using this option is avoiding the complexity and confusion of prefixes  
that are used for different namespaces in different subtrees, avoiding  
mapping issues and the need to store additional information for each  
node for this mapping."




regards, Frederick

Frederick Hirsch
Nokia
Received on Monday, 19 October 2009 16:09:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:44:00 GMT