OASIS ratification was pretty significant. It provides a building block for data-packet level confidentiality and integrity. It's a good milestone to achieve. Now developers can build more sophisticated protocols and coupling on top of message-layer security. What's next on the WS-Security road map?
WS-Security 1.1. Encrypted headers is going to be a priority. You can't encrypt SOAP patterns beyond what's in the WS-Security header. We have created a draft that explains how to wrap elements with an encrypted header element.
The next major thing is making sure we get the (WS-I) Basic Security Profile wrapped up. WS-Security was designed to be extensible because people want to do certain things with message=level security. The only way to do that is to have extensible points there.
Currently, we are also in the midst of ratifying XrML (Extensible rights markup language) token profile. We prepared a community draft and review and we got little to no comments, so we're in the midst of revving that. We should start a vote soon.
The Kerberos profile is coming along. The next one we do is going to be a minimalist profile where we try to figure out how to get more performance and more of a footprint out of the Web services stack. It will be geared for mobile devices. Vendor support has been strong for WS-Security, even prior to ratification. What potential hurdles did this ease?
The number of vendors supporting WS-Security is quite large. Microsoft, Sun, Oracle, BEA and all of the XML firewall and security vendors support WS-Security. Their support is important because now we have a single programming model for doing Web services security. Now we have an end-to-end programming method. You can now go across the enterprise and exchange SOAP messages. Prior, everyone had a different way to exchange them. It is a building block for other things to come. Is security still the major impediment to Web services deployments? How is that landscape changing?
The landscape is changing. With the customers I'm seeing, from governments to enterprises, WS-Security is showing up as a fundamental building block of their Web services. What we have established here is a check box for security for Web services.
So do I see security as an impediment? In some ways it is. For more sophisticated Web services people who need trust and federation, it still is. For single Web services, it's not an impediment. Where do the WS-Secure Conversation and WS-Trust specs stand?
We are ready to do our interops (interoperability workshops Oct. 5 and 6 in Austin, Texas. These workshops are gatherings of companies with implementations of these specifications where feedback is exchanged.) We hope once these are complete that we don't need to rev the specs and we can take them to standards body. That's basically the direction we're taking with all of our specs.
We're also working on a policy specification and the W3C is holding a workshop on policy in Oct. where we're going to present papers. The W3C is ready to determine whether to do a technical committee on policy. Are there too many specifications, or are they a necessary evil?
There are quite a few and you have to take this into consideration. Even at IBM, we query a standards base when starting a project to make sure we're not duplicating efforts. There has been definite duplication in some areas like reliability and reliable messaging that need to get worked out. As standards progress, the industry is not going to tolerate multiple standards in the same space. How important is the work WS-I is doing?
If I look at a lot of Web services specification, they are small and extensible and meant to be composed together because of SOA (service-oriented architecture). What people miss is how to build something out of these specs that is interoperable. Web services specifications as they are can be interoperable, but if one company takes a different viewpoint on one sentence in the spec, it can end up not being interoperable.
WS-I's idea is to transfer that responsibility and make sure they dig into a spec enough where all the 'shalls' and 'mays' are tight to one option, and if you're not using that one option, you're not conformant to the spec. It does tighten things down, but that is the point. What do you make of Sun's recent cooperation with Microsoft, IBM and others on specifications?
Sun has been working with us extensively from the beginning of WS-Security and some other specs. I do believe they are a proponent of making sure we have the best security for Web services available. We're glad to have them aboard; everyone certainly benefits. The spec also benefits from a lot of partners working on it.
Note: This article originally appeared on SearchWebServices.com.