I've been writing about the Global XML Web Services Architecture, a set of specifications that sit on top of SOAP and provide interoperability in a number of important areas. This article is a look at WS-Security, the GXZ security specification. These articles and associated resources are being indexed in my featured papers outline.

The OASIS web services security specification creates a set of extensions to SOAP messages that can be used to secure messages and ensure their integrity. Note that this is message-level security, not secured channels (which you could do with SOAP using HTTPS as the transport, for example). Message-level security is important whenever intermediaries are part of a conversation. These extensions are referred to as the "web services security core language" or WSS-Core. The specification was put together by Microsoft, IBM, Verisign, and others.

IBM and Microsoft have released a white paper which describes the specification. The specification extends SOAP so that the following processes can take place (quoting from the MS/IBM white paper):

• A Web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required claims, the service may ignore or reject the message. We refer to the set of required claims and related information as policy.
• A requester can send messages with proof of the required claims by associating security tokens with the messages. Thus, messages both demand a specific action and prove that their sender has the claim to demand the action.
• When a requester does not have the required claims, the requester or someone on its behalf can try to obtain the necessary claims by contacting other Web services. These other Web services, which we refer to as security token services, may in turn require their own set of claims. Security token services broker trust between different trust domains by issuing security tokens.

The paper gives a number of scenarios showing the different ways that the specification can be applied. I think its particularly important that the specification is built to accommodate existing security models rather than foisting another one upon the enterprise. This was the big mistake in 802.11a/b: the security wasn't built on existing, socially proven concepts, but something completely new that, as it turns out, didn't work.

The WS-Security specification is not the end, but the foundation for a number of other security related specifications which will build on the message-level security in the areas of security policy, trust, secure conversations, privacy, authorization, federation, and others. White papers in the areas of trust, policy, and secure conversations were released in December 2002.