In Context

Congratulations to my friends at the OpenID Foundation on the news that Google, IBM, Microsoft, VeriSign, and Yahoo! have joined the board. I’ve been in lots of meetings in the past week and the buzz is everywhere.

This happy event has jogged me into writing a few thoughts about OpenID technology and how it fits nicely with information cards (aka i-cards). So here goes.

OpenIDs offer something to people that i-cards don’t. Even run of the mill, freebie, URL-based OpenIDs give you a public identifier that you feel like you own. And the i-name flavor of OpenIDs give you a public identifier that you really do own cuz you’re not locked in to a particular OpenID provider.

OpenID is the winning, lightweight, technology for public, low-value transactions.

• Why winning? The OpenID community blended together the three competing lightweight technologies (LID, OpenID, and i-names) into a unified specification, community, code, and foundation.
• Why public? Because the appealing notion of having OpenID URI that’s mine (e.g. “=paul.trevithick”) also has the side-effect of projecting the same identifier to every relying site allowing me to be easily tracked. To be fair, there is a “directed identity” feature of OpenID that I can use to prevent this–I can just type in the URI of my OpenID OP instead. But I still think the perception is that an OpenID is mostly public.
• Why low-value? Because its simple and lightweight architecture does not incorporate a client component, end-to-end crypto, anti-phishing protection, etc. necessary to support higher value transactions and other privacy-enhancing features. But its great for logging in to blogs, etc.

OpenID + i-cards…

But the best news of all is that the strengths and weaknesses of OpenID just mentioned are a perfect complement to at least the “web-based” flavor of identity selector technology we’re developing in Higgins. With a web-based selector, a user must somehow authenticate to their i-card service provider in the cloud. Otherwise, everyone would have access to everyone else’s i-cards. This authentication step could be supplied by an OpenID OP service. The selector could provide the UI for the authentication interaction and harden it from phishing attacks at the same time.

Here’s how it would work. If I start a new browser session and try to log into a site that accepts i-cards, my identity selector’s “card picker” UI would normally pop up. But since this is a new session, I first need to authenticate to my i-card service–the service that holds my cards. So the identity selector would put up a login window and I’d type in “=paul.trevithick” and my OpenID password. No browser phishable browser redirects happen all because my selector would communicate directly with my OpenID OP server and authenticate me. The OP would return a pseudonymous token that is used to gain access to my i-card service.

Essentially my OpenID password is my master password to unlock my cards. And my cards kind of live “underneath” my OpenID. I use cards when I don’t necessarily want to be identified, and/or when I have a higher value transaction, and/or when I need claims made by third parties about me, etc., etc. all the use cases that cards work best for.

The astute reader will no doubt realize that there other cool synergies are made possible with this OpenID/i-card marriage. And they probably realize that the scenario above points out the need for a new protocol in the OpenID family to provision new services (e.g. an i-card service) in the person’s OpenID XRDS document. In other words, there’s a lot more to this story than I’ve written here.

One last thing. Now that Microsoft is being much more careful about only using the term “information card” generically, I’m feeling free to use the term myself with “i-card” as a handy contraction.