Friday, December 29, 2006

 

OpenID Providers and Externalities


This year, I had the fortune of waking up to the ring of my cellphone several dozen mornings. Each time the conversation was the same:
Hello?

May I speak to Jennifer Such and Such? This is the Acme Corporation.

Nobody named Jennifer lives here. You called yesterday and I asked to have this number taken out of your database.

Are you sure?


Yes, I've had this number for many years and I can assure you that no one by that name has ever had this number. Please remove my number from your list.
The calls went on for a few weeks and then, like weatherman Phil Connors in Groundhog Day, I finally woke up one morning without a wakeup call from the Acme Corporation.

But, then they came back for another week. The exact same conversation each time.

The relying party (Acme Corporation) trusted that the phone number was correct even though the identity provider never validated the number. The cost to the relying party and the identity provider was negligible. Apparently, it was cheaper for them to call me for weeks on end than to delete the nonvalidated erroneous data.

What does this have to do with OpenID?

If an identity provider doesn't validate an email address, some sucker like me is going to be getting Jennifer Such and Such's emails from the Acme Corporation. I presumably can't complain to the identity provider because that's Jennifer's data, after all. I can't go to the relying party to fix the problem, either. Unless the relying party knows that Jennifer's identity provider doesn't validate email addresses and requires the validation itself, I'm going to be receiving these emails for the rest of my life.

So, if Jennifer signs up to a website that doesn't possess this special knowledge of her identity provider and take corrective action, guess what? Yeah. Rise and shine, campers, and don't forget your booties!

It turns out that a month ago, the draft OpenID Assertion Quality Extension was published. Among other things, this
provides means for a Relying Party to request additional information about the specifics by which a user enrolled
In particular, there is the enroll.verified.email property.

This is the feature I thought out loud about yesterday in the comments of my previous post:
it's something i would be willing to do if there was an easy way for me to query the provider for the integrity level of the data (in this case, was the email address validated? the provider would have the option to say "don't trust this email address." of course, if he didn't say that, the data could still be invalid, but such an option would let the website know that it needed to do the validation itself.)

Friday, December 15, 2006

 

OpenID Podcast

Two and a half weeks ago at the Triumph Cafe, some friends from Bootstrap Austin gathered to talk about OpenID. Pics (thanks to jonl) here. Quite a bit has happened since then, OpenID was slashdotted, there was the Identity Workshop, and the era of Who 2.0 was announced.

Also since then, I moved Stuffopolis beyond using OpenID just for comments and went hog wild with full OpenID login and registration for the main site and also added it to the Stuffopolis wordpress blog (using the OpenID plugin for Wordpress). Bijoy and Kevin and I also worked together to get the Bootstrap Austin wiki OpenID enabled. Evan Prodromou's mediawiki OpenID extension is excellent and I borrowed some ideas from it when I enabled Stuffopolis. The mediawiki extension allows a website to specify which identity providers it trusts. As a website that enables OpenID logins, you can't trust any old identity provider. For instance, an identity provider might not validate a person's email address. That's an identity provider that shouldn't be trusted.

I took the one hour and ten minutes of audio from our meeting and edited it down to 25 minutes (you can cut it to near 18 minutes if you increase the play speed on windows media player). Here is the mp3 (complete audio can be found here) and here is the outline I prepared for it.

Here's what I learned enabling the sites with OpenID.

The Good: OpenID registration is a beautiful thing. The legacy registration page on Stuffopolis can be scrapped. Once that happens, validating email addresses, requiring passwords and lost password security questions for new members will be forever outsourced to the OpenID providers (those that your website trusts).

The Bad: When introducing OpenID, it is a breeze for new members coming to the site, but it can be a little confusing for existing members who registered with the legacy credentials. When those existing members find out about the OpenID option, instead of logging in with the legacy credentials to add the OpenID to their account, they often log in with their new OpenID instead. This log-in will attempt to create a new account by fetching simple registration data from their identity provider. If their email address (sent by their identity provider) matches the one already registered with their legacy account, they can be given some instructions, but sometimes it doesn't match and now we have a problem because if they go back and log in with the legacy credentials, they can't associate their new OpenID to it because another account (the one they accidentally created) now has that OpenID.

Update 12/17: What I need to do is when a member goes to his profile page and attempts to modify his OpenID, after a successful OpenID authentication, if the site detects that there is another account with the same OpenID, then the site will ask the member to confirm that he wants the other account deleted, making sure there is only one account with that OpenID.

The Ugly: Now that some popular open source packages (wordpress, mediawiki, phpBB) support OpenID, the software should honor each other's OpenID sessions so that someone who logs into mediawiki with his OpenID doesn't get presented with an OpenID login form when he visits phpBB, for instance. Although this isn't a huge problem, it is a little ugly and it seems it will require a standard way of registering OpenID apps on a system so that an OpenID session state change in one app will inform the others.

In a nutshell: OpenID is still immature, but it has an extraordinarily committed community behind it and when it comes to software, that's what counts.

This page is powered by Blogger. Isn't yours?