XML Key Management Working Group Charter

Charter

Chair(s):

TBS <TBS>

W3C Technology and Society Domain Leader

Daniel Weitzner <djw@w3.org>

Introduction

The XML Key Management Specification (XKMS) comprises two parts -- the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

The X-KISS specification defines a protocol for a Trust service that resolves public key information contained in XML Signature elements. The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds:KeyInfo> elements. A key objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients and thereby to be shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. The underlying PKI may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

The X-KRSS specification defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS.

Table of Contents

• Mission Statement
• Scope
  • Requirements
  • Constraints
  • Demonstration Applications
• Deliverables
• Duration and Milestones
• Confidentiality
• Coordination with Other Groups
• Communication Mechanisms
  • Group Home Page
  • Mailing List
  • Teleconferences
  • Face to Face Meetings
  • Communications with the Public
• IPR Disclosure
• Participants
  • Team
  • Member
  • Individual

Mission Statement

The mission of this working group is to develop an XML application protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service.

Scope

The core scope of this Working Group will be in specifying the necessary protocol elements and Trust Service behavior for the XML Key Management Specification.

The Working Group (WG) will:

1. Refine, revise and amend the XKMS specification to:
   • Correct errors and remove ambiguity.
   • Align with standards track proposals.
   • Apply lessons learned from implementation and interoperability testing.
   • Verify that desired behavior is achieved
   • Specify the requirements that are met by XKMS.
2. Produce non-normative document(s) that set out best practices for applying XKMS to applications that may include:
   • Chained XKMS Services (including the n-corners model).
   • Interoperation with existing  X.509 and PGP based applications.
3. Optionally produce a document that extends the XKMS specification to provide support for bulk registration of keys to be embedded in hardware devices (e.g. cable modems and smartcards).
4. Propose a new/revised charter for approval by the AC for subsequent work once 1 and 2 have been achieved.

The priority of the group shall be to achieve 1 and 2. However it is advantageous to consider at least one concrete example when considering the future extensibility of a specification and therefore the group may consider 3 at the same time as 1 provided that this does not delay the completion of the priority items.

Requirements

The following additional requirements must be met by the WG; these requirements may be augmented and extended by the requirements document: 

1. The PKI Interface must be simple and build upon the <ds:KeyInfo> element specified by XML Signature.
2. XKMS must be coordinated with and use the work product of other mature XML technologies including XML Schema, XML Signature and XML Encryption. (See Coordination)
3. All required,recommended, and optional features of the specification must be implemented in at least two independent implementations before being advanced to Proposed Recommendation.

Constraints

The working group will not address the following issues:

1. Design of new cryptographic algorithms.
2. Issues of Non Repudiation, including but not limited to 'technical non-repudiation' and 'contractual non-repudiation'.
3. Sources of Trusted Time.
4. Models and data structures for establishing inter-domain trust, including but not limited to 'cross-certification'.
5. Expression of existing PKI data structures in XML.
6. Specification of inter-domain trust semantics.
7. Authorization and Authorization Assertions.
8. Attribute Certificates.
9. Knowledge representation syntax.

Deliverables

This working group will deliver the following:

1. A W3C Working Draft that captures the requirements 
2. One or more W3C Recommendation(s) that define the XKMS Protocol
3. An optional W3C Recommendation that defines a Protocol based on XKMS for bulk registrations.
4. An optional W3C Note describing best practices for configuring XKMS applications and Trust Services to permit clients that do not provide support for certificate based PKI to interact with existing certificate based applications.
5. An optional W3C Note describing best practices for configuring XKMS to support chained service applications, including the n-corners transaction model.
6. An optional W3C Note describing architectural options for using XKMS to support security mechanisms for other Web Services.
7. If appropriate, draft charters for further work.

Duration and Milestones

This Working Group is scheduled for eleven months. Currently, its expected lifetime is from October 2001 through August 2002. Last Call candidates should be available by November 2001.

July 2001

XKMS Workshop

October 2001

Working Group face-to-face meeting

November 2001

Last Call for Requirements Document

January 2002

Last Call for XKMS & X-Bulk Specification

March  2002

Candidate Recommendation for XKMS & X-Bulk Specification

June 2002

Proposed Recommendation for XKMS & X-Bulk Specification

August 2002

Recommendation for XKMS & X-Bulk Specification

Once established, the Working Group can decide to perform tasks in parallel by forming subgroups. These dates are subject to revision due to editorial needs and external scheduling issues; updates will be negotiated with the affected working groups and participants and recorded on the XML Key Management WG home page. Any change in a deliverable date must be brought to the attention of the W3C Domain leader and Director.

Confidentiality

This charter, the WG web page, and the mailing list and archives will be publicly accessible.

Coordination with Other Groups

W3C Activities

XML and XML derived activities have become a strategic technology in W3C and elsewhere. 

The Working Group shall solicit comments from the following W3C working groups on the proposed requirements and during W3C Last Call, the Chair will procure reviews before the specification will be advanced further:

XML Activity

The XKMS Working Group will be represented in the XML Coordination Group to coordinate with other activities represented in this group.

XML Protocol

The XKMS WG shall specify a protocol binding of XKMS based on XML Protocol, the normative status of this binding shall be dependent on the status of the XML Protocol binding at the time the XKMS WG presents its recommendation.

XML Signature

XML Signature is a Candidate Recommendation.

XML Encryption

XML Encryption has issued a draft requirements document.

At the current time, there are no known dependencies on the work produced by the Working Group.

External Groups

The XML Protocol Working Group should liaise with at least the following groups outside W3C:

IETF

The Working Group will cooperate closely with the IETF on the use of XKMS to interface to a PKIX conformant PKI. In addition the Working Group will cooperate closely with IETF Working Groups that may develop profiles for making use of XKMS (e.g. S/MIME, TLS, IPSEC, DNSSEC)

IETF-SACRED

The Working group will liaise with the IETF SACRED group with the objective of harmonizing the SACRED protocol layer with the X-KRSS roaming operation.

ebXML

The Working Group will liaise via cross-participation with the Transport, Routing and Packaging project team within ebXML (electronic business XML). ebXML is a joint activity of UN/CEFACT (the United Nations body responsible for UN/EDIFACT), the international EDI standard, and OASIS (Organization for the Advancement of Structured Information Standards).

SAML

The Working Group will liaise via cross-participation with the OASIS Security Services Technical Committee developing the Security Assertions Markup Language Specification.

WAP Forum

The Working group will liaise via cross-participation with the WAP Forum to develop a XKMS profile for WAP devices.

European Telecommunications Standards Institute

The Working group will consider the impact of the ETSI XML Advanced Electronic Signatures proposal.

Communication Mechanisms

Working group members are expected to participate in an electronic mailing list, periodic teleconferences and face-to-face meetings. The WG consensus venue is the mailing list. Note, straw polls and assessments of consensus may be taken on teleconferences and face-to-face meetings which will then be sent to the list via minutes. If those decision are not opposed or questioned on the list, they naturally stand as the WG's consensus.

(See Participants for information on the roles and commitments of working group members.)

NOTE: The proceedings of this Working Group are public.

Group Home Page

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://www.w3.org/XKMS/ (tbd).

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

Mailing List

Participants must subscribe to and participate in the (www-xkms@w3.org) mailing list.

Teleconferences

As necessary, the Chair may convene teleconferences periodically for the purpose of quickly addressing and resolving open issues and tracking action items and deliverables.

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.

A public IRC channel should be available to complement/coordinate teleconference discussion. However, the IRC conversation is not necessarily part of the record: it must be stated on the teleconference as an IRC message is not necessarily a sufficient communication to the others on the teleconference.

Face to Face Meetings

The working group will have a day face to face meeting in October 2001. Meeting notice, advance agenda, and posting of minutes shall follow W3C timing rules.

Communication with the Public

This working group is public.

IPR Disclosure

W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims. W3C's policy for intellectual property is set out in section 1.5 of the W3C Process document.

Members of the XML Key Management Working Group and any other Working Group constituted within the XML Key Management Activity are expected to disclose any intellectual property they have in this area. Any intellectual property essential to implement specifications produced by this Activity must be at least available for licensing on a royalty-free basis. At the suggestion of the Working Group, and at the discretion of the Director of W3C, technologies may be accepted if they are licensed on reasonable, non-discriminatory terms.

Members disclose patent and other IPR claims by sending email to the publicly archived WG list and the archived patent issues list (that is readable by W3C Members and the W3C team): patent-issues@w3.org. Members must disclose all IPR claims to this mailing list but they may also copy other recipients.

The principal authors of the XKMS protocol have entered into a memorandum of understanding under which all Intellectual Property Rights the parties may have acquired would on formation of a W3C working group to standardize XKMS be made available to all implementers of the protocol under a non-discriminatory royalty free license.

Declaration of [Submitter]

[Submitter] hereby grants to the W3C, a perpetual, nonexclusive, royalty-free, world-wide right and license under any [Submitter] copyrights in this contribution to copy, publish and distribute the contribution, as well as a right and license of the same scope to any derivative works prepared by the W3C and based on, or incorporating all or part of the contribution. [Submitter] further agrees that any derivative works of this contribution prepared by the W3C shall be solely owned by the W3C.

Participants

This section describes the expectations and requirements of Staff, Member, and Public commitment necessary for this Working Group to be started -- and eventually succeed. The actual roles (chair, author, editor, contributor, implementor) and definitions are to be defined by W3C Process and to be compatible with those of the XML Signature Working Group Contributor Policies.

Contributors to this working group are expected to commit to 15% (6 hours a week).   Commitments for Author and Editor positions are 25% and 35% respectively.

4.4.1 W3C Team commitment

The W3C Team will dedicate 20% of a single person to this activity for active WG participation and the Staff Contact role: liasoning with other Staff Contacts of identified WGs, and advising the Chair and WG on W3C Process and Publishing.

4.4.2 W3C Member commitment

This is a public working group and anyone may contribute to the Working Group. However, at the outset of the Activity, the interested W3C member organizations are expected to identify one or more individual contributors to the Working Group and the level of contribution at which they are willing to participate.

4.4.3 Public/Individual commitment

Public contributors are welcome to commit to the completion of any action item or to the fulfillment of the roles described in the Contributor Policies. Note, materials sent to the public list are part of the W3C site and subject to W3C policies and licenses. The W3C holds the copyright of all Working Group deliverables (e.g., specifications).