Many people (e.g. Doc Searls, Julian Bond, Dave Kearns) have pointed out to me that InfoCard isn’t the Identity Metasystem and won’t become it in the future either, since my post on Monday, and they are of course right. InfoCard, at the most, will be a component of such an Identity Metasystem, and there will be many others along the lines of Julian’s ASCII chart.

However:

1. Even if it is wrong, lots of people are talking about InfoCard as "being", rather than "being part of" the identity metasystem. Just one example: in an article by ASPnews.com, Jim Wagner writes:

InfoCard is an identity meta-system that will initially incorporate everything from user names and passwords to smart cards to X.509 certificates, as well as new technologies created through the Liberty Alliance and other technology groups.

The remainder of the article is consistent with that interpretation, and you will find other articles that state it incorrectly as well. So if Microsoft indeed does not intend to position InfoCard as the identity metasystem, and I simply believe you guys who told me so, articles like the one I’ve quoted should call for some rapid spin doctoring to make sure the press, and everybody outside of identity circles doesn’t expect something that simply won’t be?

2. But even if we define the future identity metasystem as "whatever will have emerged once we have plugged all of our technologies into it and made it interoperable" (note: by definition, that would mean there will only be one identity metasystem, ever, at most. Competing with it would be a logical impossibility because by definition it would have to include everything else), it raises an entirely different set of questions:

• Who will define, and evolve, the core protocols at the heart of such interoperability? I didn’t mean to say in my original post that the "Infocard code" will be the identity meta-system, but I did mean to imply that the interfaces selected and defined by Microsoft as part of the work on InfoCard seem to be intended to govern the identity metasystem, even if it turned out that InfoCard as a product only played a small role in the overall metasystem.

  Based on my understanding of InfoCard at this point, and while it uses and reuses many existing multi-vendor protocols (e.g. WS-*), there is also a substantial amount of conventions and "profiles" (e.g. ways of using, such as the interaction between browser and identity selector aka InfoCard) and data elements (e.g. how to actually exchange VCard-like information) that have been defined by Microsoft and are currently not part of any standards track anywhere.

• It is not a logical necessity that the identity metasystem will be built on the WS-* stack. Because taking the above to its logical conclusion, the InfoCard interfaces would thus only be a proposal for, rather than "define" the interfaces of the eventual identity metasystem.

  As we see from the many good arguments in an ongoing discussion now mostly between Julian Bond and Scott Cantor (can’t find a home page for him), there are many good questions that one can raise whether the identity metasystem should be built on WS-* at all, or even on XML. For example, as I think we demonstrated with LID, there’s a lot of neat stuff one can do using a REST model, and I agree with Phil Windley that it might be worth exploring REST for the identity metasystem as well.

So how are we all going to build the identity metasystem given this? There seem to be lots of open questions … But today’s good news for me is that we have resolved at least one: InfoCard isn’t the identity metasystem!

Microsoft InfoCard is frequently described as an "Identity Meta-System" (as opposed to, say, Microsoft Passport, which is/was a plain identity system and not a meta-system). This term seems to have beek picked up widely, but like some others (e.g. Doc Searls), the longer I think about it, the more I realize that I have a number of open questions about it …

The first and most important: "meta" to what?

I think I’ve heard two answers to this question so far:

• It’s "meta" because multiple identity providers (say, American Express, the government of Zamunda and the boy scouts) can all be identity providers, independent of each other, and all the provided identities are —technically at least— equivalent to each other.

  This contrasts with, say, Microsoft Passport, because within Passport, only Microsoft could be the identity provider, leaving American Express, Zamunda and the boy scouts unable to participate.

• It’s "meta" because multiple identity technologies (say, SXIP, Identity Commons and LID) can all function within it: just like American Express, Zamunda and the boy scouts can be equal participants as identity providers, these projects could be equal participants as technology providers.

  This would contrast with, say, Liberty, because Liberty requires everybody to "talk Liberty" web services while InfoCard does not require that kind of thing … oops, doesn’t it?

This is where I’m having trouble. The first point — multiple identity providers can plug into the same framework on an equal footing — is quite straightforward, and it’s not very hard to build such a system at all. In our very own LID, every owner of an identity is their own identity provider, so if we took the first point as the definition of an "identity meta-system", LID most clearly would be such an "identity meta-system". In fact, it would be the most "meta" of all identity meta-systems because it takes this idea to its logical extreme and makes everybody their own identity provider. So I figure if people say that InfoCard is a meta-system and LID is not, the core idea about the "identity meta-system" must somehow be about the second point.

But: my problem is that I don’t see the "meta"-ness of InfoCard in this second respect. If Dick Hardt (of SXIP), for example, and we (with LID), both plugged into InfoCard, would InfoCard enable our respective technologies to interoperate so seamlessly that users think, for example, that they are using their LID to log into a website, but actually use SXIP because the website was SXIP-enabled?

I guess I must be missing something here … (please help me along if you can …) I do understand that if we built a LID-to-InfoCard "converter" and if Dick built a "SXIP-to-InfoCard" converter (assuming for a second that this would be straightforward), the user could use either their SXIP identity or their LID to log into an InfoCard-enabled website. But that does not sounds like a "meta-system" to me: that’s plainly a one-to-one mapping from two existing identity systems into a third, which would be InfoCard. Of course there’s nothing wrong with such mappings, we do them all the time, it’s just that this would imply a peer relationship between InfoCard technologies and other identity technologies, rather than one of "meta" or "backplane".

Given this, I currently think this is where the parallels of InfoCard with TCP/IP fall down. TCP/IP is a meta-protocol because it requires underlying protocols, and without those, it would be nothing. For example, you can’t run TCP/IP over Ethernet without running it on the Ethernet protocols. You can’t run TCP/IP over dialup without the V.32 and V.90 and whatever modem protocols. Same for WiFi etc. TCP/IP provides a common abstraction so I can connect to a remote server, for example, using a chain of underlying protocols from WiFi (laptop to base station) via dial-up (base station to ISP, for example) to Ethernet (ISP to website). But without Ethernet, modem protocols, WiFi protocols etc., TCP/IP by itself can’t connect anything to anything.

But InfoCard does not work that way: it’s an identity system in its own right which can very well run without the equivalent of lower-level protocols. In fact, from what I see, it does not seem to have facilities at all that allow me to use other identity protocols within it, so that I could, for example, run part of my identity interaction with a website via REST, instead of WS-* (like I can run the first leg of the TCP/IP connection to a website over a modem if I so choose). But if InfoCard doesn’t allow me that (or am I wrong on that point?), where’s the "meta" part?

It’s only Monday morning, and I’m already really puzzled …

[Previous installment here.]

Timothy Grayson hits the nail on (my?) head when he says:

Your appropriately more earnest question is, I think, “Why are we splashing around in the shallows of an institutionally-framed, banal discussion about security, costs, and efficiency rather than rising to a visionary one focused on the power for d-ID to have a transformational effect on humans and society as we know it?” (My apologies for the hyperbole.)

While this is indeed a quite melodramatic version of the question I want to pose, it is what I’m interested in here (and, as far as I can tell from various recent discussions, most people in identity land are interested in). By the way, does anybody have numbers for what cost savings and efficiency gains are supposed to be if one deploys, say, Liberty?

He goes on to say that he does not see digital identity technologies per se as being able to have a true transformational impact on society, and — which may come as a surprise to those who don’t know me well — I do agree. In my mind, what’s needed to have a true transformational impact includes digital identity as a core component but is only one of several pieces. I.e. we need to get it right, which is the reason why I got involved into this discussion in the first place, and why I think we all need to constantly ask the Kool-Aid question. Nothing would be worse (for those who see digital identity as the end, and those like me who see it as a piece for something larger) than to believe our own press releases and vision statements too readily, to create huge expectations, and then not to be able to deliver really meaningful results. I’m asking: what results do we want to deliver, and why do those matter?

Dave Kearns, in commenting on Shelley Power’s response to my Why Digital Identity Matters piece, makes the very good observation that there is a difference between "identify" and "identity". I’d like to add that many proponents of digital identity technology non-withstanding, many application scenarios indeed require just identification, without particularly the broad definition of digital identity ("all information that relates to me").

Andre Durand, of Ping Identity, narrows the discussion to "10 Reasons why InfoCard Matters" (although his list then only contains 7). He sees its benefits in better security (less Phishing, eliminates need to manage weak passworts) and higher user convenience (form-fill, SSO).

I guess I’d have to accept it if digital identity technology turned out to not take us any further than that, but I have the strong impression others are thinking much further. For somebody who does, check out this old article by Doc Searls (in particular the last part where he talks about the term "consumer" becoming obsolete.

Recently I wrote about the difficulties of using e-mail/SMTP as a transport for Digital Identity interactions. However, these difficulties are not quite the same for instant messaging protocols such as XMPP (nee Jabber), and there are some interesting possibilities that so far haven’t been taken up by that community. In fact, I continue to be surprised that the Jabber community hasn’t grabbed the opportunity to take XMPP into many areas, other than instant messaging, such as:

• XMPP as a publish-subscribe (pub-sub) protocol for website changes.
• XMPP as a pub-sub protocol for RSS subscriptions.
• XMPP as a protocol for Ajax-style fine-grained data exchange to and from a server.
• XMPP as a transport for REST or SOAP-style web services that can traverse firewalls and that connects to the user, rather than a particular host (so you can say "send message X to user Y" instead of "send message X to host Z")
• XMPP URLs as identifiers for individuals, and XMPP as a transport for digital identity interactions.

XMPP, for example, has had support for VCards for a long time, and that support is built into most XMPP clients. The Jabber Software Foundation is even the (somewhat reluctant) steward of the XML-VCard specification that we refer to in LID. Of course, we do that because in LID, we have long recognized XMPP’s potential (and at NetMesh, we’ve had Jabber/XMPP support for a long time in our InfoGrid product and customers are using that to deliver real-time business events derived by InfoGrid from information in fragmented legacy systems).

There would be some issues that need resolving (e.g. the fact that standard web browsers are not IM-aware) but they are resolvable, at least much more so than for the case of e-mail.

Anybody in the XMPP/Jabber community reading this, and interested in collaborating? Anybody in the proprietary instant messaging community?

This is one of the most common questions I’m getting about LID. The argument goes like this: people are used to addresses that look like xxx@yyy (e-mail: for people) and those that look like http://yyy/xxx (for sites). If LID uses http URLs to identify people, won’t that confuse everybody?

Well, yes, it does, but that issue is compensated more than sufficiently by the advantages we get by using http instead of SMTP. Here are the most important ones:

• Google: if you type my name into Google (try it), what do you expect to show up first? Why not my public Digital Identity? Turns out that is exactly what shows up: my LID URL, with its default page, which happens to be my blog. If my LID was my e-mail address, there would be no way for Google to show it first and the distribution of digital identifiers for people like you and me would be very hard (and thus we couldn’t use it for very much)
• Key distribution: by using http, it is very easy for the owner of a LID to distribute their public key (e.g. here is mine, simply by adding the ?meta=gpg%20-export%20–armor argument to my LID URL). All the practical issues with key distribution in a e-mail based system like PGP do not occur.
• Commands: In LID, we always use the base LID URL and then append various commands, whether this is querying for information (e.g. ?xpath=/VCARD/N), specifying a format (e.g. ?format=mime:text/xml) or an action (e.g. ?action=sso-approve). Defining such a vocabulary of commands, and making it work with existing e-mail systems would be practically infeasible (in our view).
• Uniformness: This way, people, groups/organizations and non-human entities (e.g. RFID tags) can use the same protocols for digital identities, which would be unlikely in case of e-mail.
• Spam: With more than 50% of e-mail now spam, we don’t want to introduce an ever-increasing amount of probability that a digital identity message won’t get delivered (because some spam filter, or quarantine scheme, or whatever decides not to deliver our message as sent).
• Browser as first-class client: by using http, standard, unmodified web browsers can be fully-enabled digital identity clients, which is great.

Having said that, there is at least one thing we could theoretically do to create the illusion of e-mail addresses even if we don’t use them: automatically translate an address such as lidddemouser@lid.netmesh.org into addresses such as http://liddemouser.lid.netmesh.org/ or http://lid.netmesh.org/liddemouser. However, by doing this, we may introduce other, difficult to understand, issues for the end user, such as the http behavior when SMTP behavior is expected (e.g. on-line vs. batched, browser redirects vs. helper apps etc.).