Update 2004-04-07: On April 6, 2004 the Co-Chairs of the OASIS Web Services Security (WSS) Technical Committee announced that TC voted unanimously to request that the OASIS WSS TC's Web Services Security specification, as successfully balloted to the OASIS membership, be advanced to OASIS Standard status. The Web Services Security specification set includes: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), Web Services Security UsernameToken Profile 1.0, Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas.

Update 2004-03-15: The five documents discussed below were presented to the OASIS membership for approval as an OASIS Standard. The title of the core document was changed slightly in the 2004-03-15 version as balloted: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).

A set of five documents has been approved as Committee Draft specifications by the OASIS Web Services Security (WSS) Technical Committee. The WSS Committee Draft documents have also been approved for submission to OASIS for consideration as OASIS standards. The CDs include Web Services Security: SOAP Message Security 1.0, Web Services Security UsernameToken Profile 1.0, and Web Services Security X.509 Certificate Token Profile. They are accompanied by two XML Schemas, documented in the main WSS specification as Appendix A "Utility Elements and Attributes" and Appendix B "SecurityTokenReference Model."

The WSS 1.0 specification "describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The document also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e., support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, the WSS specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message."

The Web Services Security specification "describes a set of extensions to SOAP that allow message level security to be added to Web Services message exchanges. The two profile documents describe mechanisms for using [the core SOAP Message Security 1.0 specification] to carry Username/Password and X.509 certificate level detail within these messages. The two schema documents provide the formal XML definition of the extensions to the SOAP schema that [the core WSS specification] introduces... This work builds upon work done in W3C in the areas of XML Digital Signature (DSIG) and XML Digital Encryption. The specification describes how to include security content (signatures and cipher text etc.) within a SOAP message header and body. As such, this specification both utilizes and complements the SOAP work done by the XMLP WG at W3C. Further, the WSS specification and its profiles describe how to utilize X.509 certificates within SOAP messages. X.509 (and X.500) are of course well known public specifications. Further profiles (yet to be finished) will describe how [the WSS core specification] can be used in conjunction with Kerberos, SAML, XrML and other security technologies that have been or are being developed at OASIS and elsewhere. Links to these related technologies are included in the specifications that we are delivering for easy cross reference by the reader." [adapted from the Submission Notes, clarifying that references are to current WSS core == 'SOAP Message Security 1.0', not to April 2002 'WS-Security' spec as submitted]

The OASIS Web Services Security TC (WSS) was chartered [re-chartered] to "continue work on the Web Services security foundations as described in the WS-Security specification [Web Services Security (WS-Security), Version 1.0, April 5, 2002], which was written within the context of the Web Services Security Roadmap as published in April 2002 [Security in a Web Services World: A Proposed Architecture and Roadmap]. The work of the WSS TC will form the necessary technical foundation for higher-level security services which are to be defined in other specifications..." In its revised 2002-10 Charter, the WSS TC described an initial set of target deliverables including:

1. the 'core' specification (with final name then TBD) which has now been published under the title Web Services Security: SOAP Message Security 1.0 an OASIS WSS TC approved Committee Draft, 2004-02-17
2. an X.509 profile, also published 2004-02-17, as Web Services Security X.509 Certificate Token Profile as an approved WSS TC Committee Draft
3. a SAML profile, released as WSS TC Working Draft version 09, Web Services Security: SAML Token Profile on January 27, 2004
4. a Kerberos profile, published as a WSS TC Working Draft version 03, Web Services Security Kerberos Token Profile, on January 30, 2003
5. an XrML profile, published in draft as Web Services Security XrML2-Based Rights Expression Token Profile on January 08, 2004[public URL?]

Bibliographic Information

• Web Services Security: SOAP Message Security 1.0. Edited by Anthony Nadalin (IBM), Chris Kaler (Microsoft), Phillip Hallam-Baker (VeriSign), and Ronald Monzillo (Sun). Produced by members of the OASIS Web Services Security (WSS) technical committee. Monday, 19-January-2004. Document identifier: '{draft}-{WSS: SOAP Message Security }-{1.0}'. 56 pages. [sanitized version 2004-02-18]

  Web Services Security: SOAP Message Security 1.0 (WS-Security 2004). Monday, 15-March-2004. Document identifier: {WSS: SOAP Message Security }-{1.0} (Word) (PDF). Location: 'http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0'. 56 pages. This slightly revised version of the 'core' document was released on March 15, 2004 in connection with the ballot for approving the document as an OASIS Standard. The WSS TC changed the name on the title page of the specification to avoid confusion with the original contribution. The following clarification was added in the document Introduction: "This OASIS specification is the result of significant new work by the WSS Technical Committee and supersedes the input submissions, Web Service Security (WS-Security) Version 1.0 April 5, 2002 and Web Services Security Addendum Version 1.0 August 18, 2002." [source PDF]

  Document abstract: "This specification describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. This specification also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e., support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, this specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message."

• Web Services Security UsernameToken Profile 1.0. Edited by Anthony Nadalin (IBM), Phil Griffin (Individual Member), Chris Kaler (Microsoft), Phillip Hallam-Baker (VeriSign), and Ronald Monzillo (Sun). Produced by members of the OASIS Web Services Security (WSS) technical committee. Monday, 19-January-2004. Document identifier: '{WSS: SOAP Message Security }-{UsernameToken Profile }-{1.0}'. 14 pages. [sanitized version 2004-02-18, again 2004-03-15]

  "This document describes how to use the UsernameToken with the WSS: SOAP Message Security specification (WSS). More specifically, it describes how a web service consumer can supply a UsernameToken as a means of identifying the requestor by 'username', and optionally using a password (or shared secret, or password equivalent) to authenticate that identity to the web service producer."

• Web Services Security X.509 Certificate Token Profile. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). Produced by members of the OASIS Web Services Security (WSS) technical committee. Monday, 19-January-2004. Document identifier: '{WSS: SOAP Message Security }-{X509 Profile }-{1.0}'. 17 pages. [sanitized version 2004-02-18, again 2004-03-15]

  "This document describes how to use X.509 Certificates with the Web Services Security: SOAP Message Security specification. An X.509 certificate specifies a binding between a public key and a set of attributes that includes (at least) a subject name, issuer name, serial number and validity interval. This binding may be subject to subsequent revocation advertised by mechanisms that include issuance of CRLs, OCSP tokens or mechanisms that are outside the X.509 framework, such as XKMS. An X.509 certificate may be used to validate a public key that may be used to authenticate a WS-Security-enhanced message or to identify the public key with which a WS-Security-enhanced message has been encrypted.

• WSS XML Schema: wss-wssecurity-secext-1.0.xsd. Namespace: http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd, and namespace prefix: wsse. Appendix B "SecurityTokenReference Model" of Web Services Security: SOAP Message Security 1.0 "provides a non-normative overview of the usage and processing models for the <wsse:SecurityTokenReference> element. There are several motivations for introducing the <wsse:SecurityTokenReference> element: The XML Signature reference mechanisms are focused on 'key' references rather than general token references. The XML Signature reference mechanisms utilize a fairly closed schema which limits the extensibility that can be applied. There are additional types of general reference mechanisms that are needed, but are not covered by XML Signature. There are scenarios where a reference may occur outside of an XML Signature and the XML Signature schema is not appropriate or desired. The XML Signature references may include aspects (e.g., transforms) that may not apply to all references..."

• WSS XML Schema: wss-wssecurity-utility-1.0.xsd. Namespace: http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd, and namespace prefix: wsu. Appendix A "Utility Elements and Attributes" of Web Services Security: SOAP Message Security 1.0 "defines several elements, attributes, and attribute groups which can be re-used by other specifications. This appendix provides an overview of these utility components. It should be noted that the detailed descriptions are provided in the specification and this appendix will reference these sections as well as calling out other aspects not documented in the specification. Identification Attribute: There are many situations where elements within SOAP messages need to be referenced. For example, when signing a SOAP message, selected elements are included in the signature. XML Schema Part 2 provides several built-in data types that may be used for identifying and referencing elements, but their use requires that consumers of the SOAP message either have or are able to obtain the schemas where the identity or reference mechanisms are defined. In some circumstances, for example, intermediaries, this can be problematic and not desirable. Consequently a mechanism is required for identifying and referencing elements, based on the SOAP foundation, which does not rely upon complete schema knowledge of the context in which an element is used. This functionality can be integrated into SOAP processors so that elements can be identified and referred to without dynamic schema discovery and processing. This specification specifies a namespace-qualified global attribute for identifying an element which can be applied to any element that either allows arbitrary attributes or specifically allows this attribute... The specification [also] defines XML elements which may be used to express timestamp information such as creation and expiration. While defined in the context of message security, these elements can be re-used wherever these sorts of time statements need to be made. The elements in this specification are defined and illustrated using time references in terms of the dateTime type defined in XML Schema... The schema for the utility aspects of this specification also defines some general purpose schema elements...

Summary of Web Services Security: SOAP Message Security 1.0

"This specification proposes a standard set of SOAP extensions that can be used when building secure Web services to implement message content integrity and confidentiality. This specification refers to this set of extensions and modules as the 'Web Services Security: SOAP Message Security' or 'WSS: SOAP Message Security'. This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated profile documents.

This specification provides three main mechanisms: ability to send security tokens as part of a message, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. These mechanisms can be used independently (e.g., to pass a security token) or in a tightly coupled manner (e.g., signing and encrypting a message or part of a message and providing a security token or token path associated with the keys used for signing and encryption).

Goals and Requirements: The goal of this specification is to enable applications to conduct secure SOAP message exchanges. It is intended to provide a flexible set of mechanisms that can be used to construct a range of security protocols; in other words this specification intentionally does not describe explicit fixed security protocols. As with every security protocol, significant efforts must be applied to ensure that security protocols constructed using this specification are not vulnerable to any one of a wide range of attacks. The examples in this specification are meant to illustrate the syntax of these mechanisms and are not intended as examples of combining these mechanisms in secure ways. The focus of this specification is to describe a single-message security language that provides for message security that may assume an established session, security context and/or policy agreement. The requirements to support secure message exchange are [as follows:]

The Web services security language must support a wide variety of security models. The following list identifies the key driving requirements for this specification: (1) Multiple security token formats; (2) Multiple trust domains; (3) Multiple signature formats; (4) Multiple encryption technologies; (5) End-to-end message content security and not just transport-level security. The following topics are outside the scope of this document: [a] Establishing a security context or authentication mechanisms; [2] Key derivation; [3] Advertisement and exchange of security policy; [4] How trust is established or determined; [5] Non-repudiation...

Message Protection Mechanisms: When securing SOAP messages, various types of threats should be considered. This includes, but is not limited to: (1) the message could be modified or read by antagonists, or (2) an antagonist could send messages to a service that, while well-formed, lack appropriate security claims to warrant processing. To understand these threats this specification defines a message security model.

Message Security Model: This document specifies an abstract message security model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messages. Security tokens assert claims and can be used to assert the binding between authentication secrets or keys and security identities. An authority can vouch for or endorse the claims in a security token by using its key to sign or encrypt (it is recommended to use a keyed encryption) the security token thereby enabling the authentication of the claims in the token. An X.509 certificate, claiming the binding between one's identity and public key, is an example of a signed security token endorsed by the certificate authority. In the absence of endorsement by a third party, the recipient of a security token may choose to accept the claims made in the token based on its trust of the producer of the containing message. Signatures are used to verify message origin and integrity. Signatures are also used by message producers to demonstrate knowledge of the key, typically from a third party, used to confirm the claims in a security token and thus to bind their identity (and any other claims occurring in the security token) to the messages they create...

Message Protection: Protecting the message content from being disclosed (confidentiality) or modified without detection (integrity) are primary security concerns. This specification provides a means to protect a message by encrypting and/or digitally signing a body, a header, or any combination of them (or parts of them). Message integrity is provided by XML Signature in conjunction with security tokens to ensure that modifications to messages are detected. The integrity mechanisms are designed to support multiple signatures, potentially by multiple SOAP actors/roles, and to be extensible to support additional signature formats. Message confidentiality leverages XML Encryption in conjunction with security tokens to keep portions of a SOAP message confidential. The encryption mechanisms are designed to support additional encryption processes and operations by multiple SOAP actors/roles. This document defines syntax and semantics of signatures within a <wsse:Security> element. This document does not specify any signature appearing outside of a <wsse:Security> element..." [adapted from Introduction and Section 3]

Certification of Use

Statements from eight[+] TC member organizations have been received, certifying "that they are successfully using the specifications consistently with the OASIS IPR Policy", according to the Submission Notes:

• Argonne National Laboratory: Argonne National Laboratory, a participant in The Globus Alliance, has successfully implemented and used the Web Services Security Committee Drafts (specs and schemas); Argonne is an OASIS Contributor and has fulfilled the requirements of the IPR Policy. [Frank Siebenlist, The Globus Alliance - Argonne National Laboratory]
• BEA Systems: BEA Systems hereby certifies that we are successfully using the WSS Committee Draft Specifications consistently with the OASIS IPR Policy. [Hal Lockhart, BEA Systems]
• CommerceOne: Commerce One hereby certifies that Commerce One is successfully using WSS Committee Draft Specification consistently with the OASIS IPR Policy. Commerce One has implemented in its product, and has demonstrated the interoperability with other vendors in September 2003, during the second WSS Interop testing. [Symon Chang, Commerce One]
• IBM: IBM has successfully implemented and used the Web Services Security Committee Drafts (specs and schemas) dated Monday January 19, 2004 and was consistent with the OASIS IPR Policy. [Anthony Nadalin, IBM]
• Microsoft: Certification by at least three OASIS member organizations that they are successfully using the specification consistently with the OASIS IPR Policy [Vijay Gajjala, Microsoft]
• OpenNetwork: OpenNetwork Technologies hereby certifies that we are successfully using the WSS Committee Draft Specifications consistently with the OASIS IPR Policy. [Steve Anderson, OpenNetwork]
• Reactivity: Reactivity has successfully implemented and used the Web Services Security Committee Draft Specifications in a manner consistent with the OASIS IPR Policy. [Eric Gravengaard,Reactivity]
• Systinet: Systinet attests that it successfully uses WSS-SOAPMessageSecurity specification. We are using the core functionality and WSS-UserName and WSS-X509 profiles in our implementation. Systinet is aware of the IPR statements concerning implementation of OASIS WSS specification as stated in the IPR policy [Jan Alexander, Systinet]