Over at the IT Garage, Doc Searls goes through some history of Microsoft's InfoCard initiative and asks some good questions. InfoCard is an identity metasystem that Doc correctly describes as a "barn raising project" led by Microsoft. Kim Cameron, Microsoft's chief identity architect, believes that Microsoft has an important role to play in enabling identity, rather than seeing it as a revenue center. That's a good start and Kim has played the politics (both inside and outside of Microsoft) well with his seven laws of digital identity.
InfoCard is based on Web services. No surprise there--Microsoft has been a consistent proponent of Web services (at least for everyone else) and some of the standards provide the exact behavior that the identity metasystem needs. Most important among those are SOAP, WS-Security, WS-Policy, and WS-Trust (along with attendant standards). While Microsoft intends to build and offer all of the required components--including the Longhorn embedded client (called a "selector"), the identity provider (IP), and relying party (RP) pieces--the architecture is open and others, including open source projects, will be able to build interoperable components as well.
Doc asks two questions. The first: Does the metasystem require adoption of SOAP and the whole WS-* suite of protocols (or whatever those are) ... or something much less than that? The second: What will it take to get open source developers, and the rest of the non-Microsoft world, to adopt and deploy stuff that works within the metasystem?
The first question is easier to answer than the second, since I'm not sure anyone really knows what it takes to get a community to form around an idea in open source land. Even so, I'm convinced that if Microsoft does what they say they will, the open source community will build components if for no other reason than the fact that they will have to to participate in the identity environment that will grow up around the standard Microsoft creates.
But does this require SOAP and the WS-* stack? Is there a RESTful equivalent? Not as currently constituted, as far as I can tell, but that doesn't mean their couldn't be one in the future. The problem is that things like WS-Policy and WS-Trust aren't just things people did because they were bored, there are real issues surrounding things like how you tell someone what security tokens you accept and how to exchange the token you have for one that will work. There's no RESTful equivalent. REST is almost defined by not having these kinds of standards and yet, without them, we're left to invent 20 different ways of stating metadata about a service and hoping that the market can sort it out.
I've done my share of throwing rocks at the seemingly unending proliferation of WS-* standards, but let's face it, sometimes you need things like that. For example, I think the development of RESTful intermediaries has been significantly hampered because there's no standard for service description.
I don't think all is lost, however. I believe that in the sense of Doc's barn-raising, there's a chance for the community that cares about digital identity and RESTful Web services to define an alternate REST-based interface to InfoCard and build it into their own versions of the IP and RP services. These services would have to support the WS stack interface as well. Using RESTful interfaces for these tasks should be feasible, but I haven't looked at the possibility in great detail.
Whether such an interface could survive and thrive would depend on many factors, not the least of which is whether an open source (or at least alternately sourced) version of the IP and RP services were widely adopted. Given the popularity of Amazon's RESTful service over its SOAP-based service, I think there's real hope that developers would take to it and build identity selectors that make use of it.