Scott Cantor, principal editor of SAML 2.0 has sauntered up to the plate with some comments on my recent reply to Hubert Le Van Gong. He makes two main points, and I'll deal with the first of these today:
My concern is less about WS-Trust itself than about both its status as a closed document (Microsoft was very forthright at DIDW in acknowledging that the open OASIS process does not afford them an advantage in influence that their workshop process does, but that's hardly a good thing for the rest of us) and its dependence on so many other equally unfinished specs that it's very hard to evaluate it in isolation, or without an immense amount of time at one's disposal.
This discussion has many legitimate nooks and crannies on all sides, and I think it's important for everyone who cares about these things to understand everyone else's points of view. To write properly about these issues I would need to start up a second blog – which is not in the cards!
But the conversation Scott refers to was part of a dramatic session at DIDW which I thought was one of the frankest industry dialogs I've heard in years. And guess what? Phil Becker of DIDW (God bless him) has agreed to let me podcast his recording of the session… (By the way, when is Phil going to get an award? The more I learn about him, the more he amazes me.)
So here is the mp3 of Federated Standards: The State of Convergence. Don't miss these 56 minutes.
Mike Neuenschwander of the Burton Group moderates skillfuly and starts things off by getting people from the WS camp (John Shewchuk of Microsoft and Anthony Nadalin of IBM), SAML and Liberty (George Goodman of Liberty, Rob Philpott of RSA and Bill Smith of Sun) to explain how they approach standardization. This is followed by a discussion which teaches us a lot about the many issues and requirements driving the approaches of the various players. Scott Canter then makes an extended intervention from the audience where he clearly expresses the concerns he just sketches in the paragraph above. It's a good example of why people should go to DIDW – and learn from what everyone else is saying.
I'm going to allow that session to speak for itself. I respect the views of everyone who participated.
I think we all agree that this is the most important point: WS-Trust and its associated specifications are destined for standards bodies. Everyone involved is working hard to complete the workshop testing process so we can get these specifications submitted for wide discussion as soon as possible, if not sooner. These specifications, with IBM, Microsoft and many others in the software industry already behind them, are going to open up a tremendous opportunity for those, like myself, who have been laboring long and hard to make possible an inclusive, multicentered identity fabric.
In the DIDW podcast Scott says that he is “not trying to make the point that WS-Trust is invalid – because it's not”. He explains that he is trying to get people to face up to some of the attendant complexities, things that he learned in the course of developing SAML. And I for one look forward to his contribution both in vetting and hardening WS-Trust and driving identity work forward – he has been a major innovator in the identity space.
On a lighter note, Scott (who I must admit I consider a friend) sent a devilishly mischievious and libellous takeoff of my identityblog logo (the photo of an iceberg that appears in the upper right-hand corner of my blog). He admits that it:
…was perhaps not developed in such a spirit of constructive dialog, but … I hope you'll take it with a dose of humor. I'm not the author, but am happy to relay any comments. 😉
I was brought up to be able to laugh at myself – and it's a good thing, too, given some of the spots I've gotten myself into. So I admit the play on the iceberg is pretty funny. But I guess I would say though the piece makes a good parry, it would be a lot stronger if the implication of dependency on so many standards were actually true.
Why would Scott's anonymous author desecrate my beautiful (Canadian, eh?) iceberg with the names of a bunch of unrelated specifications? Actually, I remember that when I first came across the WS specifications I simply couldn't believe how many of them there were. And they seemed to be reproducing every time I turned around! It took me a while to understand the approach of factoring things into “microstandards” that could be assembled like lego. Then one day while meeting with the authors I saw that what we have here is object orientation applied to the standards themselves. Instead of big spagetti-like mainline standards, they have factored everything out for reuse, specialization and inheritence.
Anyway, the good news is that people who have time to fabricate simulacra of my iceberg have time to read the standards, so we should all get past this in time! They're sort of like the laws of identity, I suppose. Little tiny laws.
But let's get down to reality. What do you need for InfoCards beyond WS-Security and WS-Addressing, which are already widely implemented and in standards bodies? You need WS-Trust, WS-MetadataExchange, and a few lines of XML consistent with WS-Policy and WS-SecurityPolicy. This will all be made clear in the InfoCard implementor's guide, which is real close to release.
