When IBM, Microsoft, and VeriSign announced in July 2002 that they planned to move their proposed WS-Security standard to the OASIS group, they had successfully convinced Sun Microsystems to join the effort, and thus avoided a potential prolonged dispute over how to add baseline security -- things like encryption and digital signature support -- to Web services. But there is a lot more to it than just baseline security. This could be the beginning of a major step forward for webservices.

For enterprises making big commitments on XML webservice based application architectures, there are some important issues that have been put on the table:

WS-Security should  have broad support among actual security vendors

WS-Security does not answer all the security needs for XML-based Web services

Additional specifications may now come from OASIS, not necessarily W3C. OASIS may be replacing the W3C as most important Web services standards body.

There is now an opportunity for WS-Security to play well with Secure Assertions Markup Language (SAML). 

Let's take  a look at these issues:

WS-Security : a broad security standard

The addition of Sun to the "big player list" was an important step forward, and is likely to have a ripple effect as more players decide to finally jump into the webservices pool. Getting everyone around the same table will be good for the entire industry.

Besides Sun's backing of WS-Security is the fact that most mainstream security vendors -- the big players that will actually deploy and support the specifications -- are already firmly in the WS-Security camp. In addition to VeriSign, security-oriented vendors such as Baltimore Technologies, Entrust, Netegrity, RSA Security, and Novell are WS-Security backers, and they will be involved in creating more security standards at OASIS. Many of these vendors have also been behind SAML, a key standard for enabling cross-platform single sign-on.

What Does WS-Security Do?

WS-Security's goal is to specify how to secure Web services -- including encryption and access control -- in a platform-independent manner. It's generally accepted today that security is the key driving force -- and the biggest bottleneck -- in the deployment of Web services by enterprise customers.  By using the SOAP extensibility model, SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment.

WS-Security defines a set of SOAP headers that can be used to implement security measures for Web services. The WS-Security specification describes how to add encryption and digital signatures to Web services (in each case supporting the W3C's XML-Encryption and XML-Signature). WS-Security also defines a general mechanism for passing around security tokens. These are the foundations of a standardized, industry - wide SOAP security framework.

The goal of WS-Security is to enable applications to construct secure SOAP message exchanges. The Web services security language must support a wide variety of security models.  The key driving requirements for this specification are:

At this point, WS-Security and SAML work together: WS-Security defines how you insert the information into a SOAP envelope, and SAML defines what the security information is.

The overall thrust with WS-Security is to build a "security stack" in a manner similar to the way the industry built a basic Web services protocol stack with XML Schemas, SOAP, WSDL, and so on. This concept of simplifying and consolidating Web services security efforts is also a key force behind WS-Security.

WS-Security: Room for improvement

WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. Specifically, WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies.

As presently composed, WS-Security is not the "end all", but only a start, and the three main supporters -- IBM, Microsoft, and VeriSign -- are aware of this. When they kicked off the WS-Security effort in April, and again when they moved it to OASIS, they emphasized that they planned to deliver a much broader architectural plan for Web services security.  Microsoft's Global XML Web Services Architecture (GXA) is how their version of this vision is laid out.

The partners, who now include the larger OASIS working group members, are working on specifications in six other important areas.  Of course, there may be some combination and consolidation of these as time goes on. The six proposed specifications come in two major areas, policy and federation:

Policy

Federation