Status: This documentÂ (20011017) is the joint W3C/IETF XML Signature
Charter and is an updated version of the (19990624, 20000105, 20010212) versions that governed until July
2001. This version extends the charter of the Working Group (WG) until March
2002 at a low level necessary for completing the advancement of the WG's
deliverables. The changes in this charter are adjustments to the Duration and Milestones of the Working Group, and the
additional transform deliverables.

Introduction

Digital signatures provide integrity, signature assurance and
non-repudiatability over Web data. Such features are especially important for
documents that represent commitments such as contracts, price lists, and
manifests. In view of recent Web technology developments, the proposed work
will address the digital signing of documents (any Web resource addressable
by a URI) using XML syntax. This capability is critical for a variety of
electronic commerce applications, including payment tools.

[This W3C charter is used to create a reformatted charter used for IETF
process procedures.]

The mission of this working group is to develop a XML compliant syntax for
representing signatures over Web resources and portions of protocol messages
(anything that can be referenced by a URI) and procedures for computing and
verifying such signatures. Such signatures will be able to provide data
integrity, authentication, and/or non-repudiatability. The meaning of the
signature is very simple:Â The XML signature syntax associates the
cryptographic signature value with Web resources using XML markup. The
meaning of the signature may be extensible by a set of semantics specified
separately.

This effort is equally and strongly dependent on XML expertise and
coordination, which is in the W3C, and Internet cryptographic expertise and
coordination, which is in the Internet
Engineering Task Force (IETF). Therefore, the working group will be a
joint body operating simultaneously as an IETF WG and a W3C WG. Procedures
may differ from the norm for either organization (IETF RFCs 2026 / 2418 & World Wide Web
Consortium Process Document). Details are give in the sections below.

The core scope of this activity will be in specifying the necessary data
model, syntax, and processing to bind a cryptographic signature to a resource
in XML.

The working group will focus on:

Creating a data model that permits XML-DSig to be an integral part of
developing metadata and object model technologies.

Creating an extensible canonicalization framework. In addition, specify
application requirements over canonicalization. All XML-DSig applications
must be able to sign -- at least -- the binary byte stream. The group may
also require applications to support XML syntax or Unicode
canonicalization if those mechanisms are widely understood and necessary.
This group will coordinate its requirements with activities delivering
XML, RDF, or DOM canonicalization mechanisms.

Syntax and processing for XML signatures.

Document the WG's position on signature semantics. At the Chair's
discretion the WG may develop a (small) set of signature semantics. Such
a proposal would define common semantics relevant to signed assertions
about Web resources and their relationships in a schema definition ( XML/RDF) or link type
definition (XLink).

Defining the charter for subsequent work once (1-4) has been
achieved.

Defines a simple signature XML syntax that is highly extensible. We
wish to create a simple digital signature syntax that can be used with
other application semantics (through XML-namespaces) so as to create
arbitrarily sophisticated assertion capabilities.

Ensuring that applications can create and process composite/compound
documents consisting of XML and non-XML data as well as for processing
detached or external signature blocks and assertions.

XML-DSig must be coordinated with and use the work product of other
mature XML technologies. (See Coordination)

XML-DSig syntax expresses data model semantics; we do not require
applications to make inferences on that data model.

The mandatory portions of the specification must be implemented in at
least two independent implementations before being advanced to Proposed
Recommendation.

W3C NOTE (Informational RFC) further specifying the requirements and
dependencies for the remaining deliverables.

W3C Proposed Recommendation (Proposed Standard RFC) that defines a
highly extensible XML syntax and processing used for associating a
signature with XML data without semantic specification but having
provisions for the inclusion of such specification.

W3C Proposed Recommendation (Informational RFC) that defines an
Exlusive Canonical XML in which a canonicalized subset inherits as little
context from its ancestors as possible. This permits a digital signature
over an XML subdocument to not break when that subdocument is removed
from its original document and/or inserted into a different document.

Optional ietf-draft or Note containing additional algorithm URIs and
definitions. This includes XML1.0 and Schema validation transforms which
can be addressed in a seperate Recommendation track document at Chairs'
discretion.

The following dates have been updated in October 2001 and extend the life
of the WG at a low level until March 2001.

By December 2000, the Working Group evolved in the following three
ways:

the WG opted notÂ to produce a signature semantic Note

the WG did not produce a formal test case specification as an
Informational RFC and W3C Note. Instead interoperability testing was
achieved through informal documents associated with the specifications
and discussion on the email list.

Once established, the Working Group can decide to parallelize more tasks
by forming subgroups. The Working Group can also decide to reschedule tasks
that do not have to meet deadlines imposed by other groups. However, the
schedule must fit into the total timeframe given above.

Also, document dates may not be rescheduled without notifying the W3C
Domain leaders, the W3C director, and the IETF Area Director. Note that delay
of deliverables can be a reason for the Working Group to be terminated.

A central characteristic of this activity is its dependencies on other XML
working groups. The WG chair will likely be made a member of the W3C XML
Coordination Group. During W3C Last Call, the Chair will procure
reviews from the following W3C WGs before the specification will be advanced
further:

XML Syntax/Core WG: Canonicalizing XML which involves finding a single
or "canonical" version of every possible form of the same document (by
reducing white space, mapping quote marks to a standard form, etc. etc.)
with a view to using that standard form for the purpose of applying
digital signature technology.

XML Linking WG: The objective of the XML Linking Working Group is to
design advanced, scalable, and maintainable hyperlinking and addressing
functionality for XML

XML Schema
WG: The XML Schema Working Group is addressing means for defining the
structure, content and semantics of XML documents.

Metadata CG: The RDF Model and Syntax
provides a uniform and interoperable means to exchange the metadata
between programs and across the Web. Furthermore, RDF provides a means
for publishing both a human-readable and a machine-understandable
definition of the property set itself.

Since this Working Group will be public, its coordination with other W3C
WGs must take this into account.

There are expected to be teleconferences held every few weeks at a time
set by the Chair. The exact frequency of calls will be determined by working
group consensus.

The Chair is
responsible for producing an agenda at least 24 hours in advance of each
call, posting it along with the call details to the mailing list, and causing
minutes of the call to be posted promptly after the call.

The working group will have a two day face to face meeting in September
1999 and meet at the July and November 1999 IETF meetings and may have
additional physical meetings by consensus of the WG. Meeting notice, advance
agenda, and posting of minutes shall follow W3C timing rules.

Communication with the Public

WG documents will be published by both the W3C, via the web, and in the
IETF as Internet-Drafts or RFCs. Differing delays in the processes may cause
skew in the appearance of a document in the two locations.

When a document is subject to a Last Call in both organizations (W3C Last
Call or AC Review in the W3C, Working Group or IETF Last Call in the IETF)
comments received in both venues must be considered and responded to. In
effect, the Last Call period will be the longer of the times allowed in the
W3C and IETF."

The rough equivalence between document types in the W3C and IETF (and
minimum length of time in that state) is as follows:

W3C

IETF

Note

Informational RFC

Working Draft

Working Group Internet Draft
Working Group Informational RFC

W3C Last Call (4w)

IETF Last Call (4w)

W3C Candidate Recommendation (4w)

Proposed Standard (6m)

Proposed Recommendation (6w)

Â

Recommendation (complete)

Â

Â

Draft Standard (4m)

If a document is substantively changed such that it recycles to a lower
status in either venue, the corresponding document classification in the
other venue should also change.

IETF Last Calls for joint working group documents which are on the IETF
standards track will be 4 weeks per the Variance section of RFC 2026.

The working group itself will operate by consensus as provided in the IETF
rules.

Appeals from decisions by the working group chair may be taken using
either the W3C or the IETF appeals mechanisms. It is expected that these
mechanisms will coordinate and differences are not anticipated. Nevertheless,
if and when the appeal mechanisms of the W3C and IETF come to irreconcilable
decisions, the group will thereby cease to be a working group of either the
W3C or the IETF and may not take further official action under the procedures
of either organization without explicit rechartering.

Should either the W3C or the IETF unilaterally terminate the Working Group
status so far as that organization is concerned, the WG will continue to be a
working group of the other organization.

Participation in the working group is open. Participation is expected to
take a minimum of 15% of the participants time. The XML-DSig WG will be
co-chaired by Donald Eastlake III (IBM) and Joseph Reagle (W3C). Each
co-chair is expected to devote 20% of his time to this activity.

The XML-DSig Staff
Contact will be Joseph Reagle and his staff contact duties are expected
to take 40% of his time. The staff contact is partly responsible for
coordinating dependencies and requirements from the W3C Director and other
activities. Further details on the Staff Contact and Chair roles can be found
the W3C Guidebook for Working
Group Chairs.