IETF Logo W3C Logo

XML-Signature Requirements

W3C Working Draft 1999-August-06

This Working Group version: {ascii]
Previous version:
Joseph Reagle Jr. <>

Copyright © 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

W3C Status of this Document

This is a WG XML Signature Requirements consensus candidate draft. Upon final confirmation by the WG, this document will be published as a working-draft/ietf-draft. This forthcoming publication will be similar to a last-call in that it is asking for substantive community wide review, particularly with respect to the dependencies identified in this document. It is different from a last call in that it is not intended to be advanced to a W3C Proposed Recommendation. Once dependencies and commitments have been confirmed with the identified WGs, this document may be advanced as an IETF Informational RFC. Aside from these caveats, this WG deliverable is largely on schedule with respect to the timeline in the WG Charter:

Aug 99 Requirements document to Last Call for NOTE / Informational RFC

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 class="discuss" and rendered as color:navy by style sheet compliant applications. Editorial comments about a discussion point are of class="comment" and rendered in a box with a light background.

Please send comments to the editor <> and cc: the list <>. 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 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.

Table of Contents

  1. Introduction
  2. Design Principles and Scope
  3. Requirements
    1. Signature Data Model and Syntax
    2. Format
    3. Cryptography
    4. Processing
    5. Coordination
  4. References
  5. Acknowledgements

1. Introduction

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."

2. Design Principles and Scope

  1. The specification must describe how to a sign digital content in general, and XML content in particular. [Charter]
  2. 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://..." referent=""><html>. or 
    <html><title>pricelist</title>...<dsig xmlns="http://..."> ... </dsig></html>

  3. The meaning of a signature is simple:  The XML-signature syntax associates the content of resources listed in a manifest with a key via a strong one-way transformation.
    1. The XML-signature syntax must be extensible such that it can support arbitrary application/trust semantics and assertion capabilities -- that can also be signed. [Charter(Requirement1&4), List(Bugbee, Solo)]
    2. The WG is not chartered to specify trust semantics, but syntax and processing rules necessary for communicating signature validity (authenticity, integrity and non-repudiation).  [Charter(Requirement1)] At the Chairs' discretion and in order to test the extensibility of the syntax, the WG may produce non-standard-track proposals defining common semantics (e.g., package, timestamps, endorsement, etc.) relevant to signed assertions about Web resources in a schema definition [XML, RDF] or link type definition [XLink].

    See the draft definitions document [Defn] for specific definitions of signature validation and trust validation.

  4. The specification must not specify methods of confidentiality though the Working Group may report on the feasibility of such work in a future or rechartered activity. [List(Bugbee)]
  5. The specification must only require the provision of key information essential to checking the validity of the cryptographic signature. For instance, identity and key recovery information might be of interest to particular applications, but they are not within the class of required information defined in this specification. [Reagle]
  6. The specification must define or reference at least one method of canonicalizing and hashing the signature syntax (i.e., the manifest and signature blocks). [Oslo] The specification must not specify methods of canonicalizing resource content [Charter], though it may specify security requirements over such methods. [Oslo] Such content is normalized by specifying an appropriate content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. Applications are expected to normalize application specific semantics prior to handing data to a XML-signature application. [Charter]
  7. XML-signature applications must be conformant with the specifications as follows:
    1. XML-namespaces [XML-namespaces] within its own signature syntax. Applications may choose C14N algorithms which do or do not process namespaces within XML content. For instance, some C14N algorithms may opt remove all namespace declarations, others may rewrite namespace declarations to provide for context independent declarations within every element.
    2. XLink [Xlink] within its own signature syntax. Applications must use XLink locators within the signature manifest to reference resources. Signature applications must not embed or expand XLink references in signed content, though applications may choose C14N algorithms which provide this feature.
    3. XML-Pointers [XPointer] within its own signature syntax. If applications reference/select parts of XML documents, they must use XML-Pointer within an XLink locator. [Reagle, WS-list(1)]

    The WG may specify security requirements that constrain the operation of these dependencies to ensure consistent and secure signature generation and operation. [Oslo]

  8. XML-signatures must be developed as part of the broader Web design philosophy of decentralization, URIs, Web data, modularity/layering/extensibility, and assertions as statements about statements. [Berners-Lee, Reagle, WebData] In this context, existing cryptographic provider (and infrastructure) primitives should be taken advantage of. [List(Solo)]

3. Requirements

1. Signature Data Model and Syntax

  1. XML-signature data structures must be predicated on the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter]
  2. XML-signatures apply to any resource addressable by a locator -- including non-XML content. XML-signature referents are identified with XML locators (URIs or fragments) within the manifest that refer to external or internal resources (i.e., network accessible or within the same XML document/package). [Berners-Lee, Reagle, Brown, List(Vincent), WS, XFDL]
    1. XML-signatures must be able to apply to a part or totality of a XML document.  [Charter, Brown]
    2. Multiple XML-signatures must be able to exist over the static content of a Web resource given varied keys, content transormations, and algorithm specifications (signature, hash, canonicalization, etc.). [Charter, Brown]
    3. XML-signatures are first class objects themselves and consequently must be able to be referenced and signed. [Berners-Lee, Reagle]
  3. 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]

  4. XML-signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)]

2. Format

  1. An XML-signature must be a well-formed XML document. [Charter]

    We are considering a restatement of this requirement to provide for XML-signatures being included within other doucuments: the signature is not a document itself.

  2. 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]

  3. XML-signature must provide a mechanism that facilitates the production of composite documents -- by addition or deletion --  while preserving the signature characteristics (integrity, authentication, and non-repudiatability) of the consituent parts. [Charter, Brown, List(Bugbee)]
  4. A key use of XML-signatures will be detached Web signatures. However, signatures may be embedded within or encapsulate XML or encoded content. [Charter] This WG must specify a simple method of packaging and encapsulation if no W3C Recommendation is available.

3. Cryptography and Processing

  1. The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key negotiation methods. [Brown]
  2. The specification must specify at least one required signature canonicalization, content canonicalization, hash, and signature algorithm.
  3. 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.]

    This issue is awaiting further clarification as we get closer to a syntax proposal the WG finds acceptable and we gain some sense of how applications will operate. For instance, instead of an application preferring one semantic to another, it might simply throw an error condition.

4. Coordination

  1. The XML Signature specification should meet the requirements of the following applications:
    1. Internet Open Trading Protocol v2.0 [Charter]
    2. Financial Services Mark Up Language v2.0 [Charter]
    3. At least one forms application [XFA, XFDL]
  2. To ensure that all requirements within this document are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities:
    1. XML Syntax Working Group: canonicalization dependencies. [Charter]
    2. XML Linking Working Group: signature referants. [Charter]
    3. XML Schema Working Group: signature schema design. [Charter]
    4. Metadata Coordination Group: data model design. [Charter]
    5. W3C Internationalization Interest Group:  [AC Review]
    6. XML Package Working Group: signed content in/over packages.

    7. 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.

4. References

AC Review
Misha Wolf. "The Charter should include the I18N WG in the section on 'Coordination with Other Groups.'"
Axioms of Web Architecture: URIs.
Web Architecture from 50,000 feet
Internet Draft. Digital Signatures for XML
XML Signature (xmldsig) Charter.
XML Signature Working Group Draft.
Internet Draft. Digest Values for DOM (DOMHASH)
XML Information Set Requirements Note.
Internet Draft. Digital Signatures for the Internet Open Trading Protocol
Minutes of the XML Signature WG Sessions at  IETF face-to-face meeting in Oslo.
RDF Schema
RDF Model and Syntax
Signature WG List
Uniform Resource Identifiers (URI): Generic Syntax
WS (list, summary)
XML-DSig '99: The W3C Signed XML Workshop
XML Linking Language
Extensible Markup Language (XML) Recommendation.
XML Canonicalization Requirements.
XML Forms Architecture (XFA)
Extensible Forms Description Language (XFDL) 4.0
XML-Fragment Interchange
Namespaces in XML
XML Schema Part 1: Structures
XML Schema Part 2: Datatypes
XML Pointer Language (XPointer)
Web Architecture: Describing and Exchanging Data.

5. Acknowledgements

The work of producing this specification was accomplished by the membership of the IETF/W3C XML Signature Working Group (WG). The list of contributors below was generated by the process specified in the XML Signature WG Contributor Policies.

Mark Bartel (JetForm Corporation ), John Boyer (, Richard Brown (Globeset), Donald Eastlake (Co-Chair, IBM ), Barbara Fox (Microsoft ), Todd Glassey (Meridianus/GMTsw ), Phillip Hallam-Baker (VeriSign Inc ), Richard Himes (US District Court of New Mexico), Peter Lipp (IAIK TU Graz ), Hiroshi Maruyama (IBM ), Joseph Reagle (Co-Chair, W3C), Chris Smithies (PenOp), David Solo (Citigroup), Winchel "Todd" Vincent (GSU)