W3C

XML Key Management Specification (XKMS 2.0)
Part II: Protocol Bindings

W3C Editors Copy 17th October2002

This version:
http://www.w3c.org/2001/XKMS/Drafts/XKMS20021017/xkms-part-2.html
Latest version:
http://www.w3c.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html
Previous version:
None
Editor:
Phillip Hallam-Baker VeriSign
Contributors:
See the WG participants list.

Abstract

[2]This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature [XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption.¬  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).

Status of this document

[3]This is an editors copy and has no official status whatsoever.

[4] This is the third draft of the "XML Key Management Specification (XKMS)" specification from the XML Key Management Working Group (Activity Statement).

[5] This version attempts to capture the consensus resulting from the December 9th 2001 face-to-face meeting and subsequent discussion on the list. However, it does contain points which are still under discussion or not well specified. The Working Group will try to use a new namespace 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.

[6] 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." A list of current W3C working drafts can be found at http://www.w3.org/TR/.

[7]Please send comments to the editor (<pbaker@verisign.com>) and cc: the working group mailing list www-xkms@w3c.org (archive)

[8]Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.


Table Of Contents

XML Key Management Specification (XKMS 2.0) Part II: Protocol Bindings

W3C Editors Copy 17th October2002

Abstract

Status of this document

Table Of Contents

1 Introduction

1.1 Editorial and Conformance Conventions

1.2 Definition of Terms

1.3 Structure of this document

2 Security Requirements

2.1 Confidentiality

2.2 Request Authentication

2.3 Response Authentication

2.4 Persistent Authentication

2.5 Message Correlation (Response Replay and Request Substitution)

2.6 Request Replay

2.7 Denial of Service

2.8 Security Requirements Summary

3 SOAP Binding [TBS #54, 73]

4 Abstract Protocol

4.1 All Messages

4.2 Synchronous Request / Response

4.3 Asynchronous Processing

4.4 Two phase Request / Response

4.5 Two Phase Protocol with Asynchronous Processing

5 Security Bindings

5.1 Payload Authentication Binding

5.2 Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding

6 Acknowledgments

Appendix A References

1 Introduction

1.1 Editorial and Conformance Conventions

[9]This specification uses XML Schemas [XML-schema] to describe the content model.

[10]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 [KEYWORDS]:

[11]"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)"

[12]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 [XML-NS] is described as "REQUIRED."

1.2 Definition of Terms

[13]The following terms are used within this document with the particular meaning indicated below:

[14] Service
¬ ¬ ¬ 
An application that provides computational or informational resources on request. A service may be provided by several physical servers operating as a unit.

[15] Web service
¬ ¬ ¬ 
A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions

[16] Client
¬ ¬ ¬ 
An application that makes requests of a service.¬  The concept of 'client' is relative to a service request; an application may have the role of client for some requests and service for others.

1.3 Structure of this document

[17]The remainder of this document describes the XML Key Information Service Specification and XML Key Registration Service Specification.

Section 2: Security Requirements
The security requirements of the XKMS protocol are specified.
Section 3: Payload Security Protocol
The security properties supported by the XKMS payload security features are described.
Section 4: Security Bindings
The use of XKMS payload security features is described in the context of specific security protocols.
Section 5: Security Considerations
Security considerations relevant to the implementation and deployment of the specification are discussed.

2 Security Requirements

[18]Security enhancements MAY be required to control the following risks:

[19]The security enhancements required varies according to the application. In the case of a free or un-metered service the service may not require authentication of the request. A responder that requires an authenticated request must know in that circumstance that the request corresponds to the specified response.

2.1 Confidentiality

[20]Message confidentiality protects protocol messages from disclosure to third parties. Confidentiality MAY be a requirement for an XKMS service. Deployments SHOULD consider the extent to which the content of XKMS messages reveal sensitive information. A confidentiality requirement MAY exist even if a service only provides information from public sources as the contents of a request might disclose information about the client.

[21]The use of transport or payload confidentiality protection is NOT a substitute for the encryption of private keys specified in the XKRSS Registration and Recovery services. A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher.

[22]An XKMS service SHOULD support Confidentiality by means of encryption.

[23]The means by which the client determines that the encryption key of the service is trustworthy is outside the scope of this specification. Possible mechanisms include:

[24]An XKMS service MAY determine the trustworthiness of an encryption key by reference to another XKMS service provided that the chain of references is eventually grounded by a mechanism that establishes direct trust between the client and the service.

2.2 Request Authentication

[25]Request Message Authentication MAY be required. An XKMS Service MAY require request authentication in deployments where the XKMS service is restricted to a specific audience, possibly as a paid service. An XKMS Service MAY require request authentication in contexts where different levels of service are supported according to the identity of the requestor.

[26]In addition various forms of Authentication MAY be required in the XKRSS Registration protocol to confirm the credentials of the party initiating the request and their possession of the private key component of the key pair(s) being registered.

[27]An XKMS service SHOULD support Message Request Authentication.

2.3 Response Authentication

[28]Message Response Authentication MAY be required. Message Response Authentication is required in any deployment of a Validate service. A Locate service that provides only data that is self-authenticating such as X.509 or PGP certificates does not require Message Response Authentication.

[29]Note that Message Response Authentication is considered separately from Response Replay Protection.

[30]An XKMS service SHOULD support Request Authentication.

2.4 Persistent Authentication

[31]In some circumstances requests or responses or to both may require persistent authentication. That is a message sent by A and authenticated by B may be subject to forwarding and authentication by C. In addition some applications may require further measures to ensure that messages meet certain legal standards to prevent repudiation.

[32]An XKMS service MAY support Persistent Authentication by means of a digital signature on the message.

2.5 Message Correlation (Response Replay and Request Substitution)

[33]An XKMS service MUST support a means of ensuring correct message correlation. That is the requestor must be assured that the response returned was made in response to the intended request sent to the service and not a modification of that request (Request Substitution attack) or a response to an earlier request (response replay attack).

[34]An XKMS service Must provide protection against a Request Replay or Request Substitution attack.

[35]XKMS services may employ the following mechanisms to protect against a Request Replay or Request Substitution attack

[36]¬ 

[37]In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. For correspondence verification to be possible authentication of the response is required. In the TLS binding the correspondence between the request and response is provided by the transport layer. For message layer security mechanisms such as payload security the mechanism required depends on whether or not the request is authenticated as follows:

Authenticated Request
If the request and the response are authenticated the correspondence of the request and response may be determined by verifying the value of RequestID in the response.
Non-authenticated Request
If the original request was not authenticated the response can still ensure a strong binding of the response to the original request by including a message digest function of the request in the response.

[38][TBS¬  #25 We do not at present describe a mechanism for this. I suggest that the client be required to authenticate the request with a payload or WS-Security hash function. This would then be returned in the response in some manner, possibly as a signed attribute, possibly as an additional Signature blob in the request.]

2.6 Request Replay

[39]An XKMS service may require protection against a Request replay attack. In circumstances where no accounting or other auditing is used to keep track of requests made, protection against a request replay attack may not be required.

[40]An XKMS service MAY provide protection against a Request Replay.

2.7 Denial of Service

[41]An XKMS service may require protection against a Denial of Service attack by means of protocol measures. Such measures may not be required in circumstances where an XKMS service is protected against Denial of Service by other means such as the service is managed on an isolated, tightly controlled network and does not provide service outside that network.

[42]An XKMS service SHOULD support protection against a Denial of Service attack.

2.8 Security Requirements Summary

[43]The following table summarizes the possible security requirements that an XKMS service deployment may be subject to:

Security Issue Requirement Comments
Confidentiality Some The information provided by an XKMS service may be confidential, the fact that a party has requested particular information from an XKMS service may allow confidential information to be deduced. Many XKMS applications do not require confidentiality however.
Request Authentication Some A service only needs to authenticate a request for information if either the information is confidential or some form of charge is to be made for use of the service.
Response Authentication Most An XKMS service that provides only a Location service for self authenticating key information such as Digital Certificates does not require authentication.
Persistent Authentication Some Although some XKMS applications have a specific requirement to support Non-Repudiation, the ability to repudiate requests and responses is acceptable in many applications.
Message Correspondence All The RequestID correspondence mechanism can only be used if the Request Authentication mechanism can be relied upon. Otherwise the Digest Mechanism should be used.
Request Replay Some Request replay attacks are likely to only be a concern if the service charges on a per request basis or as a type of Denial of Service attack.
Denial of Service Most Any service made available on a public network is likely to be subject to a Denial of Service attack. The risk of a Denial of Service attack is generally considered to be reduced on closed networks such as internal enterprise networks.

[44]Where the security requirements of the XKRSS protocol are stronger than those of XKISS they are addressed by the XKRSS protocol directly rather than relying upon the message security binding:

Security Issue Requirement Comments
Confidentiality of Private Key If Server Generated Key pairs used If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported.
Registration Request Authentication Some XKMS Registration services SHOULD support the authentication of registration requests for initial registration of a key binding. Registration requests for secondary registration of previously issued credentials (i.e. a signed key binding or a digital certificate) MAY be permitted without authentication.
Registration Proof Of Possession Some XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys.
Authentication by Revocation Code Some The XKMS Revocation code is self authenticating.

3 SOAP Binding [TBS #54, 73]

4 Abstract Protocol

[45]The XKMS protocol consists of pairs of requests and responses. The XKMS protocol binding allows for the case in which an additional request/response round trip is required to support cases such as pending responses and 2 phase requests for replay attack protection.

[46]Each XKMS response message contains a MajorResult code that determines whether the response is final or further processing is required. The protocol is specified in the CSP formalism [CSP] as follows:

Final = { Success, VersionMismatch, Sender, Receiver }
¬ 
Request ‚†’ Result.Final
|
Request ‚†’ Result.Pending‚†’PendingNotification‚†’Request‚†’Result.Final
|
Request ‚†’ Result.Represent‚†’Request‚†’Result.Final

[47]The following sections summarize the message processing steps taken by both parties in each of the message

4.1 All Messages

[48]The following processing steps are taken with respect to all messages regardless of whether they are a request or a response:

Generation
ID is set to a randomly generated unique value
Service is set to the value of the URI to which the XKMS request is directed
Authentication Signature is generated (if required).
Processing
The value of Service is verified
The Authentication Signature value is verified (if required)

4.1.1 Example

<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw==" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.2 Synchronous Request / Response

Requestor generation of the Request Message
Nonce and OriginalRequestID¬  are not present
RespondWith values xkms:Represent and/or xkms:Asynchronous MAY be specified
Service processing of the Request Message
Verify that request meets service authorization policy
Process request to completion
Service generation of the Response Message
RequestID is set to the value of Id in the request message
Nonce is not present
MajorResult is set to a Final result value.
Requestor processing of the Response Message
The value of RequestID is verified

4.2.1 Example

4.2.1.1 Request

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Id43fc15f6e942666a8adc7f142684fa7" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

4.2.1.2 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I2dbaacaa120b8b6aed62aadf492654d6" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#Id43fc15f6e942666a8adc7f142684fa7" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.3 Asynchronous Processing

[49]Asynchronous processing consists of a sequence of two request/response pairs, an initial request which specifies the request values and a pending request which obtains the result of the operation.

4.3.1 Initial Request

[50]The initial request message is processed as follows:

Requestor generation of the Initial Request Message
Nonce and OriginalRequestID¬  are not present
RespondWith value xkms:Asynchronous MUST be specified
Service processing of the Initial Request Message
Schedule request for asynchronous processing
Service generation of the Initial Response Message
RequestID is set to the value Id in the initial request message
Nonce is not present
MajorResult is set to Asynchronous
Requestor processing of the Initial Response Message
Register request as pending completion, wait for notification.

4.3.2 Pending Request

[51]On notification the client requests the return of the result values by issuing a PendingRequest message as follows:

Requestor generation of the Pending Request Message
The request element is PendingRequest
OriginalRequestID is set to the value of Id in the initial request message
ResponseID is set to value of Id in the initial response message
Service processing of the Pending Request Message
Match pending request to pending response
Service generation of the Pending Response Message
RequestID is set to the value of Id in the Pending request message
Nonce is not present
ResponseID is set to a randomly generated unique value
Requestor processing of the Pending Response Message
If MajorResult¬  is set to a non-final value consider it to be xkms:failure

4.3.3 Example

4.3.3.1 Request

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Iadc9f357a190a6fa6ec41bbc1f487e9f" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>Pending</RespondWith>
  <QueryKeyBinding />
</LocateRequest>

4.3.3.2 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Id0b7ad7dc569e5a7da247c5d8dcb4d1e" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending" 
      RequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.3.3.3 Notification

<?xml version="1.0" encoding="utf-8"?>
<ResultAbstractType xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.3.3.4 Pending Request

<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I02dab31556512d021314587a87db2fc8" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      OriginalRequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.3.3.5 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Ia617e870ad6e86d84e7eb13ba012b25a" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.4 Two phase Request / Response

[52]An XKMS Service MAY require the use of a two phase Request /.Response protocol to provide protection against Request Replay attacks and/or denial of service attacks.

[53]In the first phase the requestor presents the request and the service responds the MajorResult value Represent and presents a nonce.

[54]In the second phase the requestor represents the original request together with the nonce.

[55]The service can protect against replay attacks by ensuring that it only responds to each nonce once. This may be achieved in a computationally efficient manner by appropriate construction of the nonce value. The actual construction of the nonce value is outside the scope of this specification and may be chosen as site specific circumstances dictate.

[56]For example the nonce may be constructed from the current time at the service, a unique serial number and a Message Authentication Code computer computed over the preceding items using a¬  secret key known only to the service:

[57] nonce = time + serial + M ( time + serial , k )

[58]The service may limit the time interval in which replay attacks are possible by rejecting nonce values that specify an unacceptable time value or an incorrect MAC value.

[59]The service may prevent replay attacks completely by tracking the serial numbers for which responses have already been given.

[60]The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Phase 1 Request Message
RespondWith value xkms:Represent MUST be specified
Service processing of the Phase 1 Request Message
Service decides to exercise option to require Two Phase Processing
Request is NOT processed
Service generation of the Phase 1 Response Message
RequestID is set to the value Id in the Phase 1 request message
Nonce value is set in accordance with service replay protection requirements
MajorResult is set to Represent
Requestor processing of the Phase 1 Response Message
Proceed to phase 2

[61]The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Phase 2 Request Message
OriginalRequestID¬  set to the value of Id in the Phase 1 request message
Nonce value is set to the value of Nonce in the Phase 1 response message
Service processing of the Phase 2 Request Message
Verify value of Nonce
Verify that request meets service authorization policy
Process request to completion
Service generation of the Phase 2 Response Message
RequestID is set to the value of Id in the Phase2 request message
Nonce is not present
MajorResult is set to a Final result value
Requestor processing of the Phase 2 Response Message
If MajorResult set to a non-final value consider to be failure

4.4.1 Example

[62]¬ 

4.4.1.1 Request 1

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I524847b1df23a4fec4ab0d6eee401aa9" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>Represent</RespondWith>
  <QueryKeyBinding />
</LocateRequest>

4.4.1.2 Response 1

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Ief7f690062e2d564f123e640f63e3c22" 
      Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg==" 
      ResultMajor="Represent" RequestId="#I524847b1df23a4fec4ab0d6eee401aa9" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.4.1.3 Request 2

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ic183b74a6d3ec0ab495f0d83774c16b7" 
      Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg==" 
      OriginalRequestId="#I524847b1df23a4fec4ab0d6eee401aa9" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

4.4.1.4 Response 2

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I2933751847d8fce2384e20010a1f62bb" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

4.5 Two Phase Protocol with Asynchronous Processing

[63]The Two Phase Protocol may be combined with Asynchronous Processing. In this case the operation will consist of three round trips as follows:

[64]Message processing is performed as described above with the following exceptions.

4.5.1 Compound Request [TBS]

5 Security Bindings

[65]This specification describes three principal security bindings each of which specifies two or more specific implementation profiles. Each implementation profile is assigned a unique URI to facilitate negotiation of a specific security profile using some mechanism to be described as a part of the wider Web Services framework.

¬  Payload Security Transaction Layer Security
Dependencies Authentication defined by XKMS specification, client does not need to implement a comprehensive framework. Authentication mechanism defined by TLS which clients must implement
Use of XML Signature Uses XML Signature in Enveloped Mode requiring slightly more complex processing. Not required
Support for Routing Specification describes bi-lateral authentication only, multi-hop message routing and multi-party transactions are not supported. None
Support for Confidentiality None, although applications may employ TLS to establish a secure channel Supported
Non-Repudiation Supported Requires additional payload security
Unspecified Party Authentication Supported Requires additional payload security
Client Authentication Supported Supported through certificate client authentication or through use of payload security.

5.1 Payload Authentication Binding

[66][TBS #87 Exclusive cannonicalization]

Identifier: http://www.w3.org/2002/03/xkms#payload-I
No mechanism is used to authenticate the client
Identifier: http://www.w3.org/2002/03/xkms#payload-II
The client is authenticated using payload security
Security Consideration Variant Support XKMS element
Client Authentication Mechanism I None ¬ 
¬  II Payload Request/Signature
Service Authentication Mechanism ¬  Payload Response/Signature
Request/Response Correspondence I Payload Request/MessageDigest
¬  II Payload Message/RequestID
Replay Attack Protection ¬  Payload Message/Nonce
Denial Of Service Protection ¬  Payload Request/RespondWith=Represent
Non Repudiation ¬  Payload Message/Signature with digital signature

[67]The following payload security features are employed.

XKMS element Required
Message/Service Required
Request/Signature Required in profile II
Response/Signature Required
Message/RequestID Required
Message/ResponseID Required
Message/Nonce Optional, may be used to protect against Denial of Service
Request/RespondWith=Represent Optional, may be used to protect against Denial of Service
Request/MessageDigest Required in profile I, Optional in profile II

5.2 Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding

[68][TBS #77 cipher suites]

[69]The SSL/TLS binding has three variants specified by the following identifiers:

Identifier: http://www.w3.org/2002/03/xkms#tls-I
No mechanism is used to authenticate the client
Identifier: http://www.w3.org/2002/03/xkms#tls-II
TLS certificate based client authentication is used to authenticate the client
Identifier: http://www.w3.org/2002/03/xkms#tls-III
Payload security is used for client authentication
Security Consideration Variant Support XKMS element
Client Authentication Mechanism I None ¬ 
¬  II TLS Certificate based client authentication
¬  II Payload Request/Signature
Service Authentication Mechanism ¬  TLS ¬ 
Request/Response Correspondence ¬  TLS ¬ 
Replay Attack Protection ¬  TLS ¬ 
Denial Of Service Protection ¬  None The TLS service is subject to a denial of service attack [Check this]
Non Repudiation ¬  Payload Message/Signature with digital signature [if required]

[70]The following payload security features are employed.

XKMS element Required
Message/Service Required but not dependent
Request/Signature Optional, may be used to support non-repudiation
Response/Signature Optional, may be used to support non-repudiation
Message/RequestID Required but not dependent
Message/ResponseID Required but not dependent
Message/Nonce Unnecessary
Request/RespondWith=Represent Unnecessary
Request/MessageHash Unnecessary

6 Acknowledgments

Appendix A References

[71] [SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/SOAP/

[72] [RFC-2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0. ¬ IETF RFC 2246 January 1999.

[73] [WSSL] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.0 September 25, 2000, http://msdn.microsoft.com/xml/general/wsdl.asp

[74] [XTASS] P. Hallam-Baker, XML Trust Assertion Service Specification, To Be Published, January 2001

[75] [XML-SIG]¬  D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, World Wide Web Consortium. http://www.w3.org/TR/xmldsig-core/

[76] [XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.

[77] [XML-Enc] XML Encryption Specification, In development.

[78] [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures, W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/, latest draft at http://www.w3.org/TR/xmlschema-1/

[79] [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes; W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/, latest draft at http://www.w3.org/TR/xmlschema-2/

[80] [WS-Security] ¬ ¬ ¬  TBS