Brett McDowall, who gave a presentation on Liberty at IIW2005, has started a blog. At IIW2005, he said "the world belongs to those who show up" and his blog is an effort to "show up" in the blogosphere.

Brett notes that there's a lot of misunderstanding about Liberty Alliance, even (or maybe especially) among the IIW2005 crowd. Some of that's FUD, but as he notes, there are technological barriers. The primary one he notes is that RESTians aren't likely to jump on board SOAP just for the privilege of using an identity infrastructure.

I was interviewed this afternoon by Laurianne McLaughlin for an article she's doing for IEEE Computer on Microsoft's InfoCard initiative. I brought up this exact argument. Developers who use .Net and Visual Studio will probably have an easy time just using InfoCard. Whether its easy for others remains to be seen. If Microsoft is truly interested in the ubiquity of InfoCard, they need to take other programming paradigms into consideration.

And this includes the REST folks. In 2006 there is still no complete SOAP library for Perl, for example. (Yes, I know all about SOAP::Lite; compared to SOAP packages for C# and Java, it's not even a dim shadow.) This isn't because Perl programmers can't figure out SOAP, it's because there's not much interest. How will Perl programmers (and I could include other languages here) talk to Liberty or InfoCard? Right now, they just won't.

When I've tried to talk to Kim Cameron about this, his answer has always been "I don't understand why people don't want to use SOAP." But that's really beside the point. The fact is that there are scads of influential and innovative programmers out there who won't use SOAP and need a path to the identity metasystem (whatever that turns out to be).

Liberty and InfoCard are currently what I'd call "heavyweight" systems designed to appeal to the heavyweight software development process. No surprise considering where they were born. But that's not the only way to develop software and indeed much of the really interesting stuff these days is being turned out in more lightweight languages, frameworks, and processes. Achieving the ubiquity, or a close approximation, necessary to make this all worthwhile isn't going to happen unless the systems reach out to the developers in these paradigms as well. It would be a shame if myopia about "the one way" of developing software scuttled the identity metasystem.

Update: AS I was thinking about this later, I realized that another way of expressing this is to say that the identity metasystem should be transport neutral. SOAP proponents would argue that that's exactly what SOAP is. That's true: SOAP builds an abstract transport layer on top of HTTP, MOM, and most everything else. What I'm arguing is that we need neutrality up and down the stack as well. I shouldn't have to buy off on a particular transport abstraction to use the identity system metasystem.