OASIS TC Call for Participation: OASIS Web Services Secure Exchange (WS-SX) Technical Committee

[James Bryce Clark <jamie.clark@oasis-open.org>]

    A new OASIS technical committee is being formed. 
The OASIS Web Services Secure Exchange Technical Committee has been
proposed by the members of OASIS listed below.  The proposal (below)
meets the requirements of the OASIS TC Process [a].  The TC name,
statement of purpose, scope, list of deliverables, audience, and language
specified in the proposal will constitute the TC's official
charter.  Submissions of technology for consideration by the TC, and
the beginning of technical discussions, may occur no sooner than the TC's
first meeting. 

    This TC will operate under our 2005 IPR Policy
[b].  The eligibility requirements for becoming a participant in the
TC at the first meeting (see details below) are that: 
    (a) you must be an employee of an OASIS member
organization or an individual member of OASIS; 
    (b) the OASIS member must sign the OASIS membership
agreement (see [c]); 
    (c) you must notify the TC chair of your intent to
participate at least 15 days prior to the first meeting, which members
may do by using the "Join this TC" button on the TC's public
page at [d]; and 
    (d) you must attend the first meeting of the TC, at
the time and date fixed below. 
Of course, it also will be possible to join the TC at a later time. 
Standards always are improved by broad participation. 

    Non-OASIS members who wish to participate may contact
us about joining OASIS [c].  Our rules and structure are designed to
promote inclusiveness.  We look forward to assisting parties
interested in joining the community of implementers, technologists,
academics and end-users working on OASIS standardization projects. 
All also are welcome to take advantage of the public resources maintained
for each TC: a mail list archive, document repository and public comments
facility, which will be available via the TC's public home page at
[d].  Archives of the TC's mail list and public comment lists, as
with all OASIS TCs, will be visible at [e]. 

    Further information generally related to the topic
area addressed by this TC may be found on the Cover Pages at
""XML and Security": 
http://xml.coverpages.org/security.html

    Please feel free to forward this announcement to any
other appropriate lists. OASIS is an open standards organization; we
encourage your feedback. JBC 

~ James Bryce Clark 
~ Director, Standards Development, OASIS 
~ jamie.clark@oasis-open.org 

[a]
http://www.oasis-open.org/committees/process.php
[b] http://www.oasis-open.org/who/intellectualproperty.php 
[c] See http://www.oasis-open.org/join/ 
[d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx
[e] http://lists.oasis-open.org/archives/ 

====
OASIS WEB SERVICES SECURE EXCHANGE TC 

a. Name of the TC 

OASIS Web Services Secure Exchange (WS-SX) Technical Committee 

b. Statement of Purpose

The purpose of the Web Services Secure Exchange (WS-SX) Technical Committee (TC) is to define extensions to OASIS Web Services Security [1] to enable trusted SOAP message exchanges involving multiple message exchanges and to define security policies that govern the formats and tokens of such messages.  This work will be carried out through continued refinement of the Web Services SecureConversation, SecurityPolicy and Trust specifications [2-4] submitted to the TC as referenced in this charter.

c. Scope of Work

The TC will accept as input the February 2005 Version 1.2 of the WS-SecureConversation [2] and the February 2005 Version 1.2 of the WS-Trust [3] as published by Actional Corporation, BEA Systems, Inc., Computer Associates International, Inc., IBM, Layer 7 Technologies, Microsoft Corporation, Oblix Inc., OpenNetwork Technologies Inc., Ping Identity Corporation, Reactivity Inc., RSA Security Inc., and VeriSign Inc and the July 2005 Version 1.1 WS-SecurityPolicy [4] specifications (the Input Documents) as published by IBM, Microsoft, RSA Security and VeriSign.

Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.

In order to support general secure Web Service messaging, additional facilities are needed beyond what is provided in OASIS Web Services Security [1]. The OASIS Web Services Security specification describes a base mechanism for securing SOAP messages but does not deal with trust brokering, multi-message exchanges, and policies describing how to secure message exchanges with a Web service.  The following sub-sections describe the charter of the WS-SX TC with respect to these areas.
The scope of the TC’s work is to continue further refinement and finalization of the Input Documents to produce as output modular specifications that standardize the concepts, WSDL documents and XML Schema renderings of the areas described below.

Trusted Brokering of SOAP message exchanges

OASIS Web Services Security [1] defines the basic mechanism for providing secure SOAP messaging. It describes how to use security tokens to obtain message integrity, confidentiality and authentication of the message sender. In order to establish the authenticity of any message sender, the recipient needs to “trust” the asserted credentials of the sender. The WS-SX TC will add additional primitives to enable the establishing and brokering of these trust relationships between parties in a SOAP message exchange as defined by the policy expressions associated with the SOAP endpoints.

The scope of this work is to develop extensions to OASIS Web Services Security [1] that facilitate “trusted” SOAP message exchanges. This will be done by enabling the web services to participate in the establishment and brokering of trust relationships by means of an exchange and issuance of the relevant security tokens. In addition, some token and message validation may require the definition of specialized SOAP messages and header blocks.

This work will focus on:
1. Describing a protocol for brokering trust on behalf of a requestor by obtaining designated security tokens containing required claims from the trusted authorities.
2. Describing a framework for interactions with trusted authorities known as security token services. This includes describing the request/response elements for interactions with a security token service. This base framework for requesting and returning of security tokens should be usable for a variety of purposes related to security token services.  Web service trust bindings define how this framework is used for specific usage patterns. This specification defines Web service trust bindings for issuance, renewal, cancellation and validation of security tokens.
3. Declaring specific Web service bindings to a security token service for security token issuance including, but not limited to the following cases:
     a. Actions and elements for requesting a security token (or tokens).
     b. Actions and elements for responding with a security token (or tokens).
     c. Specifying the scope of each returned security token using WS-Policy [5] <wsp:AppliesTo>.
     d. Specifying mechanisms for issuing, computing or utilizing existing keys as proof keys associated with the issued token.
     e. Support for requesting and returning bearer tokens
     f. Requesting or returning multiple security tokens.
     g. Transferring security tokens as part of application messages as well as part of the SOAP body of a separate response message
     h. Requesting a security token (or tokens) on behalf of another entity (or entities).
     i. Requesting a security token (or tokens) that may be forwardable or delegatable.
     j. Specifying characteristics of the requested type of keys.
4. Declaring specific Web service bindings of the security token service framework for security token renewal. Renewal is the process by which a previously issued token with expiration is presented at a security token service and the same token is returned with new expiration characteristics. Such a renewal binding should be defined for (but not be limited to) the following:
    a. Actions and elements for requesting the renewal of a single token.
    b. Actions and elements for responding with a renewed token.
    c. Allowing for direct or indirect references to the security tokens being renewed.
5. Declaring specific Web service trust bindings of the security token service framework for cancellation.  When a previously issued token is no longer needed, the cancel binding can be used to cancel the token,
terminating its use. Such cancel binding should define (but not be limited to) the following cases:
    a. Actions and elements for requesting the cancellation of a single token.
    b. Actions and elements for responding with the cancellation result.
    c. Allowing for direct or indirect references to the security tokens being cancelled.
6. Declaring specific Web service trust bindings of the security token service framework for token validation. Validation binding is used to evaluate a security token (or OASIS Web Services Security [1] compliant message) and the result is returned as a status, token or both. Such a validation binding should be defined for (but not be limited to) the following:
     a. Actions and elements for requesting the validation of a token (or message).
     b. Actions and elements for responding about the validity of a token.
     c. Allowing for direct or indirect references to the security tokens being validated.
7. Generalizing the mechanism for a security token service to allow for multi-leg exchanges. Such exchange should allow for, but not be limited to "challenges", tunnelling of legacy binary protocols, and tunnelling of
hardware-based legacy protocols. Specifically, the following models of challenge and exchanges should be defined by this specification: 
     a. Signature challenge that requires the other party to sign specified information.
     b. Binary exchanges involving the usage of binary data from existing non-Web Services protocols.
     c. Exchanges involving request and passing of a key exchange token 

Shared security contexts

OASIS Web Services Security [1] describes using security credentials to implement message integrity, confidentiality and authentication. In cases where multiple messages need to be exchanged securely, typically a shared security context is established between the communicating parties and used for the life time of the message exchange. This TC will also address adding extensions to Web Services Security [1] and define the appropriate secure SOAP message exchanges (see above) to permit the definition of shared security contexts. 

This work will encompass:
1. Defining mechanisms for establishing a shared security context in the following cases:
     a. When one of the communicating parties creates the context and propagates it to other parties.
     b. When the shared context is achieved through a sequence of negotiations.
     c. When the shared context is brokered through a third party security token service.
2. Defining specific Web service bindings for security context establishment by utilizing the Web service trust binding elements for requesting and responding with security context tokens.
3. Defining specific Web service bindings for renewal of the security context token.
4. Defining specific Web service bindings for cancellation of the security context token.
5. Defining specific Web service bindings for amendment of the claims associated with a security context.
6. Since a shared security context may contain or imply a shared key, this specification must contain descriptions of common elements for key derivation models, where such a scheme is desirable for improving the security characteristics of the keys being used.
7. Defining a token profile for use of security context tokens with OASIS Web Services Security [1].
8. Defining a token profile for use of derived key tokens with OASIS Web Services Security [1].

Security policies

OASIS Web Services Security [1], WS-SecureConversation [2] and WS-Trust [3] define open-ended wire formats.  WS-Policy [5] defines a framework for allowing web services to express their constraints and requirements as policy assertions. WS-SecurityPolicy [4] uses the facilities of WS-Policy [5] to express the conditions and restrictions on the wire formats defined by OASIS Web Services Security [1], WS-SecureConversation [2] and WS-Trust [3] to a specific set of typed message interchanges. That is to say WS-SecurityPolicy "strongly types" the supported security messages.  This type of policy enablement allows the supported message exchanges to be analyzed from a security perspective to indicate which security protocols an end point supports. 

This work will specifically define the following:
1. Mechanism for specifying what parts of the message must be secured, called protection assertions
     a. Such protection assertions must be able to specify integrity requirements at both the element and header/body level in a security policy binding (defined below) neutral manner.
     b. Such protection assertions must be able to specify confidentiality requirements at both the element and header/body level in a security policy binding (defined below) neutral manner.
     c. Such mechanisms must not require the use of XPath 1.0 [21] but may provide it as an option.
2. Mechanism for specifying pre-conditions of security, called conditional assertions
     a. Such conditional assertions must be able to specify the required elements in the message 
3. General mechanism for specifying tokens to use in protecting the message or binding claims to the message, called token assertions
     a. Such token assertions should facilitate the specification of at least the following token types defined by OASIS SOAP Message Security, WS-Trust and WS-SecureConversation: Username token, X509 token, Kerberos token, SPNego Context Token, Security Context Token, Secure Conversation Token, SAML token, REL token, HTTPS token as well as any opaque token issued by a security token service.
     b. Such token assertions should specify conditions for inclusion in the message such as whether the token should be included in every message explicitly, whether the token should be always excluded from the message and a reference included in the message, whether the token should be included once in a message exchange and external reference should be used subsequently.
     c. Such token assertions should support specification of derived keys.
4. An abstraction for describing some of the common security usage patterns called security policy bindings.
a. Such an abstraction should contain a description of the required and optional elements of such a security policy binding, including minimal token requirements, necessary key transfer mechanism, structure and contents of elements in wsse:security header, and correlation mechanisms.
     b. Such a binding framework should also include properties for describing algorithm suite to be used, whether a timestamp should be included, signature/encryption ordering in the message, whether signatures are encrypted, and whether the signing token should also be covered by the signature.
     c. Specific security policy binding assertions for the patterns where transport is used, where a symmetric key token is used for message security or where an asymmetric key token pair is used for message security.
5. A mechanism for specifying additional token types that provide additional claims, called supporting token assertions. Such a mechanism should support the following cases: 
    a. When additional tokens are used to sign additional parts of the message
    b. When additional tokens are signed by the primary signature token
    c. When additional tokens sign the primary signature
    d. When additional tokens sign the primary signature and are signed by the primary signature token 
6. A mechanism for specifying token referencing and token issuance called WSS assertions and Trust assertions that meet the referencing mechanisms and properties defined in OASIS Web Services Security 1.0 (and associated token profiles) [1], OASIS Web Services Security 1.1 (and associated token profiles) [6], in WS-Trust [3] and WS-SecureConversation [2]. Such a mechanism should include:
a. Properties for indicating the Web Services Security 1.0 [1] defined reference mechanism to use
    b. Properties for indicating the Web Services Security 1.1 [6] defined reference mechanism to use including thumbprint reference and encryptedkey reference
    c. Signature confirmation requirement
    d. Properties for indicating the type of challenges required (as defined in WS-Trust [3])
    e. Properties for indication the type of entropy mechanism required in a negotiation sequence (as defined in WS-Trust [3])

General Notes on Scope

The output specifications will uphold the basic principles of other Web services specifications of independence and composition and be composable with the other specifications in the Web services architecture, such as the specifications listed in the References section, numbers 1, 5-12 and 18-20.   The TC will also take into consideration the following specifications/works listed in the References section, numbers 13, 14, 15 and 16.  
If any of the above specifications is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far enough along in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.
While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.
Each of the protocol elements will use implementation and language neutral XML formats defined in XML Schema [17].

Out of Scope

The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.
The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular messaging middleware, nor to specific network transports.

The following items are specifically out of scope of the work of the TC:
1. Definition and management of trust policy expressions (that is, statements about who is trusted to make what claims about an entity); these are different from the in-scope "trust assertions" referred to in the Scope
of  Work section above
2. Token revocation notifications and revocation management (e.g. via CRLs)
3. Schemas for specific tokens issued, renewed, cancelled or validated as part of the trust process.
4. The establishment of trust between two or more business parties
5. Definition of new key derivation algorithms
6. Providing a general purpose boxcaring model
7. Definition of APIs

The TC will not attempt to define concepts or renderings for functions that are of wider applicability including but not limited to:
    -- Addressing
    -- Policy language frameworks
    -- Routing
    -- Reliable message exchange
    -- Transactions and compensation
Where required these functions are achieved by composition with other Web services specifications.

The TC will not attempt to define functionality duplicating that of any normatively referenced specification in the input WS-SecureConversation [2], WS-Trust [3] or WS-SecurityPolicy [4] specifications.If the referenced specification is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far along enough in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability. 

d.  Deliverables

The TC has the following set of deliverables:
    *  A revised Web Services SecureConversation specification and associated Schema.   A Committee Specification is scheduled for completion within 18 months of the first TC meeting.
    *  A revised Web Services Trust specification with associated Schema and WSDL.  A Committee Specification is scheduled for completion within 18 months of the first TC meeting.
    *  A revised Web Services SecurityPolicy specification and associated Schema.  A Committee Specification is scheduled for completion within 18 months of the first TC meeting.

These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with this charter.
Ratification of the above specifications as OASIS standards, including a brief period to address any errata will mark the end of the TC’s lifecycle.

e. Anticipated Audience

The anticipated audience for this work includes:
    *  Vendors offering web services products
    *  Other specification authors that need security for Web services
    *  Software architects and programmers, who design, write or integrate applications for Web services
    *  End users implementing Web services-based solutions that require an interoperable, composable solution for trusted SOAP message exchanges, security policies and shared security contexts. 
    *  Vendors making gateway and router class products (both hardware and software)

f.  Language

TC business will be conducted in English. 

g.  IPR Policy

This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15 April 2005. 

====
The following is informational only for the purposes of starting the TC, and will not be part of the TC's charter.

a. Related Work

Since the specifications developed by the WS-SX TC are part of the Web Services Architecture, and must work well with other specifications within that architecture, the following work may be relevant to this WS-SX TC:

Similar Work:
The specifications developed by the WS-SX TC address functionality required for Web services that is not addressed in other security related activities.  The WS-SX TC will be informed by the following:
    *  Internet X.509 Public Key Infrastructure Qualified Certificates Profile [22]. 
    *  The Liberty Identity Web Services Framework (ID-WSF) [23], [24]. 
    *  Open Mobile Alliance Web Services Enabler (OWSER) [25]. 
    *  The Kerberos Network Authentication Service [26] from IETF. 
    *  Security Requirements for Cryptographic Modules [27], from NIST.
    *  Security Assertion Markup Language (SAML) [28] from OASIS. 
    *  eXtensible Access Control Markup Language (XACML) [29] from OASIS.
    *  XML Key Management Specification (XKMS) [30] from W3C.

The proposers of this TC recognize there are different security approaches in the industry and believe that the defined Scope of Work of this TC addresses many functional use cases of these parallel efforts. The proposers of this TC seek involvement from authors of other such activities and the contribution of their expertise and experience, and intend to work in harmony with them in the creation of the product of this technical committee.

Applicable Work:
    *  OASIS Web Services Security TC.  WS-SX TC will ensure that its specifications compose with the WSS TC specifications.
    *  OASIS Web Services Reliable Exchange TC.  WS-SX TC will ensure that its specifications compose with the WS-RX TC specifications.
    *  OASIS Web Services Transaction TC.  WS-SX TC will ensure that its specifications compose with the WS-TX TC specifications.

The TC may decide to establish liaisons with other groups as needed. Responsibilities for such liaison will be defined by the TC at that time.

b. Anticipated Contributions 

The current WS-SecureConversation Version 1.2 [2] and WS-Trust Version 1.2 [3] specifications  (as published in Feb 2005) are expected to be contributed to this TC by Actional Corporation, BEA Systems, Inc., BMC Software, Computer Associates International, Inc., IBM, Layer 7 Technologies, Microsoft Corporation, Oracle, Ping Identity Corporation, Reactivity Inc., RSA Security Inc., and VeriSign Inc and the current WS-SecurityPolicy Version 1.1 [4] specification (as published in July 2005), is expected to be contributed to this TC by IBM, Microsoft, RSA Security and VeriSign.  

c. Date and Time of First Meeting

The first meeting of the WS-SX TC will be a two day face to face meeting held in Redmond, WA on Wednesday and Thursday, December 7-8 from 9:00 am to 5:30 local time.  This meeting will be sponsored by Microsoft Corporation.

d. On-Going Meeting Plans & Sponsors

It is anticipated the WS-SX Technical Committee will meet via teleconference every week at a time determined by the TC members during the TC's first meeting. 
It is anticipated that the WS-SX Technical Committee will meet in face to face every quarter at a time and location to be determined by the TC members.  
Actual pace of face to face and teleconference meetings will be determined by TC members. 
One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities.  If no other TC proposers offer to sponsor teleconference facilities, Microsoft or IBM will donate their facilities. If OASIS establishes a phone bridge system as is being discussed that will be used instead. 

e. Proposers of the TC

The following eligible individuals are in support of this proposal:

Dan Appelquist, Vodafone, daniel.appelquist@vodafone.com
Steve Anderson, BMC (OpenNetwork), steve_anderson@bmc.com
Abbie Barbir, Nortel, abbieb@nortel.com
Siddharth Bajaj, VeriSign, sbajaj@verisign.com
Michael Bechauf, SAP, michael.bechauf@sap.com
Martijn de Boer, SAP, martijn.de.boer@sap.com
Jeff Bohren, BMC (OpenNetwork), jeff_bohren@bmc.com 
Toufic Boubez, Layer 7 Technologies, tboubez@layer7tech.com
Lloyd Burch, Novell, lburch@novell.com
Steve Carter, Novell, srcarter@novell.com
Dave Chappell, Sonic Software, chappell@sonicsoftware.com
Kathleen G. Cherry, Lockheed Martin Corporation, kathleen.g.cherry@lmco.com
David M. Connelly, Open Applications Group, dconnelly@openapplications.org
Paul Cotton, Microsoft, pcotton@microsoft.com
Blake Dournaee, Sarvega an Intel Company, blake@sarvega.com
Glen Daniels, Sonic Software, gdaniels@sonicsoftware.com
Petr Dvorak, Systinet, petr.dvorak@systinet.com
Ruchith Fernando, WSO2, ruchith@wso2.com
Dan Foody, Actional, dan@actional.com
Hans Granqvist, VeriSign, hgranqvist@verisign.com
Phillip Hallam-Baker, VeriSign, pbaker@verisign.com
Peter Hendry, Cape Clear, peter.hendry@capeclear.com
Frederick Hirsch, Nokia Corporation, frederick.hirsch@nokia.com
Chris Kaler, Microsoft, ckaler@microsoft.com
Dana Kaufman, Forum Systems, dkaufman@forumsys.com
Paul Knight, Nortel, paul.knight@nortel
Ram Krishnamurthy, IONA, ramanathan.krishnamurthy@iona.com
Chris Kurt, Microsoft, ckurt@microsoft.com
Kelvin Lawrence, IBM, klawrenc@us.ibm.com
Richard Levinson, Computer Associates, richard.levinson@ca.com
Mark Little, Arjuna, mark.little@arjuna.com
Hal Lockhart, BEA Systems, hlockhar@bea.com 
Denis Lussier, Individual, denis@enterprisedb.com
Ashok Malhotra, Oracle, ashok.malhotra@oracle.com
Robin Martherus, Oracle, robin.martherus@oracle.com
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
Prateek Mishra, Oracle, Prateek.Mishra@oracle.com
Vamsi Motukuru, Oracle, vamsi.motukuru@oracle.com
Anthony Nadalin, IBM, drsecure@us.ibm.com
Andrew Nash, Reactivity, anash@reactivity.com
Eric Newcomer, IONA, eric.newcomer@iona.com 
Duane Nickull, Adobe, dnickull@adobe.com
Darren Platt, Ping Identity, dplatt@pingidentity.com
Martin Raepple, SAP, martin.raepple@sap.com
Alain Regnier, Ricoh, alain@ussj.ricoh.com
Irving Reid, HP, irving.reid@hp.com
Claus von Riegen, SAP, claus.von.riegen@sap.com
Maneesh Sahu, Actional, Maneesh@actional.com
Rich Salz, DataPower, rsalz@datapower.com
Hitoshi Sekine, Ricoh, hitoshi@ussj.ricoh.com
Davanum Srinivas, WSO2, dims@wso2.com
Gene Thurston, Amberpoint, gthurston@amberpoint.com 
Paola Tonelli, Vodafone, Paola.Tonelli@vodafone.com
David Waite, Ping Identity, dwaite@pingidentity.com
Greg Whitehead, Trustgenix, grw@trustgenix.com
Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com 

f. TC Convener

The TC Convener will be Paul Cotton, Microsoft Corporation, pcotton@microsoft.com 

g. Proposed Co-Chairs 

The charter proposers recommend the following as TC Chair(s): 
    *  Kelvin Lawrence, International Business Machines Corporation, klawrenc@us.ibm.com 
    *  Chris Kaler, Microsoft Corporation, ckaler@microsoft.com 

References
 
[1] WS-Security Version 1.0
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf  

Web Services Security: SAML Token Profile 1.0
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 

Web Services Security: REL Token Profile 1.0
http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf 
 
[2] WS-SecureConversation
http://schemas.xmlsoap.org/ws/2005/02/sc
 
[3] WS-Trust
http://schemas.xmlsoap.org/ws/2005/02/trust 

[4] WS-SecurityPolicy
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy 

[5] WS-Policy 
http://schemas.xmlsoap.org/ws/2004/09/policy/ 

[6] WS-Security Version 1.1
http://www.oasis-open.org/committees/download.php/13397/wss-v1.1-spec-pr-SOAPMessageSecurity-01.pdf 

http://www.oasis-open.org/committees/download.php/13396/wss-v1.1-spec-pr-SOAPMessageSecurity-01.htm

Web Services Security: SAML Token Profile 1.1 
http://www.oasis-open.org/committees/download.php/13404/wss

Web Services Security: X.509 Certificate Token Profile 1.1 
http://www.oasis-open.org/committees/download.php/13383/wss-v1.1-spec-pr-x509TokenProfile-01.htm

Web Services Security: Kerberos Token Profile 1.1 
http://www.oasis-open.org/committees/download.php/13389/wss-v1.1-spec-pr-KerberosTokenProfile-01.htm

Web Services Security: UsernameToken Profile 1.1 
http://www.oasis-open.org/committees/download.php/13392/wss-v1.1-spec-pr-UsernameTokenProfile-01.htm

Web Services Security: Rights Expression Language (REL) Token Profile 1.1  
http://www.oasis-open.org/committees/download.php/13301/wss-v1.1-spec-pr-RELTokenProfile.htm 

Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.1 
http://www.oasis-open.org/committees/download.php/13288/wss-v1.1-spec-pr-SwAProfile-01.html

[7] WS-ReliableMessaging 
http://www.oasis-open.org/committees/document.php?document_id=13220&wg_abbrev=ws-rx 

[8] WS-Addressing
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

[9] SOAP 1.1
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 

[10] SOAP 1.2
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 

[11] WSDL 1.1 
http://www.w3.org/TR/2001/NOTE-wsdl-20010315 

[12] WSDL 2.0 
http://www.w3.org/TR/wsdl20/ 

[13] WS-I Basic Profile 
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

[14] WS-I Basic Security Profile 
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html 

[15] Secure, Reliable, Transacted Web Services: Architecture & Composition
http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp 

http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html

[16] Security in a Web Services World: A Proposed Architecture and Roadmap
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp 

http://www-128.ibm.com/developerworks/library/ws-secmap/ 

[17] XML Schema
XML Schema Part 1: Structures
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ 

XML Schema Part 2: Datatypes
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 

[18] WS-Coordination
http://schemas.xmlsoap.org/ws/2004/10/wscoor 

[19] WS-AtomicTransaction
http://schemas.xmlsoap.org/ws/2004/10/wsat 

[20] WS-BusinessActivity
http://schemas.xmlsoap.org/ws/2004/10/wsba 

[21] XPath 1.0
http://www.w3.org/TR/1999/REC-xpath-19991116 

[22]  ITU-T Recommendation X.509 (2000)
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/2000/index.html, March 2000.

[23] Liberty Identity Web Services Framework (ID-WSF)
http://www.projectliberty.org/resources/specifications.php

[24] Liberty ID-WSF Authentication Service Specification
http://www.projectliberty.org/specs/draft-liberty-idwsf-authn-svc-v2.0-02.pdf

[25] Open Mobile Alliance Web Services Enabler (OWSER)
http://www.openmobilealliance.org/release_program/owser_v10.html 

[26] J. Kohl and C. Neuman, "The Kerberos Network Authentication Service 311 (V5)," RFC 1510, September 1993, http://www.ietf.org/rfc/rfc1510.txt

[27]  Security Requirements for Cryptographic Modules, May 2001. 
See http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf .

[28] Security Assertion Markup Language (SAML)
http://www.oasis-open.org/committees/security/

[29] eXtensible Access Control Markup Language (XACML)
http://www.oasis-open.org/committees/xacml/

[30] XML Key Management Specification (XKMS)
http://www.w3.org/2001/XKMS/

END