Last week we discussed OpenID, one of the identity technologies you should care about.  Today we'll talk about "Information Cards", another open standard for identity on the web.  We'll fill out the series by discussing BBAuth and Live ID in future posts.

The quickest way to understand "Information Cards" is to look at this one-minute screen cast.  It demonstrates login without password using both Internet Explorer and Firefox.  The user simply presents an "information card" to the site, and is safely logged in.

Business Case: if you enable people to use Information Cards to login to your site, your users will be able to login with a safe, consistent phishing-resistant user interface that doesn't require username and password.  People can use a shared "Information Card" across multiple sites for convenience without compromising their login information (similar to using a shared OpenID across multiple sites).  But more importantly, the "Information Cards" protocol is designed for use in high-value scenarios like banking, where phishing-resistance and support for secure authentication mechanisms like smart card are critical.

Protocol: Information Cards are based on open standards.  Anyone can implement, issue, or accept Information Cards.  Information Cards are composed using WS-* specifications instead of HTTP redirect, so the specifications are significantly more complicated than OpenID.

Industry Situation: A number of platforms can easily accept Information Cards for login.  It takes just a few minutes to enable Information Cards on ASP.NET, and code is available for Ruby, Java, and PHP.  Once a web site is configured to accept Information Cards for login, users can login from Windows (using Windows CardSpace), and soon from Mac and Linux.  In fact, just a couple of weeks ago at Burton's Catalyst conference, 11 different clients and 24 different servers participated in an interop demo.

Analysis: Information Cards can be considered to be a "heavier" protocol than the other technologies (LiveID, BBAuth, OpenID).  But when you want password-less login, phishing-resistance, and consistent cross-platform UI; they are essentially the only option.  And Information Cards are complimentary to the other technologies (as we saw with OpenID last week) in that you could use an Information Card in place of username/password to authenticate against one of the other systems.  You should strongly consider Information Cards (end-to-end, or in conjunction with something like LiveID or OpenID) if your scenario isn't one one where you feel comfortable with the security implications of "password reminder e-mails".

It starts when you ask a simple question, like "how can I authenticate users against my site?", or "why do I need so many different accounts for all of these different sites?"  Soon you're wading through a dizzying array of buzzwords: CardSpace, Live ID, BBAuth, OpenID, and more.

I've collected resources about each of the important technologies.  By the time we're done, you'll know the key characteristics and tradeoffs of each.  Today we talk about OpenID.

The best person to talk about OpenID is Simon Willison.  He's had plenty of practice giving a thorough introduction and demo for OpenID.

Simon is clearly eager to push OpenID, but he's forthright and honest about the limitations and tradeoffs.  Watch the whole presentation, including Q&A at the end.  He does an excellent job, so I'll just highlight some observations from the presentation:

Business Case: If you enable OpenID on your site, anyone with an account at AOL, LiveJournal, or other site that supports OpenID can logon to your site without needing an extra username/password.  Anyone can choose to be an OpenID provider, OpenID is not controlled by any vendor.  Currently sites like Yahoo!, Google, PayPal, and MSN don't support OpenID, so people on those services wouldn't be able to login to your site.

Protocol: Enabling OpenID is very easy; it's a simple redirect-based mechanism similar to BBAuth or the old Passport.

Industry Situation: It's unlikely that the companies with largest user accounts databases (like PayPal, Yahoo!, Google) will wholesale allow their logins to be OpenID logins anytime soon.  But I expect companies to experiment with OpenID where it makes sense.

The large identity providers are hesitant to expose OpenID logins for a number of reasons that surface in the presentation and Q&A.  Simon rightly observes that if you're comfortable allowing lost-password e-mails, you are already exposed to most of these risks, and points out that lost password reminders are "web single sign-on with deliberately poor user experience".  This argues against lost password e-mails of course, but puts the risks in context.

The biggest fear people have around OpenID is phishing -- the current OpenID design is susceptible to phishing attacks.  Around the 18:00 mark, Simon raises CardSpace as a good solution.  In fact, David Recordon from VeriSign just posted a proposed OpenID spec detailing how OpenID could incorporate other forms of stronger authentication (including Information Cards) in order to make OpenID less susceptible to phishing and other related identity attacks. Congratulations to the OpenID community on this initial draft!

Some other common issues raised were collusion (30:00), ability to allow AOL but not LiveJournal (for example), and recycling IDs (48:00) since OpenID doesn't have a GUID-style identifier.  For scenarios like blog commenting, these aren't showstoppers.