I spent my summer deep in an engineering project, the purpose of which will come to light in coming months. Now that the first phase of that work is complete, I have time to start posting again. And what better place to start than by answering questions raised by Simon Fell's recent post about the use of WS-Security with the new Microsoft.com web services.

Some of the guys at microsoft.com spent their summer working on the server-side infrastructure they need in place to support production Web service. They recently launched a prototype service that's intended to vet the plumbing. To use the service, developers have to register and get a username and password. Request messages carry a WS-Security UsernameToken containing the username and a digest based on the password, a nonce, etc.. Simon points out that, because the message is not signed, it doesn't provide any security. He's right, but that really isn't the intent. Rather, the UsernameToken is used like a cookie. It tracks invocations to gather metrics about how the services are used and to throttle requests so that servers aren't overwhelmed. The goal is to test the server plumbing and get a sense of how people use it. Google and Amazon do similar things with their public services.

So, why use a WS-Security header to do this? The service designers felt that a header would be preferable to an extra parameter on every call. A SOAP header made more sense than an HTTP header, because, long-term it is likely that messages will end up being routed on the server side for a range of operational and deployment reasons. Given that, WS-Security's UsernameToken mechanism seemed to fit the bill. They thought about requiring messages to be signed with the token to help protect against swiped tokens, modified messages, etc. They decided against signing for several reasons:

• the service is read-only
• there's no private data to protect
• requiring signing would make it much harder to build message from any toolkit that doesn't support WS-Security

From my perspective, the last issue is the most significant. It's pretty easy to layer in a UsernameToken with a password digest with a toolkit that has no knowledge of WS-Security (like this Python client). It's harder to layer in XMLDSIG support.

The people who maintain the new service's web site are working on updating the text there to make it clearer that the service is not intended to be secure. (They're also working on posting the documentation for the service online.) Beyond that, there are two other changes they could make. FIrst, they could modify the service to require a signature, thereby mitigating the issues Simon raised. However, that would make consuming the service from any non-XMLDSIG enabled toolkit essentially impossible. Alternatively, they could change the service to use some other header that people don't associate with security, e.g., . It isn't clear to me yet that either of those changes makes sense. But people here are definitely listening to your feedback!