Slightly updated May 18

If you Google Microsoft’s InfoCard, you mostly seem to find people asking "who can tell me more about InfoCard", but very little actual answers. Here is what I’ve learned from public statements by Kim Cameron and other Microsoft people, and the public demo they did at Digital Identity World 2005. (Disclaimer: I may be wrong about some things, as I don’t work for Microsoft. Also, I believe all of the information here is public. If I’m wrong on either count, please do let me know.)

To understand InfoCard, you need to understand Kim Cameron, InfoCard’s architect. Kim is credited with being the, or at least one of the inventors of the concept of a meta-directory. A directory (as in corporate directory, LDAP, that kind of thing) is a special kind of database run by companies to manage information about their employees, such as their names, phone numbers, e-mail addresses, office locations, as well as computers, printers and sometimes access permissions to various applications or information. When companies started to deploy directories, very quickly multiple directories were found within the same company, and the question arose how those directories could be used together, because some directories would know information about some employees but not others, etc. The idea of a meta-directory is to have a piece of software that would appear just like any other directory, but that would pull its data from other directories. In other words: have your cake and eat it, too. Keep whatever directories you have, but make all their information appear in one place (coincidentally one of the core principles behind our NetMesh InfoGrid as well).

So when Kim decided to do something about digital identity, he used the same mindset that he used for the idea of a meta-directory, because he saw the same market conditions in this area: lots of incompatible digital identity systems, that prevent everybody from interacting with most other people — just like stovepipe directory systems would prevent one person from accessing a printer defined in another. In the identity space, not only do we have Microsoft Passport, Liberty Alliance, SXIP, Identity Commons, and our LID, but thousands, or maybe far more, home-grown account and user registration systems. In Kim’s view, while there may be advantages that one of those systems has versus others, the real problem is fragmentation of digital identity systems, just like fragmentation of directory systems back then. So the core idea for InfoCard is to be a meta-identity system, with the word "meta" meaning the same thing as it does in the term meta-directory system.

Another way saying the same thing would be by parallel with TCP/IP as the universal abstraction layer that abstracts away from things like Ethernet, but nevertheless depends on them. Using this analogy, we could think of InfoCard just like we do about TCP/IP (in relation to digital identity systems and Ethernet or WiFi, respectively).

Kim’s hope that by having such an abstraction layer, such a big momma identity backplane (as Marc Canter puts it so memorably), we can get an explosion of identity-enabled new applications. And he adds another analogy: there was little innovation in graphics before there were commons APIs that developers could use to talk to any graphics card, but then it exploded, we got graphical user interfaces and all of that. Without that common API, the next level of innovation simply wasn’t possible. He thinks that it will be the same about identity.

Before we get into the guts, let’s list some more of the assumptions behind Infocard: (you should also read Kim’s Laws of Identity which I won’t cover here but which contain a lot more interesting assumptions)

• 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.
• InfoCard is built entirely on the web services (WS-*) stack. Given that it is a very distributed system, this choice is understandable. Kim says that while not all WS technologies used in InfoCard have been blessed yet by suitable standards bodies, all of them are on the standards track already.
• Because of the need to combat phishing and other attacks where outside stuff (web pages, viruses popping up application windows etc.) pretends to be something else to the user, InfoCard will be anchored pretty deeply inside the Windows OS in a secure process space.
• The InfoCard — like a virtual credit card or membership card — metaphor is the central user interface metaphor.
• InfoCard only defines the "framework" protocols between the InfoCard client-piece (the one inside Windows), an identity provider, and a relying party (e.g. a website that requires identifying information). Lots of parties can be an identity provider or a relying party using many (all?) of today’s identity systems which can plug into the InfoCard system by adding actual content into the defined messages.

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
• SAML
• WS-Federation (unclear)

Does this make sense do you? It does to me … Feel free to post back or contact me if I’m wrong or incomplete or you have questions or …