IETF and W3C

["Jim Carlo" <jcarlo@ti.com>]

I note below that in the development of Digital Sigatures, the IETF and W3C
have formed a joint working group. This could be a model for future IEEE/IETF
joint working groups.

Jim Carlo(jcarlo@ti.com) Cellular:1-214-693-1776  Voice&FAX Mail:1-214-853-5274
TI Fellow, Networking Standards at Texas Instruments
Chair, ISO/IEC JTC1/SC6 Telecom and Info Exchange Between Systems
Chair, IEEE 802 LAN MAN Standards Committee

JOINT IETF / W3C WORKING GROUP:

This effort is equally and strongly dependent on XML expertise and
coordination, which is in the World Wide Web Consortium (W3C), and
Internet cryptographic expertise and coordination, which is in the
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.

SCOPE:

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:

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

2. Creating a extensible canonicalization framework. In addition,
   specify application requirements over canonicalization. At least all
   XML-DSig applications must be able to sign 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.

3. Syntax and processing for XML signatures.

4. Document the WG's position on signature semantics with a
   non-standard-track document. 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).

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

REQUIREMENTS:

The following requirements must be met by the WG:

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

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

- Mandatory portions of the specification must be implemented in at
  least two independent implementations before being advanced to
  Proposed Standard.


CONTRAINTS:

The working group will not address the following issues:

- Trust engines

- Public key infrastructure

- Trust management systems

- XML schemas for certificates

DELIVERABLES:

This working group will deliver the following:

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

- Proposed Standard RFC (W3C Recommendation) 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.

- Informational RFC (W3C NOTE) on signature semantics labeling and,
  if appropriate, an additional (small) set of signature semantics in a
  schema definition (XML/RDF) or  link type definition (XLink).

- Informational RFC (W3C NOTE) documenting a set of test cases for
  interoperability testing and a report on interoperability results.

- If appropriate, charters for further work.

COORDINATION WITH OTHER W3C GROUPS:

A central characteristic of this activity is its dependencies on other
XML working groups. The WG chair will likely be 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:

o XML Syntax 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.

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

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

o RDF: The RDF 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.

COMMUNICATIONS MECHANISMS:

In order to maintain shared context of the group and to provide access
to the proceedings of the group, the Chair maintains a web page
at http://w3.org/XML-DSig/.

Active participants are expected to have ready access to this page
and be familiar with its contents.

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.

IETF / W3C PROCESS SYNCHRONIZATION:

WG documents will be dual published in both the IETF as Internet-Drafts
or RFCs and in the W3C, via the web. 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 (Working
Group or IETF Last Call in the IETF, W3C Team Last Call or AC Review in
the W3C) comments received in both venues must be considered and
responded to.  In effect, this postpones the end of the Last Call
that would have ended sooner until the end of the Last Call is the
other organization.

The rough equivalence between document types in the IETF and W3C
is as follows:

       IETF                                  W3C
    Informational RFC                     Note
    Working Group Internet Draft          Working Draft
    Working Group Informational RFC       Working Draft
    Proposed Standard RFC                 Proposed Recommendation
    Draft Standard RFC                    Recommendation
    Full Standard RFC                     Recommendation

Recycling of a document in grade in either venue will cause
a corresponding document classification in the other venue.

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

DECISON PROCEDURES AND APPEALS:

The working group 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.

IPR DISCLOSURE:

Working group members must disclose any intellectual property rights
brought into this WG by following both IETF and W3C procedure; that
is, at a minimum, by email to (patent-issues@w3.org)  and the IETF
Executive Director (iesg-secretary@ietf.org)

TIME TABLE:

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.

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.