Phil Windley has started a very fascinating thread in response to my piece on WS-Policy. Since a number of people have found it helpful I've decided to go through the other microstandards necessary for InfoCards and do a similar “identity person's summary”. Clearly I will forgive those who don't find protocols as interesting as I do – just skip on by.
Anyway, back to the point… Phil's posting:
Kim Cameron has a very cogent piece on WS-Policy. In fact, read it and forget the standard. Everything you need to know is in Kim’s description. This was timely because I’ve been considering my article at Between the Lines on a RESTful alternative (or augmentation perhaps) to the InfoCard proposal, something that was sparked by some questions from Doc. As I read Kim’s description, I realized that there really no need to redo WS-Policy for REST—it can be used as is.
One way to think about the RESTian argument is to separate out those parts of the WS stack that are about transport and those that are not. SOAP, WSDL, UDDI, WS-MEX, WS-ReliableMessaging, and so on are about defining transport for XML documents. This is especially apparent when you consider the Doc Literal style of using SOAP. The goal is to define an HTTP-independent way of transporting XML documents around in order to define services. The other standards are ways of declaring meta information about the service.
The REST folks argue “why replace HTTP?” Just forget SOAP and use HTTP instead. There’s some real meat to this argument. In particular, RESTful services seem to be easier to use. My point, however, is not to convince you to use REST or SOAP, but to convince you that these are just two different ways of transporting XML documents around.
What the RESTians have not done, however, is to define solutions to the very problems that most of the WS-* stack addresses. I believe we need to come up with equivalent alternatives in the REST world for things like WS-MEX or WSDL—all the transport related stuff. We don’t, however, need to replace the XML documents and the security and policy declarations that accompany them.
Things like WS-Policy and WS-Security could just as easily be used with RESTful services as they could with SOAP-based services. Sure, we’d need some conventions to pass the reference for the declaration in the message header so that it accompanies the XML document and maybe a few other things, but I think it’s workable. If you read through Kim’s description of WS-Policy, you’ll see that the issues it solves and the ways it does so would work very well in a RESTful service.
I'm going to send this link to Don Box and see what he has to say about it. He has thought about these more general issues a lot more than I have. I'm really just an identity person looking for a way to build a metasystem that will encompass many security and privacy technolgies, allowing us to build a unified fabric rather than a patchwork solution.