Kim Cameron's Identity Weblog :
Kim believes that it has to be an entirely open system. My understanding is that Microsoft will find a license (I also understand they have not settled on one, in fact Kim is looking for input), that allows anybody to create any part or all of InfoCard themselves. Unlike some earlier rumors, InfoCard does not seem to be released as open source itself, but admittedly, that would really have surprised me.
Here is an example use case:
1. An InfoCard-enabled user (e.g. one running the upcoming Windows Longhorn, or the downward-compatible release for XP) first signs up with one or more identity providers of their choice. That could be their ISP, their bank, a site like eBay, or Slashdot. This process is entirely outside of InfoCard, but of course the identity provider must support their part of the InfoCard protocol.
2. The user visits an InfoCard-enabled relying website (such as an InfoCard-enabled Amazon) that requires certain identity information from the user, say, a shipping address. The website sends a web page which contains an HTML OBJECT tag, which triggers a DLL which invokes the InfoCard system.
3. The InfoCard system determines which personal information is requested by the website, and matches it to the identities (i.e. InfoCards) that are in possession of the user. It then displays those InfoCards to the user that are applicable, such as: driver's license (if the government was an InfoCard-enabled identity provider), or credit card from AMEX. Note that the InfoCard selector runs natively on the PC and is not downloaded.
4. The user selects an InfoCard to use. The dialog shown takes over the entire Windows screen (similar to the Windows login / logout dialogs today) in order to reduce phishing. It would also be difficult for an attacked to bring up a screen that has the exact set of InfoCard pictures on it as the user owns, as the information about which cards the user has is stored securely in a secure area of Windows. As a result of the selection, the InfoCard process on the PC contacts the selected identity provider, and obtains essentially a signed XML document that contains the requested identity information. The signature comes from the identity provider.
5. The InfoCard PC piece then forwards the obtained document to the relying party (the website).
6. However, InfoCard does not describe the actual tokens flying around, thereby enabling other identity systems to plug in.
In order to accomplish this, InfoCard employs:
* SOAP
* WS-Addressing
* WS-MetadataExchange
* WS-Policy
* WS-Security
* WS-SecurityPolicy
* WS-Transfer
* WS-Trust
* XML Signature
* XML Encryption
So:
- 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.
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.
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.
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.
|
, Microsoft 