This happens over and over. New WS-* spec submission, check. Insanely huge charter locking down the conclusion and ensuring a rubber-stamp outcome, check. Loads of dependencies on WS-standards, WS-drafts, WS-submissions, and other WS-handwaving, check. Resolute obliviousness to other technologies that address the same problem, check. [Update: Hostilities break out in the comments. Read ’em and see what you think.]
The IETF standards process may not be perfect, but compared to the noxious fumes emitted by the recent politics in progress at OASIS and ECMA and ISO (see Simon’s last link here), it smells pretty sweet to me these days.
[Update:] I quote from Eve Maler: “The telecon was held this morning. TC convener Paul Cotton responded to the collected comments by reading from a prepared text that gave the same answer 30 times: ‘Proposed response: no changes to the WSFED TC charter are required.’” Feeling cynical and paranoid yet?
If, instead of my reflexive grousing, you’d like to read some actual educated commentary by people who know the territory, you’ll probably enjoy the input from Nokia, France Telecom, NTT, Sun, and Oracle (twice!).
Contributions
Comment feed for ongoing:
From: Steve Loughran (Apr 03 2007, at 02:56)
...But on a positive note, OASIS did announce the end of the WS-ResourceFramework TC. "With WSRF v1.2, the work of the WSRF TC is complete."
http://lists.ebxml.org/archives/tc-announce/200704/msg00004.html
[link]
From: Nico (Apr 03 2007, at 11:17)
Yup. Quite a while back I made a number of comments on the WS-Security TC's Kerberos V Token Profile drafts. I only ever got answers to the easy questions; I never got answers to the hard ones. I asked twice too. Are we supposed to give up?
[link]
From: Assaf (Apr 03 2007, at 18:31)
Hopefully, Sun and other vendors will vote with their feet on this one. It's hard to resist yet-another-WS-checkbox on the product brochure, especially something that pretends to be an industry standard. But in the long run, your customers will appreciate it.
[link]
From: Nico (Apr 05 2007, at 09:34)
That charter is unreadable. "Insanely huge" seems insufficient to describe its length (or maybe that's just because every adjective in the English language is applied figuratively nowadays, literally :) That's just not a serious charter. Reviewing it is like reviewing a large specification: it takes time to read it in context (e.g., following references as needed), to understand it, to analyze it and to find what's missing/broken, except that, being a charter, it lacks references. Ugh.
[link]
From: Mike Champion (Apr 05 2007, at 22:10)
Hmmm, I'd phrase those points slightly differently :-)
Standardizing technology known to work and interoperate rather than starting with a mess of inconsistent inputs and an unconstrained charter? Check.
Composing existing standards rather than building a special-purpose silo? Check.
Leveraging (via WS-Trust) proven bits of other technologies (e.g SAML tokens) that address parts of the same problem? Check.
The WS workshop process http://msdn2.microsoft.com/en-us/library/ms996518.aspx may not be perfect, but seems to be better at producing interoperable specs than the design-by-committee process that led to so many of the standards that took years to produce and longer to truly interoperate.
[link]
From: Rick Jelliffe (Apr 08 2007, at 00:40)
Tim: Simon Phipp's comment that you quote is pretty ignorant w.r.t. ISO. What noxious fumes are you talking about? MS cannot "stack" SC34 to get a vote, because SC34 does not vote on OpenXML. And Simon (and your) evidence for this stacking was Alex Brown's comments about WG1, which certainly has no vote...indeed, OpenXML maintenance was not even on the agenda.
The WG1 committee which has individual member doesn't vote on OpenXML, though will have some kind of limited maintenance/liason role if OpenXML passes as a standard after February 2008. SC34 doesn't have individual voting, but again was not voting on any OpenXML-related issues AFAIK. An MS (or Sun) person cannot automatically get on a national body delegation for SC34, they have to be accredited by the particular mechanism of each national body.
WG1 and SC34 have strict rules requiring that agendas and study material are distributed weeks in advance to allow review by people with non-English first languages: technical material is not necessarily easier to read than literature. Any standards body that does not have such a rule betrays their lack of seriousness or understanding of international participation: actually, of course, other standards bodies are not organized in such a way to recognize that different nations (with different cultural practises, languages, time zones, etc) exist. Some W3C specs (notably XSD) adopted a limited vocabulary principle, which may have helped if accompanied by some kind of phrase-count limit.
Even ISO does not go far enough in its editorial guidelines. Most standards bodies have rules for particular words that have different regional interpretations (in particular, shall, must, may, should) but these are still inadequate. One editorial rule that standards should implement is Fujitsu's old rule to ban the word "it" and particular "its", which is a magnet for ambiguity in technical specifications and tedious complexification for East Asian readers.
[link]
From: David Carver (Apr 08 2007, at 07:49)
...Michael is right. What needs to change is the methodology that the committees use. But I also think, that in many cases, the WS-* has started making it too complicated, when "good enough" gets the job done.
[link]
From: Paul (Apr 08 2007, at 08:35)
Microsoft is sending a 'response' to your WS-Fed charter comments: Accept or Deny?
Deny.
[link]
From: Eve M. (Apr 08 2007, at 20:37)
Hi Mike-- I understand that you're presenting the theory of the WS-* workshop process, and you present it faithfully. I don't mean to be picking on you. But the facts don't support WS-Federation being a superior solution on these grounds.
SAML's first version was built in a "messy" open standards forum by a large, knowledgeable community (which included both vendors and users) in record time. It was approved as an OASIS standard in Nov 2002, before WS-Federation was even published (Jul 2003). SAML V1.0 made important early usage -- it was highly debated at the time! -- of SOAP for the cases where server-to-server identity communications were desirable. SAML then cycled to V1.1 in 2003 to capture important lessons learned about the still-new XML Signature. And V2 was explicitly about a grand convergence, in which an expanded community took active part. That took only another 18 months.
Likewise, Liberty Web Services was, as far as I know, the first adopter and profiler of the OASIS WS-Security standard and its SAML Token Profile anywhere, offering the first truly interoperable design patterns for identity-enabled web service messaging in late 2003. The WS-Security profiling in ID-WSF V2.0 is even more sophisticated, and it even adds support for WS-Addressing (now a W3C Rec).
SAML was publicly tested in interop labs at RSA 2004 and 2005. In the meantime, Liberty began running conformance and interoperability certification tests in 2003, and when SAML2 became the Liberty Federation standard of record, Liberty began formally testing it too. Dozens of identity-related products, including some open-source implementations, have been certified Liberty Interoperable, including products from all of the identity vendors who appeared as WS-Fed TC co-proposers (except one).
SAML seems to be the reference technology of choice for the public sector, which has interesting requirements around stability, quality, security, privacy, open standardization, and vendor choice. And check out the adoption info on the Liberty site -- there are 15 verticals represented.
By contrast, WS-Federation has been late to the party, has seemed to copy functionality from other specs that were already done, and was developed by a select committee of vendors. There are some good ideas in it, but it's awfully hard to get past the artificial all-or-nothingness of the spec, its dependencies, and its planned standards track to use those good ideas.
Summing up: Are SAML and ID-WSF "[s]tandardizing technology known to work and interoperate"? Yep.
Are they "[c]omposing existing standards rather than building a special-purpose silo?" I'd say yes.
Are they "[l]everaging ... proven bits of other technologies (e.g SAML tokens) that address parts of the same problem?" Definitely. Regarding the "(via WS-Trust)" part I elided: I'm willing to believe that WS-Trust's unique value can be proven (my company even offers support for it in service of better .NET interop). But SAML and Liberty have so far managed to define plenty of web service protocols for issuing and exchanging tokens that -- I don't mean to shock you :-) -- don't currently use RST and RSTR. (If only WS-Trust were put on a standards track when it was first privately published, in Dec 2002, things might have been different! And if you want to bring, say, a WS-Trust binding to the SSTC table, I'll even offer to help.)
So, summing up, I would dispute that the WS-* workshop process "seems to be better at producing interoperable specs than the design-by-committee process that led to so many of the standards that took years to produce and longer to truly interoperate".
[link]
From: Mike Champion (Apr 08 2007, at 22:53)
Hi Eve. I hope someone who is knowledgeable at MS or one of the other WS-Federation proposers responds to the points raised here, in your blog, and in the others you link to, but I definitely don't know enough to do so in any depty. XSD, not SAML, is my shining bad example of a design by committee spec that the WS workshop process (and other "invent first, then verify interoperability, standardize later" approaches) can help avoid. My point in replying to Tim's "bracing commentary" was to push back on the implication ("Insanely huge charter locking down the conclusion and ensuring a rubber-stamp outcome") that the process here is somehow broken. What I see happening is a) front-loading the hard work and b) asking a standards body to debug rather than invent a spec.
It was definitely not my intention to demean the process that created the SAML specs or cast doubt on its interoperability FOR ITS TARGET SCENARIOS. The question is whether those target scenarios cover the full range of emerging federated identity scenarios. As best I understand it, SAML 2.0 addresses today's "passive" browser single signon scenarios, but doesn't integrate well into the WS-* infrastructure for "active" enterprise application scenarios. So, a (actually rather good-sized) group of vendors set out to address the problem and extend WS-Trust to support more of the necessary functionality in a single spec with "active" and "passive" flavors.
Likewise, I don't understand the point about WS-Trust/WS-Federation being "late to the party" -- it leverages functionality from SAML (and Kerberos, etc), recasts it to fit into the web services infrastructure that has been built up over the last 5 years or so, and provides services that can be used "passively" by browsers and "actively" by enterprise apps.
I'm just not smelling any toxic fumes here.
[link]
From: John Kemp (Apr 09 2007, at 06:35)
As an implementer of Liberty ID-WSF, SAML and WS-* specs, I'd have to say that all of them bring some value in interoperability and functionality.
I'm sure there's some value in WS-Fed too.
But both WS-Fed Active and Passive profiles are to some extent duplicating functionality already available in SAML 2 and Liberty ID-WSF. From reading both specifications, that's clear to me.
The WS-Fed charter doesn't leave any room for convergence of existing work (SAML 2, Liberty ID-WSF) with anything that has been done in WS-Fed. That seems like a shame for the market.
[link]
From: Alex Brown (Apr 09 2007, at 09:05)
wrt the "noxious fumes" coming out of ISO ...
As the source of Simon Phipps's comment about MS "stacking" the OOXML vote, I would first like to second Rick's comments about the wrong-headedness of the suggestion that somehow this influx of MS-employed members will ensure the "OOXML vote is a landslide", in that it was made very plain to everyone attending the SC34 meetings in Oslo that OOXML was just not up for discussion: and so it wasn't.
Anybody who attending that 3-day meeting hoping to discuss OOXML and/or ODF will instead have had the experience (more interesting IMO) of discussing revisions to NVDL and Schematron, while carrying-out line by line scrutiny of some new up-coming standards: DSRL, CRDL and DTLL (see http://dsdl.org/ for more).
I might also have mentioned that MS is not the only large corporate to have had employees attend ISO meetings of late (just that this particular meeting was notable for it). We've had the pleasure of having Sun and IBM staff in attendance at recent meetings also.
[link]