An OASIS discussion list has been created on the topic Web Services Security Quality of Protection. Subscribers to the 'WSSQoP-Discuss' list will discuss the possible creation of an OASIS Technical Committee. Sponsors of the proposal include representatives from CommerceOne, Cisco, Entrust, IBM, RSA Security, SAP, Sun Microsystems, and VeriSign; the discussion leader is Tim Moses (Entrust). The stated purpose of the TC under discussion would be "to identify candidate solutions for communicating the required security tokens and quality of protection for a Web service, taking advantage of the common service definition tools, such as WSDL. The solutions are intended to allow a service consumer to determine (1) how to produce a SOAP message including security tokens and protection mechanisms, in accordance with WSS, that is acceptable to both the provider and consumer, and (2) whether the consumer is capable of performing the required security processing on the response from a Web service. Components of security policy include at least the set of acceptable types of security token, the set of acceptable cryptographic algorithms, (optionally) what key to use for encryption, and the payload nodes to be protected. The topic is potentially open-ended, leading to solutions for trust policy, authorization policy, personal privacy policy, etc. While recognizing this, it is the intention to limit the identified solutions to those that address the QoP of the initial mechanisms of WSS. This is analogous to the 'cipher suites' and "supported algorithms" mechanisms of TLS and S/MIME, respectively. In addition, the group will identify candidate process models for producing a WSDL instance from a security policy definition, and producing a language-specific API from a WSDL instance..."

From a strawman document "Web-Services Security Quality of Protection" posted by Tim Moses (see reference below): "Problem statement: WSS allows Web-service providers to implement a security policy. The term security policy is used in this context to mean: 'a statement of the requirements for protecting arguments in a WS API, including: (1) how actors are to be authenticated, using what mechanisms and with what parameter value ranges; (2) which XML elements are to be encrypted, for what individual recipients, recipient roles or keys, using what algorithms and key sizes; (3) which XML elements are to be integrity protected, using what mechanisms, with which algorithms and key sizes, and (4) what additional qualifications the service consumer must demonstrate in order to successfully access the API'. This is a relatively restrictive use of the term 'security policy'. A more comprehensive definition addresses such requirements as: (1) privacy (retention period, intended usage, further disclosure); (2) trust (initial parameters of the signature validation procedure, including those keys or authorities that are trusted directly, policy identifiers, maximum trust path length), and (3) non-repudiation (requirements for notarization and time-stamping)..."

Proposed activities of the TC under discussion

• Prepare a full list of the components of a Web-Service security policy
• Identify the subset of policy components required to support the initial mechanisms of WSS
• Receive briefings on related activities (e.g. WSDL, UDDI, ebXML, WSS)
• Propose and evaluate publication models
• Propose and evaluate process models
• Agree the next step
• Publish a summary report

Sponsors of the proposal

Zahid Ahmed, CommerceOne, zahid.ahmed@commerceone.com
Martijn de Boer, SAP, martijn.de.boer@sap.com
Yassir Elley, Sun, yassir.elley@Sun.com
Phillip Hallam-Baker, VeriSign, pbaker@verisign.com
Ron Monzillo, Sun, ronald.monzillo@sun.com
Tim Moses, Entrust, tim.moses@entrust.com
Tony Nadalin, IBM Nadalin drsecure@us.ibm.com
Robert Philpott, RSA Security, rphilpott@rsasecurity.com
Krishna Sankar, Cisco, ksankar@cisco.com