Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document proposes a simple form of Canonical XML called "Canonical XML Vnext" (C14n-Vnext). The simplification is based on the assumption that a document subset selection MUST NOT loose namespaces declarations that are actually used by elements or attributes.
An implementation of C14n-Vnext MUST enforce the assumption above by taking a complete XML document represented in some data model or event stream and a boolean function called "is-selected(Node n)" as input.
An implementation of C14n-Vnext MUST also be prepared to take an additional boolean function called "prune(SpecialAttribute a)", where a SpecialAttribute is either a namespace declaration or an inheritable attribute.
These functions intend to achieve a data model independent specification of inclusive and exclusive canonicalization functionality. C14n-Vnext however in the general case cannot try to achieve output equivalence with C14n 1.0, C14n 1.1 and Exc-C14n due to it being agnostic about wheather SpecialAttributes are selected or not. It takes a different position where "is-selected(Node n)" will return true for all SpecialAttributes. It hence (as previous versions of C14n did implicitly) explicitly requires a complete traversal across the input document, but is not constrained to do this in the XPath data model.
An implementation of C14n-Vnext specifies an inclusive, an exclusive and a mixed form to match different application requirements.
I) TBD: For the inclusive form of C14n-Vnext, SpecialAttributes, such as inheritable attributes and namespace declarations (or namespaces in scope) used by QNames in content or content that is depending on xml:lang, xml:space or xml:base are assumed to be "properly defined" in the complete input document. This "properly defined" state will with a few exceptions not be lost in nodes orphaned (and readopted by another element) through document subset selection. C14n-Vnext in its inclusive form will not remove any SpecialAttribute context. C14n-Vnext in its inclusive form will merely push the SpecialAttribute context down into the next element node E availiable (i.e. is-selected(E) = true). The earlier mentioned exceptional case where such a push down operation is not possible can easiliy be determined. The case where E would need to get assigned "two values" for a SpecialAttribute to be rendered inside E denotes the exception. (E.g. Let's assume all text, comment or processing instruction nodes would have some QName in content or depend on inheritable attributes of the xml namespace. If then one such node would be adoped by a new parent element that already defines or inherits a value different to what the nodes had in context previous to their adoption is obviosly problematic, but easily determined.) Implementations MUST throw an error in such a situation and hence deem the given input as invalid. @@@ The lack of a SpecialAttribute, will have to be considered a "non-value". This implies that all text, comment or processing instruction nodes will cause an error, if adoped by an element that has a different SpecialAttribute context.@@@
II) TBD: The exclusive form of C14n-Vnext Namespace declarations SpecialAttributes, such as inheritable attributes and namespace declarations (or namespaces in scope) used by QNames in content or content that is depending on xml:lang, xml:space or xml:base are similarily assumed to be "properly defined" in the complete input document. C14n-Vnext in its exclusive form however will remove SpecialAttributes context with the exception of namespace declarations (or namespaces in scope) that are used by elements or normal ("non-special") attributes and potentially break the sematics of QNames in content or content that is depending on xml:lang, xml:space or xml:base.
This specifcation hence specifies the inclusiveness or exclusiveness on the granularity of the each SpaecialAttribute kind. For being able to make transport protocols and enveloping sigantures more robust a third boolean input function called "loose-Context-At(Element root)" will provide for a mechanism that allows to loose all SpaecialAttribute context at one certain element having no rendered parent element for XML 1.0 ( and at arbitrary elements for XML 1.1, @@@not sure we want to do this@@@).
III) TBD: The mixed form of C14n-Vnext will allow to be parameterized ... (maybe e.g.: xml:lang="inclusive/exclusive", xml:space or xml:base)
The "is-selected(Node n)" function means of an error. If an element or attribute The simplification is based on the assumption that a document subset selection MUST NOT loose namespaces declarations that are actually used by elements or attributes.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a First Public Working Draft of "Canonical XML Vnext (straw man proposal)".
This document is expected to be further updated based on both Working Group input and public comments. The Working Group anticipates to potentially publish a stabilized version of this document as a W3C Working Group Note.
The design outlined in this document is part of the XML Security Working Group's development of enhancements to versions 1.0 and 1.1 a revised version 2.0 of XML Signature; this Working Draft is published to solicit early community and review of the direction that the Working Group expects to take with version 2. Early feed-back is welcome.
This document was developed by the XML Security Working Group.
Please send comments about this document to public-xmlsec-comments@w3.org (with public archive).
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Definitions
1.2 An
informal specification of C14n-Vnext (non-normative)
1.2.1 An informal specification of
inclusive C14n-Vnext (non-normative)
2 References
The problem with current C14n algorithms is that they are not agnostic about the provided input format (or data model) and previos versions of C14n are complex and behave "unnaturally", depending on wheather namspace declarations (or their inherited node representations in XPath) are selected to be in the input or not. Similar concerns apply for all kinds of simple inheritable attributes such as xml:lang, xml:space and especially for the more complex inheritance rules of xml:base. ....
This document outlines a proposed change to the XML Signature processing model to achieve an input data-model agnostic specification of C14n-Vnext, that these goals. It also outlines use cases and the new requirements associated with the suggested changes.
It should be noted that this proposal is not for an additional constrained processing model, but for an actual replacement of the existing generically extensible model that exists now. Thus, the changes proposed in this document would be a breaking change to XML Signature, necessitating new implementations and possibly precluding the ability to support some use cases currently supported.
Thus, before making such a change in a proposed new version of XML Signature, the XML Security Working Group would like to obtain additional feedback on this proposal. The purpose of this document is to solicit early feedback.
[Definition: A SpecialAttribute is either a namespace declaration or an inheritable attribute.]
[Definition: The SpecialAttribute Context is constituted by the namespace declarations in scope and the inherited attributes in scope.]
[Definition: An inheritable attribute is either a simple inheritable attribute [C14N] or an xml:base attribute.]
The input to C14n-Vnext is a complete XML document represented in some data model or event stream. A boolean function called "is-selected(Node n)" returns true for all nodes whose information as input.
A SpecialAttribute is rendered irrespective of whether it is in the node-set, if it has not been ancestrally declared. Similar thought could be applied to xml:lang, xml:space and for xml:base [...] more sophisticated versions applying the combination rules of the join-URI-References function.