Consortium batches first WS-security specs. (Storage Networking).

In a critical step forward in the challenge to secure data shared among enterprises, a group of industry majors has announced the first batch of specifications designed to make Web services and transactions reliable and safe. The overall framework, called Web Services Security (WS-Security for short) is expected to move into implementation phase later this year.

The group, composed of BEA Systems, IBM, Microsoft, RSA Security, SAP AG and VeriSign, announced in late December six new subspecifications of the WS-Security framework, which IBM and Microsoft introduced last spring. The new sub-specs are organized into two groups. The first addresses technical concerns in the area of security and builds on the work Outlined in the two companies' co-produced road map, Security in a "Web Services World", authored in April. The second group focuses on streamlining the implementation of business policies in a Web services environment.

To understand the new specifications, it helps to first understand a few assumptions that underlie the WS-Security efforts. In April, Microsoft and IBM introduced a joint white-paper that somewhat loosely outlined a new security structure that would ensure the reliability of data sent among enterprises across the Web. According to the white-paper, WS-Security defines the core facilities for protecting the integrity and confidentiality of a message, as well as mechanisms for associating security-related claims with the message. WS-Security seeks to unify the various (and varied) standards-based security specs (including SOAP WSDL, XML Digital Signatures, XML Encryption and SSL/TLS) into a single, flexible framework.

One of the critical goals of the WS-Security effort is that it provides a mechanism for adding interoperable security elements to pre-existing applications with their own security architectures already in place. For example, a customer could add message-level integrity or persistent confidentiality (encryption of message elements) to an existing Web service whose messages are carried through Secure Sockets Layer (SSL/TLS). The messages would then have integrity (or confidentiality) that persists beyond the transport layer.

What is the overall business goal of the framework? In essence, as enterprise applications and business processes are recast as Web services, companies need a way to guarantee to their customers that their investments (and their data) are secure in an increasingly interconnected world. Many see WS-Security as the most broadly accepted effort in this direction: Even Sun, which has been pushing for a different open security initiative--called Project Liberty--appears to be somewhat amenable to WS-Security, with some provisos. Many not currently in the camp, however, are taking a wait-and-see approach.

The WS-Security framework grew out of work done by IBM and Microsoft on three of the most promising Web services specifications: the Simple Object Access Protocol (SOAP); Universal Description, Discovery and Integration (UDDI), and Web Services Description Language (WSDL). SOAP is an XML-based protocol for accessing remote objects over a network, while UDDI and WSDL allow companies to register, describe, and access services using standardized methods. WS-Security is intended to be a SOAP-based extension, and will likely be integrated as one portion of a SOAP-based message.

New Specifications

The first three of the six WS-Security specifications announced in December fall under the heading of technical security elements of the framework. They include:

* WS-Trust. It describes a framework for managing, establishing and assessing trust relationships to enable Web services to securely interoperate (authored by IBM, Microsoft, RSA Security and VeriSign);

* WS-SecureConversation. It describes a framework to establish a secure context for parties that want to exchange multiple messages (authored by IBM, Microsoft, RSA Security and VeriSign);

* WS-SecurityPolicy. It describes general security policies that can be associated with a service (authored by IBM, Microsoft, RSA Security and VeriSign).

The second group focuses on streamlining the implementation of business policies. These include:

* WS-Policy. It outlines a way for senders and receivers of Web services to communicate their requirements and capabilities, which enables them to search for and discover the information they need to access the service (authored by BEA, IBM, Microsoft and SAP);

* WS-Policy Attachment. It provides a standard mechanism for attaching the requirement and capability statements to the Web service (authored by BEA, IBM, Microsoft and SAP);

* WS-Policy Assertions. It describes general policies that can be affiliated with a service (authored by BEA, IBM, Microsoft and SAP).

Some additional details are necessary in order to understand how some key parts of the framework will operate. WS-Trust will provide for direct and third-party-brokered trust relationships through the creation of "security token issuance services." WS-SecureConversation will describe how a Web service can authenticate requester messages; how requesters can authenticate services; and how to establish mutually authenticated security contexts. (In other words, how to have a conversation without having to re-authenticate each time message is sent.)

While details are still sketchy in terms of how each specification will be implemented, the vendors say that understanding the nuts and bolts of how the pieces fit together is not a necessity. All the companies have committed to adding the WS-Security specs to their key products, with customers only responsible for setting up security policies. Further, WS-Security is a framework for secure Web services, and as such can use various token types for different security assertions (authentication, identity, access control, and so on).

How Open Is Open?

As is par for the course for any Microsoft-authored effort, companies not directly involved in the development of WS-Security have doubts about the true openness of the specifications released in December. This is, in part, because Microsoft and IBM have yet to submit their new specifications to an international standards body. In particular, the Organization for the Advancement of Structured Information Standards (OASIS), though it has a technical committee looking at the overall framework, has yet to review the new standards, and it is not clear when (or it) the new proposed standards will be submitted to this group. Many observers feel that to truly be an open standard, the entire WS-Security scheme--including the recent additions-needs to go through OASIS, a non-profit, global consortium that develops and supports e-business standards, including XML and SAML.

"The specifications released in December were a private publication, not a part of the Web services security work going on in OASIS," notes Ed Reed, Security Tzar at Novell, which currently supports Project Liberty. "It is hard to say what impact or relevance they'll have, yet, on customer efforts to deploy Web services. There are certainly a broad range of vendor suggestions and contributions in this space, but we're a long way from a broadbased consensus on what is needed or how we'll achieve it."

Reed says that many vendors with Web services software are waiting to see how things shake out, and are particularly waiting to see how much of an open standard WS-Security actually becomes. "It's [hard] to predict when vendors will implement the WS-Security framework; certainly you'd expect the vendors involved in the announcement to implement as soon as possible, but vendors committed to open standards, like Novell, will need to see this work handed over to a standards body before committing to it."

Reed adds that Novell is currently implementing the Liberty Alliance specification, based on the SAML specification from OASIS. "The other so-called specifications have not yet been offered to any of the open standards groups for consideration, so I have to assume their widespread industry adoption is still some time away."

Still, analysts feel that while the new specifications have not yet gone to OASIS, this remains the ultimate goal. 'There is already an OASIS Technical Committee that works on WS-Security, and their stated goal is the presentation of WS-Security as an OASIS standard," says Ray Wagner, Research Director of Information Security Strategies at Gartner Group. "I think we will see movement toward a 1.0 standard, including at least what we've seen so far, during 2003."

But while Microsoft, IBM, and the other vendors involved in WS-Security have said that an open standard is the goal, Novell is not alone in its wait-and-see approach. Key security, database, and hardware vendors, including Entrust, Oracle, and Sun have not been involved in WS-Security development and have yet to sign on to the effort. Like Novell, these and other vendors would like to see the full standard pass through a community review process, in the form of a standards body, before it is implemented.

"The recently released security-related specs are only one part of a much larger industry effort, which is focused on convergence of overlapping standards, open participative development and royalty-free licensing terms," says Susan Struble, manager of XML industry initiatives at Sun. "Important security related standards work is in progress across a number of different organizations, such as OASIS, the W3C and Liberty Alliance Project."

As for WS-Security, Struble says Sun has not ruled it out, but is still waiting for more progress. Sun will be able to make a decision "when these specifications have been submitted to a recognized standards body for open development and have published and clear licensing terms," Struble adds.