Copyright © 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document attempts to capture the Working Group's consensus though it contains
points which are still in dispute or not well specified. Issues which are still being
actively discussed during the publication of this document are of
and rendered in red by style sheet compliant applications.
Please send comments to the editor <email@example.com> and cc: the list <firstname.lastname@example.org>. 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 W3C Drafts as other than "work in progress".A list of current W3C working drafts can be found at http://www.w3.org/TR. Publication as a Working Draft does not imply endorsement by the W3C membership.
This document lists the design principles, scope and requirements for the XML Digital Signature specification.
The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. The mission of this working group is to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability.
This document lists the design principles, scope, and requirements over three things: (1) the scope of work available to the WG, (2) the XML signature specification, and (3) applications that implement the specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. Those things that are required are designated as "must," those things that are optional are designated by "may," those things that are optional but recommended are designated as "should."
XML-signatures are generated from a hash over the canonical form of a signature manifest. The manifest includes references to Web resources, the hash of the resource content (or its canonicalized form), and (optionally) the resource content type. [Brown, List(Solo)] Web resources are defined as any digital content content that can be addressed using the syntax of XLink locator [XLink]).
Scenarios are being explored which examine the ability to sign without
requiring a manifest whereas the scope of the signed content is designated by the relative
placement of signature elements in the XML stream/tree. For instance:
<html> .....</body><dsig xmlns="http://..."
xmlns="http://..."> ... </dsig></html>
The WG may specify security requirements that constrain the operation of these dependencies to ensure consistent and secure signature generation and operation. [Oslo]
The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic negotiation of keying material. [Brown] Resource or algorithm identifier are a first class objects, and must be addressable by a URI. [Beners-Lee, Reagle]
An XML-signature must be a well-formed XML document. [Charter] [What if it's imported into another document, does this make sene?]
An XML document of a certain type must still be recognizable as its original type when signed. For example, an XML form, when signed, should still be recognizable as a XML form to its application after it has been signed. [WS-summary]
In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics. [awaiting clarification - Reagle.]
Another possibility is that an error should be generated, however it isn't where a conflict will be flagged between the various function and application layers regardless.
XML Package Working Group: signed content in/over packages.
XML Fragement Working Group: signing portions of XML content.
Members of the WG are very interested in signing and processing XML fragments and packaged components. Boyer asserts that [XML-fragment] does not "identify non-contiguous portions of a document in such a way that the relative positions of the connected components is preserved." Packaging is a capability critical to XML-Signature applications, but it is clearly dependent on clear trust/semantic definitions, package application requirements, and even cache-like application requirements. It is not clear how this work will be addressed.