WS-I, also known as the Web Services Interoperability Organization, has finally released the first full version of the Basic Security Profile. Release of the 1.0 version followed a four-month comment period on the final draft.
According to Paul Cotton, WS-I Basic Security Profile working group chair, and group manager, web services standards and partners at Microsoft, the draft 1.0 release survived the comment stage with no changes.
The WS-I profiles were created to establish tests so that web services created on one vendor’s SOA platform can be deciphered by another. The WS-I Basic Security Profile is a superset of the original profile, aptly named the WS-I Basic Profile.
To recap, the Basic Profile itself concentrates on compatibility in the structures of SOAP messages and bindings and WSDL service definitions. A new draft version 1.2 adds interoperability tests for WS-Addressing 1.0 and MTOM, a successor to WS-Attachment for adding binary payloads to a SOAP message.
The WS-I Basic Security Profile 1.0 just released covers two contrasting scenarios: security that is implemented inside a SOAP message, using WS-Security based headers; and security implemented at the transport layer, using HTTPS (Secure, or encrypted HTTP).
The first scenario, which is better known, is about testing interoperability of different vendor implementations of the WS-Security (also known as WS-S) 1.0. The protocol covers how you generate or handle security tokens.
The Basic Security Profile has interoperability tests for Username, X.509, REL, Kerberos, and SAML tokens. It describes how interoperability for these protocols can be tested within the body of the SOAP message or inside SOAP attachments.
The second scenario focuses on testing interoperability of so-called Transport-Level Security (TLS), which relies on HTTPS. This is a method that is already well-used, especially for direct connects between two parties.
According to Cotton, it reflects the fact that some users may wish to connect to a web service using well-established web protocols and that you don’t always require SOAP messages to connect to a web service. People didn’t appreciate the fact that the working group actually came out and said that TLS is definitely a counter measure in some cases.
On the horizon, the working group is planning the next version of the profile to support the more recent WES-Security 1.1 version. The working group feels that it’s technically complete, said Cotton, adding, We need to get interoperability testing done inside WS-I to get it to move on. That work is being done by testing tools and sample apps working group. Obviously if they found bugs we might have to change it.
Given the small change between [versions] 1.0 and 1.1, that’s not a very high probability, said Cotton.
Compared to standards development, generating test profiles to ensure that standards interoperate can seem almost anticlimactic. While standards development is intended to advance the state of the art, ensuring that each vendor’s implementation of the standards means defining criteria to deal with what’s already out there.
So it’s not surprising that WS-I is a bit behind Oasis, but that’s not necessarily such a bad thing because so are users.