Out Of The Frying Pan and Eating the Cake

Don Box says :

"Personally, my dream stack would be ubiquitous WS-Security/WS-Trust over HTTP GET and POST and tossing out WSDL in favor of doing direct XML programming against payloads from VB9 (or XQuery), but hey, I have unusual tastes."

In response Sam Ruby posts Out Of the Frying Pan. I've read it first time and thought, hmm..., I'm not getting it. Lets try few more times while focusing on the text Sam highlighted. Still my brain does not help me. Apparently, it was not only me who found a text to be a bit difficult to grasp so to say :-)

Ok, so I've tried to see what others are saying, may be they'll help to understand.

From Dare Obasanjo who keeps banging nails into the WS-* coffin (or WS-* vs REST discussion?) :-), I've found about OAuth. So little time so much to learn. Some knowledgeable people say OAuth may be incomplete yet and I'm wondering will it do well beyond web applications and social web-networks ? I need to learn this stuff. Anyway, I've seen him commenting on the vested interests of various web properties, it's getting closer but what is it that Sam was trying to say about WS-Security ?

Now, I'm seeing "Having one's cake and eating it too" from Don Box. These guys can understand each other from half a word :-). Following their exchange :

Sam : "Out of the box, exactly what security mechanisms does WS-Security provide? "

Don : "Without a mechanism for getting a token, not much. I typically think of WS-Security and WS-Trust as a unit, but you are correct, they are distinct. "

Sam : "Using only those two specs, what "ValueType" does one use for Kerberos? X509?"

Hmm... I think I'm nearly getting it now, but not quite. Dan's post comes to the rescue, or comments to be precise :

Sam Ruby : "Executive summary: Don’s criticism is that HTTP amounts to little more than a pluggable framework for incompatible authentication schemes. His proposed replacement? A pluggable framework for incompatible authentication schemes."

Here we go. It's brilliant. That's why I like the blogosphere. One day you can get something like :

"Guess what ? Web Services are like CORBA and half of your web services projects will fail". Do you really want to talk about it ?

The next day one can get something really interesting. I feel I've just learnt more about WS-Security and WS-Trust than I thought I'd known before.

And here's my 2c answer to Sam's question :

It's spot on that WS-Security is really a pluggable framework for incompatible authentication schemes. It's however the "framework" which makes a difference, at least for a time being. It makes it easier to deal with Kerberos and X509 by dictating that all goes into soap headers. This and the fact that some services to be secured are coarse-grained. No problems with security departments ignoring the interop concerns :-) It can make it easier to do a product-level support for doing advanced web services security. And WS-Policy can make it easy to consume WS-Security expressions.

Have I missed the subtle point of Sam's question ? may be, but it was fun trying :-)

Dan asks :

"Maybe the question we need to ask is how do we do WS-SX related stuff over Just HTTP"

How about :

atom:feed/atom:headers/ :-) ?