Julian Bond of voidstar has posted a piece called, rather uncharitably, “Why InfoCard will fall at the first fence.” I'll just make a few comments to make it clear where he understands our plans and where he doesn't.
He says:
- User end requires Longhorn or an XP upgrade
- Depends on SOAP and the WS protocol stack
- Uses HTML OBJECT tag wth DLL support
- Multiple commercial licensing but with probably no open, free, license.
Since the InfoCard identity selector runs in a protected subsystem to offer significant security advantages, it does require new code. Isn't it about time we had new code and a new approach? And can't Julian see anything positive in Microsoft making an initiative here, and using its ability to distribute this code so as to contribute to the construction of a rigorous identity fabric? Further, I would think he might commend the fact that these capabilities are being made available down-level, and will be distributed very efficiently. The result is that the proportion of clients which will be InfoCard equipped will climb very quickly. This doesn't mean that they automatically capture the imagination of users. But it certainly represents a great opportunity to help move the whole industry forward. I don't understand the factionalism in this regard.
InfoCard does depend on SOAP and WS. But creating an interoperating stack is not difficult. People on non-windows clients will have open source implementations available to them. Such implementations are being built today (some exist). Why does Julian want to walk away from such an opportunity?
Again I will say that the IP will be available in a royalty-free license. We are working on using an existing license that is well accepted by the vast majority of people building software today.
Julian goes on to say:
So that counts out Apple and Linux clients. It may well count out Firefox and other browsers. It almost certainly counts out PHP-Apache websites. Java/Perl server environments probably won't work because interop between MS implementations of the WS stack with Java/Perl implementations is extremely patchy.
Untrue. The open source implementations will run on those clients. And we would urge people to build clients to work with us to ensure interoperability. These are still the early days of the stack! Of course the interoperation is patchy! In the early days of LDAP we couldn't even agree on what to call an email address! Julian's comments here strike me as a bit mean-spirited. But Julian continues:
So >50% of the market is excluded. And *all* of the long tail of small and medium sized web sites. Which is exactly the same problem as with Passport. It ends up as an IE only, MS Windows only, client tied to a server system that only works with the very biggest players. And each one of them involves a huge sell with the corresponding bad press when they back out.
I guess if people follow Julian's advice in lockstep he may achieve this. But on the other hand, someone who wants to do something positive for identity might use the open source stacks to put together a Security Token Service (STS) that just plugs into apache and handles identity management for that long tail. It all depends on whether we want to take advantage of an opportunity that I see as historic.
Julian concludes:
What's sad about this is that Microsoft cannot separate the standards process from it's commercial business. It's completely unable to take a view that a larger market raises all boats. So I'm not at all surprised at the approach and I also predict loads of noise and very little implementation leading to another failure. I think the rest of us can safely ignore what they're doing. While at the same time borrowing from all the excellent work that people like Kim Cameron are doing on the fundamental analysis of Identity.
I wonder, in this case, if it is Microsoft who can't separate the standards from the opportunity, or Julian himself.
I just don't get Julian's vibrations. We thought long and hard about how to make the client tremendously open to a plurality of identity technologies and operators. We've put it out there. It doesn't require anyone to lay down their existing protocols – use whatever works for interacting with conventional clients. But let's give the end user a better, safer and more comprehensible mechanism for taking control of her identity.
In this, Julian, why not work with us? The laws are not abstract things. This is the time when we need to change the Internet so it comes into accord with them. Not every aspect of these proposals may be exactly as you would wish. But please consider the great complexity of “weaving” a solution here, garnering support across all the consitutencies, and consider again why you would walk away from this opportunity.
