Re: Requirements and Goals for the Design of an 'XML Encryption Standard'

At 17:48 11/20/2000 -0800, hal@finney.org wrote:
>Part of the work of the group needs to be to define
>that equivalence class, and/or to define a mechanism to specify the
>equivalence class (some kind of canonicalization transform).

The present Canonical XML does this over elements:
>Any XML document is part of a set of XML documents that are logically 
>equivalent within an application context, but which vary in physical 
>representation based on syntactic changes permitted by XML 1.0 [XML] and 
>Namespaces in XML [Names]. This specification describes a method for 
>generating a physical representation, the canonical form, of an XML 
>document that accounts for the permissible changes. Except for limitations 
>regarding a few unusual cases, if two documents have the same canonical 
>form, then the two documents are logically equivalent within the given 
>application context. Note that two documents may have differing canonical 
>forms yet still be equivalent in a given context based on 
>application-specific equivalence rules for which no generalized XML 
>specification could account.
>http://www.w3.org/TR/xml-c14n

Related issues we've encountered include:

1. Whether it's required/defaulted.
2. Whether it's part of a specified transform/processing model.
3. Whether the resulting XML is overly verbose for human/application 
purposes (not relevant to xmldsig).

However, as the WG is likely to have in its charter (and/or part of its 
requirements document) a requirement not to invent new things (data models, 
algorithms, etc.) and to put a point on this, are you advocating something 
other than Canonical XML? If so, is the variance the particular equivalence 
chosen by Canonical XML or an issue that is broader/higher/lower in the 
"stack" of the design?


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 27 November 2000 21:51:09 UTC