You keep using that word

I do not think it means what you think it means… (Montoya)

Maybe I’m just cranky because I’m back to facing reality after a truly outstanding vacation in Hawaii (I might taunt you with…uh, share with you some photos eventually), but I’ve got a bone — and a few nits — to pick.

Via Phil Windley by way of Planet Identity, I just noticed some very odd invocations of the word “standard” along with other anomalies in this DevX article called Pocket This Decoder for WS-Alphabet Soup. Extra points for the cute title and concept, but points deducted, I’m afraid, for inaccuracies and general weirdness.

I realize this is supposed to be a quick reference, and one of my favorite sayings — often invoked when I give shorter talks — is “A little inaccuracy sometimes saves tons of explanation” (H.H. Munro)*. But I think a number of the points in the article go way too far down this path. Let’s start with the introduction:

The Web Services Interoperability organization (WSI) has developed a whole stable of standards upon which Web services commerce and communication can be executed securely. These standards are in great demand and many developers have already gotten their feet wet with a few of them out of sheer necessity. But it’s not been particularly easy to figure out which standard one might need to apply in various circumstances.

This implies that all of the, ahem, standards about to be discussed have been “developed” by WS-I, right? This is a common notion but utterly wrong. WS-I (note the hyphen, without which you’d land at the Washington Square Institute for Psychotherapy & Mental Health) writes interoperability profiles of existing standards and specifications (originally developed by others) and then develops testing tools and sample applications to test interop on the ground.

The PR folks involved with WS-I call this being a “standards integrator”, which is a nice turn of phrase. Having done some press work for WS-I when I chaired its Security Work Plan working group, I liked to describe its main activity as “closing gaps and choosing options”. Modern protocol specifications seem to love being “frameworks”, which means that flexibility is built right into them on purpose; choosing from among those options is critical for any level of interop for particular scenarios. And occasional gaps — underspecified bits — are inevitable, even though most standards bodies work really hard to eliminate them without going over to the side of determining implementation details.

WS-I has, so far, undertaken simple profiling of an extremely short list of standards and specifications. The Basic Profile and its related outputs deals with the very lowest-level web services infrastructure, principally focusing on SOAP, WSDL, and UDDI. The Basic Security Profile, still in draft form, principally deals with WS-Security and HTTPS.

The very nature of WS-I is to be a trailing indicator of technology adoption because there’s no sense wasting resources profiling things in flux or whose adoption curve is uncertain. So this makes the list of “standards” covered by the DevX article even more odd — since some of them don’t even exist and some of them seem to be lost in private WS-* workshop limbo. Here’s the list:

• WS-Security: Okay — but it wasn’t originally “drawn up by OASIS”; it had its roots in a proprietary spec called SOAP Security Extensions that got submitted to W3C as a Note, then got privately developed as WS-Security, then went to OASIS as WSS before changing names again.
• WS-Policy and WS-SecurityPolicy: I’d say WS-PolicyFramework and WS-PolicyAttachments are noticeably moving along the adoption curve (by contrast I still see people inventing different ways of expressing security policy) but I’m waiting impatiently for them to be contributed to a standards organization and put on some kind of completion track, since it’s been nine months since the second draft came out, and 15 months between the first and second drafts.
• WS-Trust: Yes, this is a spec that could be useful as an ingredient in many security and identity recipes, but it’s far from a standard; again, being on a completion track would help implementors sort out what to do with (which version of) it.
• WS-Privacy: Um, this one was on the original GXA roadmap but never came out. Maybe IBM’s EPAL (which seems moribund in W3C) was intended to be its successor, but I don’t think that counts. In any case, it can’t be argued to be, as the article author does in his conclusion, one of the “12 of the best-known (and most useful) standards”.
• WS-Federation: Without mention of the further interop profiling done by the original authors of this spec, I think a mention of WS-Fed is nearly meaningless. There were the Active Requestor Profile (akin to SAML/Liberty’s “back channel“) and the Passive Requestor Profile (akin to the “front channel”), with the latter getting enough attention to merit an interop workshop, which resulted in — deep breath here — the Passive Requestor Interoperability Profile. I think this latter one is where there may be some energy for the sake of universal interop (as you may recall from the recent Sun-Microsoft event), but there’s comparatively much more energy in Liberty’s Identity Federation Framework (ID-FF V1.2) and now SAML V2.0.
• WS-Authorization: Another no-show, like WS-Privacy. I suspect this one turned into WS-Trust along the way, but who knows?
• WS-Reliability and WS-ReliableMessaging: These have been essentially competing specs, with the former being on a standards track and the latter being done privately. The good news is that, as of this month, a lot of the big players on both sides seem to have come together in a single new OASIS Technical Committee called Reliable Exchange (WS-RX for short). This bodes well for having a single implementation/deployment target once the group concludes its work.
• WS-Routing: This is an interesting one, in that it did (does) exist, but was obsoleted by WS-Addressing. WS-Addressing was originally proprietary but fairly recently morphed into a set of standards-track specs in W3C (last call for comments is now closed), and is a good example of a WS-* success story.
• XML-Encryption and XML-Signature: Okay (and I very much agree with listing these).

What would I have listed, beyond the comments above? Of course I’m biased (aren’t we all?), but I think Liberty’s Identity Web Services Framework rates a mention, since it already has a V2.0 in draft form and many implementations of its previous versions have undergone rigorous interoperability testing. Quite a few companies have been finding it useful so far (do follow the link for some cool examples).

Now, I really don’t mean to be bad-temperedly picking on this article in particular. A number of similar articles have come out over the years, with similar errors. But haven’t we gotten past the point where, just because a spec or white paper has “WS-” stuck on the front, it’s a must-implement? (In fact, I wonder if this article was written many months ago and just pulled out of mothballs now; that’s certainly how it reads.) For that matter, haven’t we gotten past the point where promises to publish white papers that might someday become specs and/or standards that might become popular are treated as if they were living, breathing interoperability protocols already? Technologies need to be measured on quite a few dimensions of merit (and at least one dimension of existence!) before they’re rated as “useful”.

And you’ll have to forgive me if I reserve the word “standard” for specifications published by a standards body or consortium that is open (has a broad and inspectable definition of membership) and has documented its governance rules and development tracks. In this context, other uses seem imprecise, or at the most merely metaphorical (one or a few companies “setting the standard” for others to follow).

I think I need a mai tai…

*Or perhaps I should quote Montoya again:

Westley: Who are you? Are we enemies? Why am I on this wall? Where is Buttercup?
Inigo Montoya: Let me ‘splain. [pause] No, there is too much. Let me sum up.