XML Validation Transforms for XML Signature

Abstract

This document specifies two XML Signature transforms for [XML1.0] and [XML-Schema] validation.

Status of this document

This document is an Editors' draft with no standing whatsoever.

This is the first draft of the "XML Validation Transforms for XML Signature" from theXML Signature Working Group(Activity ). Comments and implementation experience of this proposal are solicited.

Publication of this document 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 a W3C Working Draft as anything other than a "work in progress." A list of current W3C working drafts can be found athttp://www.w3.org/TR/ .

Please send comments to the editors (<reagle@w3.org> and cc: the listw3c-ietf-xmldsig@w3.org

Patent disclosures relevant to this specification may be found on the Working Group'spatent disclosure page) in conformance with W3C policy

Table of Contents

1. Introduction
2. XML Validation
3. Schema Validation
4. Schema, DTD, Data Model, and Valid Examples
5. Definitions
6. References
7. Authors' Address

1.0 Introduction

This document profiles the changes made to an XML document by [XML] and [XML-schema] validation as [XML-DSIG] transforms. The input, output, and processing (via normative references) is specified, along with the syntax and processing of [XML-DSIG] transform parameters.

1.1 Editorial and Conformance Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

1.3 Versions, Namespaces and Identifiers

No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different URI. The base URI that MUST be used for identification of these transforms is:

   xmlns="http://www.w3.org/2001/09/validate#"

1.4 Acknowledgements

The contributions of the following Working Group members to this specification are gratefully acknowledged:

...

2.0 XML1.0 Validation

Identifier:

http://www.w3.org/2001/09/validate#dtd

The normative specification of validating XML 1.0 processing is [XML]. Use of this transform indicates the document should be processed by a validating XML processor which, "must read and process the entire DTD and all external parsed entities referenced in the document." [XML]

The XML validation transform has no parameters, the document should be processed according to information available to the document, including document type declarations within the document.

If the input is octets they must be parsed by a validating XML parser. If the input is an XPath node-set, this node-set must be serialized first prior to validation. (However, validating an XPath nodeset is of little use since the node-set will not have a Document Type Declaration associated with it.) Note, while the changes made to an information set by XML validation can affect entities and default attribute content values. Consequently, the presence and order of XML validation may affect the canonical form.

3.0 Schema Validation

Identifier:

http://www.w3.org/2001/09/validate#schema

The normative specification for XML Schema is [XML-Schema]. Use of the schema validation transform without any parameters indicates that the document should be processed according to information within the resource being transformed. Use of a name space qualified schema element, which must be the sole child of the Transform, indicates the specified schema should be used for validation; whether this instantiates other validation using other schema is determined by the XML Schema processing model; the ordered application of multiple schema validations may require multiple Transforms. No special provision is made for the identification of a remote stylesheet at a given URI because it can be communicated via an xsd:include or xsd:import within the schema child of the Transform.

This transform requires a specified set of "Required Information Set Items and Properties" [XML-schema, Appendix D]. If the input is octets, the octets must be parsed. If the input is an XPath node-set, this node-set may be able to serve as the necessary information set. Note, while the changes made to an information set by schema validation are largely augmentations, and consequently not contained in the XPath data model, schema validation can affect default attribute and element content values. Consequently, the presence and order of schema validation may affect the canonical form.

[Do we have to worry about laxly schema valid? -JR]

8.0 Security Considerations

...

10.0 Definitions

11.0 References

DOM

Document Object Model (DOM) Level 1 Specification. W3C Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October 1998.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/

KEYWORDS

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
http://www.ietf.org/rfc/rfc2119.txt

SAX

SAX: The Simple API for XML. D. Megginson, et al. May 1998.
http://www.megginson.com/SAX/index.html

SEC

RFC 2828 . Internet Security Glossary. R. Shirey. May 2000.
http://www.faqs.org/rfcs/rfc2828.html

URI

RFC 2396 . Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998.
http://www.ietf.org/rfc/rfc2396.txt

URI-Literal

RFC 2732 . Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999.
http://www.ietf.org/rfc/rfc2732.txt

URL

RFC 1738. Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, and M. McCahill. December 1994.
http://www.ietf.org/rfc/rfc1738.txt

URN

RFC 2141 . URN Syntax. R. Moats. May 1997.
http://www.ietf.org/rfc/rfc2141.txt

RFC 2611 . URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999.
http://www.ietf.org/rfc/rfc2611.txt

XML

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October 2000.

http://www.w3.org/TR/2000/REC-xml-20001006

XML-C14N

Canonical XML. W3C Recommendation. J. Boyer. March 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt

XML-ns

Namespaces in XML. W3C Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114

XML-schema

XML Schema Part 1: Structures. W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. May 2001.

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

XML-DSIG

XML-Signature Syntax and Processing. Proposed Recommendation. D. Eastlake, J. Reagle, and D. Solo.

http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/

XPath

XML Path Language (XPath) Version 1.0. W3C Recommendation. J. Clark, S. DeRose. October 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116

12. Authors' Address

Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Phone: + 1.617.258.7621
Email: reagle@w3.org