Sam welcomed me back to
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...