Another abandoned server code base... this is kind of an ancestor of taskrambler.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

1395 lines
49 KiB

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator"
content="HTML Tidy for Linux/x86 (vers 1st February 2002), see www.w3.org" />
<title>
XML Key Management Specification Bulk Operation (X-BULK)
</title>
<style type="text/css">
/*<![CDATA[*/
/**/
/**/
u,ins { background: white; color: red;}
del,strike,.strike { background: white; color: silver; text-decoration: line-through;}
code {font-weight: normal; }
.link-def { background: #FFFFFF; color: teal; font-style: italic;}
.comment { background: #FFFFF5; color: black; padding: .7em; border:
navy thin solid;}
.discuss { color: blue; background: yellow; }
.xml-example,.xml-dtd { margin-left: -1em; padding: .5em; white-space:
pre; border: none;}
.xml-dtd { background: #efeff8; color: black;}
/**/
/**/
/*]]>*/
</style>
<link href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" type="text/css"
rel="stylesheet" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body xml:lang="en" lang="en">
<p>
<a href="http://www.w3.org/"><img height="48" alt="W3C"
src="http://www.w3.org/Icons/w3c_home" width="72" /></a>
</p>
<div class="head">
<h1 class="notoc">
XML Key Management Specification Bulk Operation (X-BULK)
</h1>
<h2 class="notoc">
W3C Working Draft 18 March 2002
</h2>
<dl>
<dt>
This version:
</dt>
<dd>
<a
href="http://www.w3.org/TR/2002/WD-xkms2-xbulk-20020318">http://www.w3.org/TR/2002/WD-xkms2-xbulk-20020318/</a>
</dd>
<dt>
Latest version:
</dt>
<dd>
<a
href="http://www.w3.org/TR/xkms2-xbulk/">http://www.w3.org/TR/xkms2-xbulk/</a>
</dd>
<dt>
Previous version:
</dt>
<dd>
n/a
</dd>
<dt>
Editor:
</dt>
<dd>
Merlin Hughes, Baltimore Technologies, <a
href="mailto:merlin@baltimore.ie">merlin@baltimore.ie</a>
</dd>
</dl>
<p class="copyright">
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
&copy; 2002 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.
</p>
<hr title="Separator from Header" />
</div>
<h2 class="notoc">
Abstract
</h2>
<p>
This document extends the XML Key Management Specification [<a
href="#ref-XKMS">XKMS</a>] protocol to encompass the bulk registration operations
necessary for interfacing with such systems as smart card management systems.
</p>
<p>
X-BULK is defined in terms of structures expressed in the XML Schema Language [<a
href="#ref-XML-Schema">XML-Schema</a>] and web services description language [<a
href="#ref-WSDL">WSDL</a>].
</p>
<h2>
<a id="status" name="status">Status of this document</a>
</h2>
<div class="">
<p>
This is the first draft of the "XML Key Management Specification Bulk Operation
(X-BULK)" specification from the<a
href="http://www.w3.org/2001/XKMS/Overview.html">W3C XML Key Management Working
Group</a> (<a href="http://www.w3.org/2001/XKMS/Activity.html">Activity
Statement</a>). This version contains points which are still under discussion
or are not well specified.
</p>
<p>
The Working Group will try to <a href="http://www.w3.org/1999/10/nsuri">use a
new namespace</a> when changes in its syntax or processing are substantive.
However, this namespace might be reused (prior to reaching Candidate
Recommendation) by subsequent drafts in such a way as to cause instances using
the namespace to become invalid or to change in meaning or affect the operation
of existing software. Requests for a more stringent level of namespace
stability should be made to the Working Group.
</p>
<p>
Publication of this document 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 a W3C Working Draft as
anything other than a "work in progress." Please send comments to the editor
and cc: the list <a href="mailto:www-xkms@w3.org">www-xkms@w3.org</a> (pubicly
<a href="http://lists.w3.org/Archives/Public/www-xkms/">archived</a>).
</p>
<p>
Patent disclosures relevant to this specification may be found on the Working
Group's<a href="http://www.w3.org/2001/XKMS/Disclosures.html">patent disclosure
page</a>in conformance with W3C.
</p>
<p>
A list of current W3C working drafts can be found at <a
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
</p>
</div>
<h2>
<a id="contents" name="contents">Table of Contents</a>
</h2>
<ol>
<li>
<a href="#sec-Intro">Introduction</a>
<ol>
<li>
<a href="#sec-Overview">Overview</a>
</li>
<li>
<a href="#sec-Namespaces">Namespaces</a>
</li>
<li>
<a href="#sec-Operations">Bulk Operations Service Specification</a>
</li>
<li>
<a href="#sec-Editorial">Editorial and Conformance Conventions</a>
</li>
<li>
<a href="#sec-Structure">Structure of this Document</a>
</li>
</ol>
</li>
<li>
<a href="#sec-Messages">X-BULK Messages</a>
<ol>
<li>
<a href="#sec-BatchHeader">The <code>BatchHeader</code> element</a>
<ol>
<li>
<a href="#sec-ProcessInfo">The <code>ProcessInfo</code> element</a>
</li>
</ol>
</li>
<li>
<a href="#sec-BulkRegister">The <code>BulkRegister</code> message</a>
<ol>
<li>
<a href="#sec-Respond">The <code>xkms:Respond</code> element</a>
</li>
<li>
<a href="#sec-Requests">The <code>Requests</code> element</a>
</li>
<li>
<a href="#sec-Request">The <code>Request</code> element</a>
</li>
<li>
<a href="#sec-Request-KeyInfo">The <code>dsig:KeyInfo</code>
element</a>
</li>
<li>
<a href="#sec-ClientInfo">The <code>ClientInfo</code> element</a>
</li>
<li>
<a href="#sec-BulkRegister-Example">Example</a>
</li>
</ol>
</li>
<li>
<a href="#sec-BulkRegisterResult">The <code>BulkRegisterResult</code>
element</a>
<ol>
<li>
<a href="#sec-RegisterResults">The <code>RegisterResults</code>
element</a>
</li>
<li>
<a href="#sec-BulkRegisterResult-Example">Example</a>
</li>
</ol>
</li>
<li>
<a href="#sec-BulkStatus">BulkStatus</a>
<ol>
<li>
<a href="#sec-BulkStatus-Example">Example</a>
</li>
</ol>
</li>
<li>
<a href="#sec-BulkStatusResult">BulkStatusResult</a>
<ol>
<li>
<a href="#sec-StatusResult">The <code>StatusResult</code> element</a>
</li>
<li>
<a href="#sec-BulkStatusResult-Example">Example</a>
</li>
</ol>
</li>
<li>
<a href="#sec-6">New children of <code>dsig:KeyInfo</code></a>
<ol>
<li>
<a href="#sec-PKCS1">The <code>PKCS1</code> element</a>
</li>
<li>
<a href="#sec-PKCS10">The <code>PKCS10</code> element</a>
</li>
</ol>
</li>
</ol>
</li>
<li>
<a href="#sec-Schema">Schema Definition</a>
</li>
<li>
<a href="#sec-WSDL">WSDL</a>
</li>
<li>
<a href="#sec-References">References</a>
</li>
<li>
<a href="#sec-Acknowledgements">Acknowledgements (Informative)</a>
</li>
</ol>
<hr />
<!-- =============================================================================== -->
<h2>
<a id="sec-Intro" name="sec-Intro"></a>1. Introduction
</h2>
<p>
XKMS currently addresses one-by-one registration (X-KRSS) and key information and
validation services (X-KISS). However, we feel that a standard must also address
bulk issuance cases and are proposing that an X-BULK specification, built on the
basis of X-KRSS be included in scope of the work.
</p>
<h3>
<a id="sec-Overview" name="sec-Overview"></a>1.1 Overview
</h3>
<p>
The use cases where X-BULK is required include:
</p>
<ul>
<li>
Smart card factories for enterprise, wireless and cable-modem applications
</li>
<li>
Device factories in general (e.g. TCPA-like TPM modules)
</li>
<li>
To handle functionality analogous to separated RAs and CAs from the X.509 world
</li>
</ul>
<p>
Key differences between X-KRSS and X-BULK include:
</p>
<ul>
<li>
X-BULK is required to correlate batches of requests and responses.
</li>
<li>
X-KRSS doesn't support some legacy key registration formats (e.g. PKCS#10),
which are important for existing hardware modules.
</li>
<li>
Authentication and response profiling should be at the level of the batch, not
the individual request.
</li>
<li>
Batch status is not the same as key status.
</li>
<li>
X-BULK addresses interfacing with card administration and deployment back-end
servers (a.k.a. card management systems).
</li>
</ul>
<p>
X-BULK does however reuse element definitions from the current X-KRSS
specification.
</p>
<p>
Separating bulk from one-by-one registration has the benefit that the separately
defined messages required are simpler than if a single message format handling
both one-by-one and bulk cases were to be defined. It is also better not to
burden a client for one-by-one operation with the additional complexity required
in batch operation.
</p>
<p>
Demand for this functionality is shown by the emergence of a number of
proprietary solutions in this space.
</p>
<p>
Design criteria include:
</p>
<ul>
<li>
Consistency with and reuse of [<a href="#ref-XKMS">XKMS</a>]
</li>
<li>
To handle batches of register requests and responses
</li>
<li>
To handle legacy cryptographic formats prevalent in current hardware
environments, in particular, [<a href="#ref-PKCS10">PKCS10</a>] and [<a
href="#ref-PKCS1">PKCS1</a>] as well as KeyInfo from [<a
href="#ref-XMLDSIG">XMLDSIG</a>]
</li>
<li>
To handle both client and server side key generation
</li>
<li>
Simplicity and flexibility
</li>
</ul>
<h3>
<a id="sec-Namespaces" name="sec-Namespaces"></a>1.2 Namespaces
</h3>
<p>
For clarity, some examples of XML are not complete documents and namespace [<a
href="#ref-XML-Names">XML-Names</a>] declarations may be omitted from XML
fragments. In this document, certain namespace prefixes represent certain
namespaces. References to XML schema defined herein use the prefix
<code>xbulk</code> and are in the namespace <a
href="http://www.w3.org/2002/03/xkms-xbulk">http://www.w3.org/2002/03/xkms-xbulk</a>.
</p>
<p>
This specification makes use of the [<a href="#ref-XKMS">XKMS</a>] and [<a
href="#ref-XMLDSIG">XMLDSIG</a>] namespaces and schema definitions:
</p>
<pre class="xml-example">
xmlns:xkms='<a
href="http://www.w3.org/2002/03/xkms">http://www.w3.org/2002/03/xkms</a>'
xmlns:dsig='<a
href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>'
</pre>
<h3>
<a id="sec-Operations" name="sec-Operations"></a>1.3 Bulk Operations Service
Specification
</h3>
<p>
X-BULK defines a batch element that can contain registration requests, responses
and status requests. The basic idea is that a single batch can contain a number
of independently referencable requests or responses. Batches are produced both
from the requestor and responder. A responder will process an entire batch and
produce a single batch of responses after processing.
</p>
<p>
All batches MUST be authenticated; that is, the originator of a batch must be
able to protect the batch. Implementations MUST support the RSA algorithm for
digitally signing batches. Implementations MUST be capable of using the XKMS
Register operation for the registration of the keys used to authenticate batches.
</p>
<p>
Implementations MUST include a <code>dsig:X509Data</code> element in the
Signature, which is used together with the <code>BatchID</code> to ensure batch
uniqueness.
</p>
<p>
The basic mode of operation is that a batch of requests is submitted. The
responder processes the batch and produces a response batch that contains one
response for each request in the batch. Other, more flexible modes of operation
may be defined later (e.g. allowing responses to be spread over multiple
batches). This mode of "full batch processing" is sufficient for most use cases
and is considerably simpler than supporting "selective batch processing."
</p>
<p>
Each batch has a header that identifies the batch (and can contain additional
unprocessed information).
</p>
<p>
In order to allow the requestor to track the progress of batch processing
implementations MAY support status requests. A status request is a request to
determine the status of processing of the referenced batch. The response gives a
simple indication of the numbers of requests from the batch that are in the
various possible states (processed, failed, etc.).
</p>
<p>
A batch response contains one response for each request, not necessarily in the
same order as in the request batch. That is, requestors MUST be able to handle
responses that are not sorted in any particular way.
</p>
<p>
In many use cases, the requestor requires "additional information" to be "carried
around" with a batch or request, but which is not intended for processing by the
responder.
</p>
<p>
Responders MAY also add more additional information to the specific responses.
Requestors MUST be able to handle such additional information.
</p>
<p>
The basic request and response structures are as in [XKMS] and can support the
same level of functionality (registration of new keys, local/central key
generation, revocation, etc.).
</p>
<h3>
<a id="sec-Editorial" name="sec-Editorial"></a>1.4 Editorial and Conformance
Conventions
</h3>
<p>
This specification uses XML Schemas [<a href="#ref-XML-Schema">XML-Schema</a>] to
describe the content model.
</p>
<p>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to
be interpreted as described in RFC2119 [<a href="#ref-Keywords">Keywords</a>]:
</p>
<blockquote>
<p>
"they MUST only be used where it is actually required for interoperation or to
limit behavior which has potential for causing harm (e.g., limiting
retransmissions)"
</p>
</blockquote>
<p>
Consequently, we use these capitalized keywords to unambiguously specify
requirements over protocol and application features and behavior that affect the
interoperability and security of implementations. These key words are not used
(capitalized) to describe XML grammar; schema definitions unambiguously describe
such requirements and we wish to reserve the prominence of these terms for the
natural language descriptions of protocols and features. For instance, an XML
attribute might be described as being "optional." Compliance with the
XML-namespace specification [<a href="#ref-XML-Names">XML-Names</a>] is described
as "REQUIRED."
</p>
<h3>
<a id="sec-Structure" name="sec-Structure"></a>1.5 Structure of this Document
</h3>
<p>
The remainder of this document describes the X-BULK messages, first the "outside"
elements, then the request specifics, the status messages and finally the
response elements. Finally the complete schema for X-BULK and the [<a
href="#ref-WSDL">WSDL</a>] definition are presented.
</p>
<h2>
<a id="sec-Messages" name="sec-Messages"></a>2. X-BULK Messages
</h2>
The header of the schema definition is as follows:
<pre class="xml-dtd">
Schema Definition:
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;schema
targetNamespace="http://www.w3.org/2002/03/xkms-xbulk"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xkms="http://www.w3.org/2002/03/xkms"
xmlns:xbulk="http://www.w3.org/2002/03/xkms-xbulk"
xmlns="http://www.w3.org/2000/10/XMLSchema"&gt;
&lt;import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/&gt;
&lt;import namespace="http://www.w3.org/2002/03/xkms" schemaLocation="xkms-20010330.xsd"/&gt;
&lt;annotation&gt;
&lt;documentation xml:lang="en"&gt;
XML Schema for X-BULK version 1.1 draft 5
&lt;/documentation&gt;
&lt;/annotation&gt;
</pre>
<h3>
<a id="sec-BatchHeader" name="sec-BatchHeader"></a>2.1 The
<code>BatchHeader</code> element
</h3>
<p>
The header is common to all the elements in this document; it will contain the
following information:
</p>
<ul>
<li>
A batch ID
</li>
<li>
A batch creation date
</li>
<li>
Additional processing information for the responder.
</li>
</ul>
<p>
BatchID combined with the originating party X509Data (from the Signature) MUST be
unique at a given moment in time.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="BatchHeaderType"&gt;
&lt;choice minOccurs="0" maxOccurs="unbounded"&gt;
&lt;sequence&gt;
&lt;element name="BatchID" type="string"/&gt;
&lt;element name="BatchTime" type="dateTime"/&gt;
&lt;element name="NumberOfRequests" type="positiveInteger"/&gt;
&lt;element ref="xbulk:ProcessInfo" minOccurs="0"/&gt;
&lt;/sequence&gt;
&lt;/choice&gt;
&lt;/complexType&gt;
&lt;element name="BatchHeader" type="xbulk:BatchHeaderType"/&gt;
</pre>
<h4>
<a id="sec-ProcessInfo" name="sec-ProcessInfo"></a>2.1.1 The
<code>ProcessInfo</code> element
</h4>
<p>
Things like customer name, that are not actually required for the batch to be
processed, MAY be included as <code>ProcessInfo</code>.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="ProcessInfoType"&gt;
&lt;sequence minOccurs="1" maxOccurs="unbounded"&gt;
&lt;any namespace="##other"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="ProcessInfo" type="xbulk:ProcessInfoType"/&gt;
</pre>
<h3>
<a id="sec-BulkRegister" name="sec-BulkRegister"></a>2.2 The
<code>BulkRegister</code> message
</h3>
<p>
The <code>BulkRegister</code> message is an XML element that consists of a
<code>BatchHeader</code>, a response profile, a sequence of requests and a
Signature over the header and requests.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="BulkRegisterType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xkms:Respond" minOccurs="0"/&gt;
&lt;element ref="xbulk:Requests"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="ds:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkRegister" type="xbulk:BulkRegisterType"/&gt;
</pre>
<h4>
<a id="sec-Respond" name="sec-Respond"></a>2.2.1 The <code>xkms:Respond</code>
element
</h4>
<p>
A global <code>xkms:Respond</code> element may be used to profile all requests
that do not contain a more specific setting. It can, for example, indicate that,
unless otherwise specified, the requests are for:
</p>
<ul>
<li>
X509Cert (an X.509 certificate)
</li>
<li>
RetrievalMethod (Certificate URLs (LDAP or HTTP))
</li>
</ul>
<p>
The full set of allowed <code>Respond</code> values is defined in [XKMS].
Implementations MUST support: KeyName, KeyValue, X509Cert, X509Chain,
RetrievalMethod and Private.
</p>
<h4>
<a id="sec-Requests" name="sec-Requests"></a>2.2.2 The <code>Requests</code>
element
</h4>
<p>
The <code>Requests</code> consists of an unbounded number of <code>Request</code>
elements. The number of <code>Request</code> elements MUST be specified in the
<code>number</code> attribute of <code>Requests</code>.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="RequestsType"&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:Request" maxOccurs="unbounded"/&gt;
&lt;/sequence&gt;
&lt;attribute name="number" use="required"/&gt;
&lt;/complexType&gt;
&lt;element name="Requests" type="xbulk:RequestsType"/&gt;
</pre>
<h4>
<a id="sec-Request" name="sec-Request"></a>2.2.3 The <code>Request</code> element
</h4>
<p>
A <code>Request</code> MUST contain a <code>KeyID</code>, which must be unique
within the batch (this can anything; examples include a smart card serial number
, a MAC Address (cable modem), ICCID (used by S/WIM cards) or even simply 1,2,3),
and a <code>dsig:KeyInfo</code> with keying information about the request.
</p>
<p>
A <code>Request</code> may also contain <code>xkms:Respond</code>,
<code>ClientInfo</code>, and <code>ProcessInfo</code> elements.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="RequestType"&gt;
&lt;sequence&gt;
&lt;element ref="xkms:KeyID"/&gt;
&lt;element ref="dsig:KeyInfo"/&gt;
&lt;element ref="xkms:Respond" minOccurs="0"/&gt;
&lt;element ref="xbulk:ProcessInfo" minOccurs="0"/&gt;
&lt;element ref="xbulk:ClientInfo" minOccurs="0"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="Request" type="xbulk:RequestType"/&gt;
</pre>
<h4>
<a id="sec-Request-KeyInfo" name="sec-Request-KeyInfo"></a>2.2.4 The
<code>dsig:KeyInfo</code> element
</h4>
<p>
The following types of <code>dsig:KeyInfo</code> within a <code>Request</code>
MUST be supported:
</p>
<ul>
<li>
A <code>PKCS10</code> request
</li>
<li>
An <code>dsig:X509SubjectName</code> and key data (in which case the key data
can either be a <code>dsig:KeyValue</code> or a <code>PKCS1</code> public key)
</li>
<li>
An <code>dsig:X509SubjectName</code> without key data (server generated keys)
</li>
</ul>
<p>
In addition, the following KeyInfo types from [XMLDSIG] SHOULD be supported:
<code>dsig:KeyName</code>, <code>dsig:KeyValue</code>,
<code>dsig:RetrievalMethod</code>, and <code>dsig:X509Data</code>.
</p>
<h4>
<a id="sec-ClientInfo" name="sec-ClientInfo"></a>2.2.5 The
<code>ClientInfo</code> element
</h4>
<p>
<code>ClientInfo</code>, if present, MUST be ignored and treated as opaque data
by the responder. This element must be returned in the corresponding
<code>RegisterResult</code> element. This can be used by the client for
bookkeeping.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="ClientInfoType"&gt;
&lt;sequence maxOccurs="unbounded"&gt;
&lt;any namespace="##other"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="ClientInfo" type="xbulk:ClientInfoType"/&gt;
</pre>
<h4>
<a id="sec-BulkRegister-Example" name="sec-BulkRegister-Example"></a>2.2.6
Example
</h4>
<p>
An example <code>BulkRegister</code> message follows:
</p>
<pre class="xml-example">
&lt;BulkRegister xmlns="http://www.w3.org/2002/03/xkms-xbulk"&gt;
&lt;SignedPart Id="id-0"&gt;
&lt;BatchHeader&gt;
&lt;BatchID&gt;batch-0&lt;/BatchID&gt;
&lt;BatchTime&gt;1999-05-31T13:20:00-05:00&lt;/BatchTime&gt;
&lt;NumberOfRequests&gt;2&lt;/NumberOfRequests&gt;
&lt;/BatchHeader&gt;
&lt;xkms:Respond xmlns:xkms="http://www.w3.org/2002/03/xkms"&gt;
&lt;string xmlns=""&gt;X509Cert&lt;/string&gt;
&lt;/xkms:Respond&gt;
&lt;Requests number="2"&gt;
&lt;Request&gt;
&lt;xkms:KeyID xmlns:xkms="http://www.w3.org/2002/03/xkms"&gt;
mailto:bar@foo.com
&lt;/xkms:KeyID&gt;
&lt;dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;dsig:X509Data&gt;
&lt;dsig:X509SubjectName&gt;CN=Bar Foo&lt;/dsig:X509SubjectName&gt;
&lt;/dsig:X509Data&gt;
&lt;dsig:KeyValue&gt;
&lt;dsig:RSAKeyValue&gt;
&lt;dsig:Modulus&gt;...&lt;/dsig:Modulus&gt;
&lt;dsig:Exponent&gt;AQAB&lt;/dsig:Exponent&gt;
&lt;/dsig:RSAKeyValue&gt;
&lt;/dsig:KeyValue&gt;
&lt;/dsig:KeyInfo&gt;
&lt;ClientInfo&gt;
&lt;EmployeeID xmlns="urn:foo"&gt;6&lt;/EmployeeID&gt;
&lt;/ClientInfo&gt;
&lt;/Request&gt;
&lt;Request&gt;
&lt;xkms:KeyID xmlns:xkms="http://www.w3.org/2002/03/xkms"&gt;
mailto:baz@foo.com
&lt;/xkms:KeyID&gt;
&lt;dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;dsig:X509Data&gt;
&lt;dsig:X509SubjectName&gt;CN=Baz Foo&lt;/dsig:X509SubjectName&gt;
&lt;/dsig:X509Data&gt;
&lt;dsig:KeyValue&gt;
&lt;dsig:RSAKeyValue&gt;
&lt;dsig:Modulus&gt;...&lt;/dsig:Modulus&gt;
&lt;dsig:Exponent&gt;AQAB&lt;/dsig:Exponent&gt;
&lt;/dsig:RSAKeyValue&gt;
&lt;/dsig:KeyValue&gt;
&lt;/dsig:KeyInfo&gt;
&lt;ClientInfo&gt;
&lt;EmployeeID xmlns="urn:foo"&gt;007&lt;/EmployeeID&gt;
&lt;/ClientInfo&gt;
&lt;/Request&gt;
&lt;/Requests&gt;
&lt;/SignedPart&gt;
&lt;dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
... URI="#id-0" ...
&lt;/dsig:Signature&gt;
&lt;/BulkRegister&gt;
</pre>
<h3>
<a id="sec-BulkRegisterResult" name="sec-BulkRegisterResult"></a>2.3 The
<code>BulkRegisterResult</code> element
</h3>
<p>
The <code>BulkRegisterResult</code> contains the header and a certificate
response for each request that was in the batch. The element contains a
<code>BatchHeader</code>, <code>RegisterResults</code>, and
<code>dsig:Signature</code>.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="BulkRegisterResultType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xbulk:RegisterResults"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/&gt;
</pre>
<h4>
<a id="sec-RegisterResults" name="sec-RegisterResults"></a>2.3.1 The
<code>RegisterResults</code> element
</h4>
<p>
The <code>RegisterResults</code> element contains one (and only one)
<code>RegisterResult</code> for each and every <code>Request</code> element in
the corresponding <code>BulkRegister</code>. The number of
<code>RegisterResult</code> elements MUST be an attribute to
<code>RegisterResults</code>.
</p>
<p>
<code>RegisterResult</code> is defined in [<a href="#ref-XKMS">XKMS</a>]; its
contents are dictated by the <code>Respond</code> elements in the
<code>BulkRegister</code>.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="RegisterResultsType"&gt;
&lt;sequence&gt;
&lt;element ref="xkms:RegisterResult" maxOccurs="unbounded"/&gt;
&lt;/sequence&gt;
&lt;attribute name="number" use="required"/&gt;
&lt;/complexType&gt;
&lt;element name="RegisterResults" type="xbulk:RegisterResultsType"/&gt;
</pre>
<h4>
<a id="sec-BulkRegisterResult-Example"
name="sec-BulkRegisterResult-Example"></a>2.3.2 Example
</h4>
<p>
A sample response to the first example request:
</p>
<pre class="xml-example">
&lt;BulkRegisterResult xmlns="http://www.w3.org/2002/03/xkms-xbulk"&gt;
&lt;SignedPart Id="id-0"&gt;
&lt;BatchHeader&gt;
&lt;BatchID&gt;batch-0&lt;/BatchID&gt;
&lt;BatchTime&gt;1999-05-31T13:20:00-05:00&lt;/BatchTime&gt;
&lt;NumberOfRequests&gt;2&lt;/NumberOfRequests&gt;
&lt;/BatchHeader&gt;
&lt;RegisterResults number="2"&gt;
<em>&lt;!-- xkms:RegisterResult is not the appropriate type --&gt;</em>
&lt;xkms:RegisterResult xmlns:xkms="http://www.w3.org/2002/03/xkms"&gt;
&lt;xkms:Result&gt;Success&lt;/xkms:Result&gt;
&lt;xkms:Answer&gt;
&lt;xkms:Status&gt;Valid&lt;/xkms:Status&gt;
&lt;xkms:KeyID&gt;
mailto:bar@foo.com
&lt;/xkms:KeyID&gt;
&lt;dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;dsig:X509Data&gt;
&lt;dsig:X509Certificate&gt;...&lt;/dsig:X509Certificate&gt;
&lt;/dsig:X509Data&gt;
&lt;/dsig:KeyInfo&gt;
&lt;/xkms:Answer&gt;
&lt;/xkms:RegisterResult&gt;
&lt;xkms:RegisterResult xmlns:xkms="http://www.w3.org/2002/03/xkms"&gt;
&lt;xkms:Result&gt;Success&lt;/xkms:Result&gt;
&lt;xkms:Answer&gt;
&lt;xkms:Status&gt;Valid&lt;/xkms:Status&gt;
&lt;xkms:KeyID&gt;
mailto:baz@foo.com
&lt;/xkms:KeyID&gt;
&lt;dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;dsig:X509Data&gt;
&lt;dsig:X509Certificate&gt;...&lt;/dsig:X509Certificate&gt;
&lt;/dsig:X509Data&gt;
&lt;/dsig:KeyInfo&gt;
&lt;/xkms:Answer&gt;
&lt;/xkms:RegisterResult&gt;
&lt;/RegisterResults&gt;
&lt;/SignedPart&gt;
&lt;dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
... URI="#id-0" ...
&lt;/dsig:Signature&gt;
&lt;/BulkRegisterResult&gt;
</pre>
<h3>
<a id="sec-BulkStatus" name="sec-BulkStatus"></a>2.4 BulkStatus
</h3>
<p>
The <code>BulkStatusRequest</code> is a request for the current status of a
batch. The batch is identified by its header. The element consists of a
<code>BatchHeader</code> and <code>dsig:Signature</code>.
</p>
<p>
The <code>BatchID</code> MUST be exactly the same as in the header of the
corresponding <code>BulkRegister</code> element.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="BulkStatusType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkStatus" type="xbulk:BulkStatusType"/&gt;
</pre>
<h4>
<a id="sec-BulkStatus-Example" name="sec-BulkStatus-Example"></a>2.4.2 Example
</h4>
<p>
An example status request:
</p>
<pre class="xml-example">
&lt;BulkStatus xmlns="http://www.w3.org/2002/03/xkms-xbulk"&gt;
&lt;SignedPart Id="id-0"&gt;
&lt;BatchHeader&gt;
&lt;BatchID&gt;batch-0&lt;/BatchID&gt;
&lt;BatchTime&gt;1999-05-31T13:20:00-05:00&lt;/BatchTime&gt;
&lt;NumberOfRequests&gt;2&lt;/NumberOfRequests&gt;
&lt;/BatchHeader&gt;
&lt;/SignedPart&gt;
&lt;dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
... URI="#id-0" ...
&lt;/dsig:Signature&gt;
&lt;/BulkStatus&gt;
</pre>
<h3>
<a id="sec-BulkStatusResult" name="sec-BulkStatusResult"></a>2.5 BulkStatusResult
</h3>
<p>
The <code>BulkStatus</code> is a very simple element that contains the
<code>BatchHeader</code> and <code>StatusResult</code> of a batch. The
<code>BatchHeader</code> MUST be exactly the same as the header in the
<code>BulkRegister</code> element.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="BulkStatusResultType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xbulk:StatusResult"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/&gt;
</pre>
<h4>
<a id="sec-StatusResult" name="sec-StatusResult"></a>2.5.2 The
<code>StatusResult</code> element
</h4>
<p>
The <code>StatusResult</code> element contains the following:
</p>
<ul>
<li>
The number of requests pending
</li>
<li>
The number that have completed successfully
</li>
<li>
The number that have failed
</li>
</ul>
<p>
One application might be to use a XML style sheet to present this information to
the customer over a web page.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;complexType name="StatusResultType"&gt;
&lt;sequence&gt;
&lt;element name="Pending" type="positiveInteger"/&gt;
&lt;element name="Successful" type="positiveInteger"/&gt;
&lt;element name="Failed" type="positiveInteger"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="StatusResult" type="xbulk:StatusResultType"/&gt;
</pre>
<h4>
<a id="sec-BulkStatusResult-Example"
name="sec-BulkStatusResult-Example"></a>2.5.3 Example
</h4>
<p>
A sample response to the example status request:
</p>
<pre class="xml-example">
&lt;BulkStatusResult xmlns="http://www.w3.org/2002/03/xkms-xbulk"&gt;
&lt;SignedPart Id="id-0"&gt;
&lt;BatchHeader&gt;
&lt;BatchID&gt;batch-0&lt;/BatchID&gt;
&lt;BatchTime&gt;1999-05-31T13:20:00-05:00&lt;/BatchTime&gt;
&lt;NumberOfRequests&gt;2&lt;/NumberOfRequests&gt;
&lt;/BatchHeader&gt;
&lt;StatusResult&gt;
&lt;Pending&gt;0&lt;/BatchID&gt;
&lt;Successful&gt;2&lt;/BatchTime&gt;
&lt;Failed&gt;0&lt;/NumberOfRequests&gt;
&lt;/StatusResult&gt;
&lt;/SignedPart&gt;
&lt;dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"&gt;
... URI="#id-0" ...
&lt;/dsig:Signature&gt;
&lt;/BulkStatusResult&gt;
</pre>
<h3>
<a id="sec-6" name="sec-6"></a>2.6 New children of <code>dsig:KeyInfo</code>
</h3>
<p>
The following new children of <code>dsig:KeyInfo</code> are defined, for
integration with legacy systems:
</p>
<h4>
<a id="sec-PKCS1" name="sec-PKCS1"></a>2.6.1 The <code>PKCS1</code> element
</h4>
<p>
The <code>PKCS1</code> element contains a DER-encoded [PKCS1] public key.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;element name="PKCS1" type="binary"/&gt;
</pre>
<h4>
<a id="sec-PKCS10" name="sec-PKCS10"></a>2.6.2 The <code>PKCS10</code> element
</h4>
<p>
The <code>PKCS10</code> element contains a DER-encoded [PKCS10] public key.
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;element name="PKCS10" type="binary"/&gt;
</pre>
<h2>
<a id="sec-Schema" name="sec-Schema"></a>3. Schema Definition
</h2>
<p>
The complete schema definition is as follows:
</p>
<pre class="xml-dtd">
Schema Definition:
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;schema
targetNamespace="http://www.w3.org/2002/03/xkms-xbulk"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xkms="http://www.w3.org/2002/03/xkms"
xmlns:xbulk="http://www.w3.org/2002/03/xkms-xbulk"
xmlns="http://www.w3.org/2000/10/XMLSchema"&gt;
&lt;import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/&gt;
&lt;import namespace="http://www.w3.org/2002/03/xkms" schemaLocation="xkms-20010330.xsd"/&gt;
&lt;annotation&gt;
&lt;documentation xml:lang="en"&gt;
XML Schema for X-BULK version 1.1 draft 5
&lt;/documentation&gt;
&lt;/annotation&gt;
&lt;!-- General Stuff --&gt;
&lt;complexType name="BatchHeaderType"&gt;
&lt;choice minOccurs="0" maxOccurs="unbounded"&gt;
&lt;sequence&gt;
&lt;element name="BatchID" type="string"/&gt;
&lt;element name="BatchTime" type="dateTime"/&gt;
&lt;element name="NumberOfRequests" type="positiveInteger"/&gt;
&lt;element ref="xbulk:ProcessInfo" minOccurs="0"/&gt;
&lt;/sequence&gt;
&lt;/choice&gt;
&lt;/complexType&gt;
&lt;element name="BatchHeader" type="xbulk:BatchHeaderType"/&gt;
&lt;complexType name="ProcessInfoType"&gt;
&lt;sequence minOccurs="1" maxOccurs="unbounded"&gt;
&lt;any namespace="##other"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="ProcessInfo" type="xbulk:ProcessInfoType"/&gt;
&lt;!-- copied from XKMS, since not typed there --&gt;
&lt;element name="KeyID" type="uriReference"/&gt;
&lt;element name="Respond"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element name="string" type="string" minOccurs="0" maxOccurs="unbounded"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;!-- Register Stuff --&gt;
&lt;complexType name="BulkRegisterType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xkms:Respond" minOccurs="0"/&gt;
&lt;element ref="xbulk:Requests"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkRegister" type="xbulk:BulkRegisterType"/&gt;
&lt;complexType name="RequestsType"&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:Request" maxOccurs="unbounded"/&gt;
&lt;/sequence&gt;
&lt;attribute name="number" use="required"/&gt;
&lt;/complexType&gt;
&lt;element name="Requests" type="xbulk:RequestsType"/&gt;
&lt;complexType name="RequestType"&gt;
&lt;sequence&gt;
&lt;element ref="xkms:KeyID"/&gt;
&lt;element ref="dsig:KeyInfo"/&gt;
&lt;element ref="xkms:Respond" minOccurs="0"/&gt;
&lt;element ref="xbulk:ProcessInfo" minOccurs="0"/&gt;
&lt;element ref="xbulk:ClientInfo" minOccurs="0"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="Request" type="xbulk:RequestType"/&gt;
&lt;complexType name="ClientInfoType"&gt;
&lt;sequence maxOccurs="unbounded"&gt;
&lt;any namespace="##other"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="ClientInfo" type="xbulk:ClientInfoType"/&gt;
&lt;!-- Result Specific Stuff --&gt;
&lt;complexType name="BulkRegisterResultType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xbulk:RegisterResults"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkRegisterResult" type="xbulk:BulkRegisterResultType"/&gt;
&lt;complexType name="RegisterResultsType"&gt;
&lt;sequence&gt;
&lt;element ref="xkms:RegisterResult" maxOccurs="unbounded"/&gt;
&lt;/sequence&gt;
&lt;attribute name="number" use="required"/&gt;
&lt;/complexType&gt;
&lt;element name="RegisterResults" type="xbulk:RegisterResultsType"/&gt;
&lt;!-- Status Specific Stuff --&gt;
&lt;complexType name="BulkStatusType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkStatus" type="xbulk:BulkStatusType"/&gt;
&lt;complexType name="BulkStatusResultType"&gt;
&lt;sequence&gt;
&lt;element name="SignedPart"&gt;
&lt;complexType&gt;
&lt;sequence&gt;
&lt;element ref="xbulk:BatchHeader"/&gt;
&lt;element ref="xbulk:StatusResult"/&gt;
&lt;/sequence&gt;
&lt;attribute name="Id" type="ID" use="required"/&gt;
&lt;/complexType&gt;
&lt;/element&gt;
&lt;element ref="dsig:Signature"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="BulkStatusResult" type="xbulk:BulkStatusResultType"/&gt;
&lt;complexType name="StatusResultType"&gt;
&lt;sequence&gt;
&lt;element name="Pending" type="positiveInteger"/&gt;
&lt;element name="Successful" type="positiveInteger"/&gt;
&lt;element name="Failed" type="positiveInteger"/&gt;
&lt;/sequence&gt;
&lt;/complexType&gt;
&lt;element name="StatusResult" type="xbulk:StatusResultType"/&gt;
&lt;!-- new types of dsig:KeyInfo --&gt;
&lt;element name="PKCS1" type="binary"/&gt;
&lt;element name="PKCS10" type="binary"/&gt;
&lt;/schema&gt;
</pre>
<h2>
<a id="sec-WSDL" name="sec-WSDL"></a>4. WSDL
</h2>
<p>
The WSDL is as follows:
</p>
<pre class="xml-dtd">
WSDL Definition:
<em>&lt;!-- to follow from a more stable schema --&gt;</em>
</pre>
<h2>
<a id="sec-References" name="sec-References"></a>5. References
</h2>
<dl>
<dt>
<a id="ref-Keywords" name="ref-Keywords">Keywords</a>
</dt>
<dd>
<a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>. <em>Key words for
use in RFCs to Indicate Requirement Levels</em>. Best Current Practice. S.
Bradner. March 1997.
</dd>
<dd>
<a
href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
</dd>
<dt>
<a id="ref-PKCS1" name="ref-PKCS1">PKCS1</a>
</dt>
<dd>
<a href="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/">PKCS #1</a>. <em>RSA
Cryptography Specifications Version 2.0</em>. B. Kaliski and J. Staddon.
September 1998.
</dd>
<dd>
<a
href="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/">http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/</a>
</dd>
<dd>
Also <a href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a>.
</dd>
<dt>
<a id="ref-PKCS10" name="ref-PKCS10">PKCS10</a>
</dt>
<dd>
<a href="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/">PKCS #10</a>.
<em>Certification Request Syntax Standard Version 1.7</em>. RSA Laboratories.
26 May 2000.
</dd>
<dd>
<a
href="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/">http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/</a>
</dd>
<dt>
<a id="ref-XMLDSIG" name="ref-XMLDSIG">XMLDSIG</a>
</dt>
<dd>
<a href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">XML-Signature
Syntax and Processing</a>. IETF Draft/W3C Proposed Recommendation. D. Eastlake,
J. Reagle, and D. Solo. 31 August 2001.
</dd>
<dd>
<a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/</a>
</dd>
<dt>
<a id="ref-XKMS" name="ref-XKMS">XKMS</a>
</dt>
<dd>
<a href="http://www.w3.org/TR/2002/WD-xkms2-20020318/">XML Key Management
Specification (XKMS)</a>. W3C Working Draft. P. Hallam-Baker. March 2002.
</dd>
<dd>
<a
href="http://www.w3.org/TR/2002/WD-xkms2-20020318/">http://www.w3.org/TR/2002/WD-xkms2-20020318/</a>
</dd>
<dt>
<a id="ref-XML-Names" name="ref-XML-Names">XML-Names</a>
</dt>
<dd>
<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in
XML</a>. W3C Recommendation. T. Bray, D. Hollander, and A. Layman. January
1999.
</dd>
<dd>
<a
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a>
</dd>
<dt>
<a id="ref-XML-Schema" name="ref-XML-Schema">XML-Schema</a>
</dt>
<dd>
<a href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/">XML Schema Part 1:
Structures</a>. W3C Working Draft. H. S. Thompson, D. Beech, M. Maloney and N.
Mendelsohn. 22 September 2000.
</dd>
<dd>
<a
href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/">http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/</a>,
latest draft at <a
href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a>
</dd>
<dd>
<a href="http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/">XML Schema Part 2:
Datatypes</a>. W3C Working Draft. P. V. Biron and A. Malhotra. 22 September
2000.
</dd>
<dd>
<a
href="http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/">http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/</a>,
latest draft at <a
href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>
</dd>
<dt>
<a id="ref-WSDL" name="ref-WSDL">WSDL</a>
</dt>
<dd>
Web Services Description Language. E. Christensen, F. Curbera, G. Meredith, S.
Weerawarana, <em>Web Services Description Language 1.1 (WSDL) 1.0</em>. W3C
Note. 15 March 2001, <a
href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">http://www.w3.org/TR/2001/NOTE-wsdl-20010315</a>
</dd>
</dl>
<!-- =============================================================================== -->
<h2>
<a id="sec-Acknowledgements" name="sec-Acknowledgements"></a>6. Acknowledgements
(Informative)
</h2>
<p>
The following people provided valuable feedback that improved the quality of this
specification:
</p>
<ul>
<li>
Patrick George, Gemplus
</li>
<li>
Pierre Heuze, Cardbase
</li>
<li>
Jean-Claude Perrin, Schlumberger
</li>
<li>
Fran&ccedil;ois Rajchenbach, Oberthur Card Systems
</li>
<li>
James Webster, Cards etc
</li>
</ul>
</body>
</html>