Sam welcomed me back to the blogosphere...

Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com's services as an example to emulate, so they try to make sure they do the right thing. In this case, there's a been a lot of confusion around the fact that WS-Security really offers levels of protection and, in this case, the level required is pretty low. That said, the guys who built the service are working on the details for replay detection. I'll keep you posted as I find out more...

In the same thread, Dare commented that the use of WS-Security in this context doesn't make sense to him and that a token like the one used in the Google service makes more sense to him. The problem with adding a token to every operation is that it goes in the body of the message. Since the goal in microsoft.com's case is to consume the token at a router that then passes the message on, it needs to be in a header so as to avoid violating the SOAP processing rules. Once you're using a header, you've got more code to write in any case. Given that, why not use an existing header that identifies users? I think it would have been more confusing if they'd made up some new header of their own...