The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: April 08, 2004.
News: Cover StoriesPrevious News ItemNext News Item

OASIS Web Services Security Specification Approved as an OASIS Standard.

On April 6, 2004 the co-chairs of the OASIS Web Services Security (WSS) Technical Committee announced the TC's unanimous decision to request that the WSS TC's Web Services Security specification, as successfully balloted to the OASIS membership, be advanced to OASIS Standard status. An official OASIS announcement was issued on April 19, 2004.

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. The WSS TC is also creating additional token profiles for use with the core SOAP Message Security 1.0 specification, including the Web Services Security: SAML Token Profile, now in an advanced state of preparation.

The SOAP Message Security 1.0 core 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 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, so as to 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 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 26 of the tokens that are included with a message."

The UsernameToken Profile describes how to use the UsernameToken with the core WSS specification. 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) [how] to authenticate that identity to the web service producer."

The X.509 Certificate Token Profile document describes "how to use X.509 Certificates with the SOAP Message Security 1.0 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."

Web Services Security: Bibliographic Information

  • Web Services Security: SOAP Message Security 1.0 (WS-Security 2004). Monday, 15-March-2004. 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. 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]

  • 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, 15-March-2004. Document identifier: '{WSS: SOAP Message Security }-{UsernameToken Profile }-{1.0}'. 14 pages. [source PDF]

  • 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, 15-March-2004. Document identifier: '{WSS: SOAP Message Security }-{X509 Profile }-{1.0}'. 17 pages. [source PDF]

  • 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..." [source .XSD]

  • 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..." [source .XSD]

  • See also: Web Services Security: SAML Token Profile. WSS TC Working Draft. Version 10. April 06, 2004. Produced by members of the OASIS Web Services Security (WSS) Technical Committee. 35 pages. This document describes how to use Security Assertion Markup Language (SAML) Version 1.1 assertions with the core Web Services Security: SOAP Message Security 1.0 specification. The profile describes: (1) how SAML assertions are carried in and referenced from <wsse:security> headers; (2) how SAML assertions are used with XML Signature to bind the statements of the assertions (i.e., the claims) to a SOAP message. See also the following reference.

  • See also: Web Services Security: SAML Interop 1 Scenarios. WSS Technical Committee Working Draft. Version 04. January 29, 2004. 41 pages. Document identifier: 'wss-saml-interop1-draft-04.doc'. OASIS WSS TC. Edited by Rich Levinson (Netegrity) and Hal Lockhart (BEA Systems). With contributions from Prateek Mishra (Netegrity) and Ron Monzillo (Sun Microsystems). ['This document documents the four scenarios to be used for the WSS-SAML Interoperability Event.'] "This document describes message exchanges to be tested during the SAML interoperability event of the WSS TC. All use the Request/Response Message Exchange Pattern (MEP) with no intermediaries. All invoke the same simple application. These scenarios are intended to test the interoperability of different implementations performing common operations and to test the soundness of the various specifications and clarity and mutual understanding of their meaning and proper application." See preceding reference: a WSS SAML Profile is being prepared and a SAML "virtual interop" event is to be held on May 17, 2004. Contact: Ronald Monzillo; SAML general references. [source .DOC]

About the OASIS Web Services Security TC (WSS)

The OASIS Web Services Security TC (WSS) was chartered [re-chartered September 2002] 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-09 Charter, the WSS TC described an initial set of target deliverables. These deliverables included:

  1. A 'Core' specification (with final name then TBD) which has now been published under the title Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) as an OASIS Standard
  2. A SAML profile, released as WSS TC Working Draft version 10, Web Services Security: SAML Token Profile on April 06, 2004
  3. An X.509 profile, Web Services Security X.509 Certificate Token Profile now released as an OASIS Standard
  4. A Kerberos profile, published as a WSS TC Working Draft version 05, Web Services Security Kerberos Token Profile 1.0, on April 15, 2004
  5. An XrML profile, published in draft as Web Services Security XrML2-Based Rights Expression Token Profile on January 08, 2004 [public URL?]

OASIS WSS TC Scope: "The scope of the Web Services Security Technical Committee is the support of security mechanisms in the following areas: (1) Using XML signature to provide SOAP message integrity for Web services; (2) Using XML encryption to provide SOAP message confidentiality for Web services; (3) Attaching and/or referencing security tokens in headers of SOAP messages; (4) Carrying security information for potentially multiple, designated actors; (5) Associating signatures with security tokens. Each of the security mechanisms will use implementation and language neutral XML formats defined in XML Schema." [from the Charter]

Principal References


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2004-04-08-c.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org