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.
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.
# posted by herestomwiththeweather @ 12/15/2006 07:03:00 AM 
Comments:
<< Home
"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."
This is a controversial topic. I would say that you can and should trust "any old identity provider", but only for that basic assertion that says "this person is allowed to log in with this OpenID identifier." It's true that doesn't always get you a verified e-mail address, but it also doesn't lock the user in to using a specific provider, or having to use different providers for different sites.
This is a controversial topic. I would say that you can and should trust "any old identity provider", but only for that basic assertion that says "this person is allowed to log in with this OpenID identifier." It's true that doesn't always get you a verified e-mail address, but it also doesn't lock the user in to using a specific provider, or having to use different providers for different sites.
# posted by 
: 11:30 AM
: 11:30 AM
I say that part of OpenID is handing over part of your security decision-making to a third party. If that third party is misconfigured, badly programmed, irresponsible or simply evil, you have every right to refuse to parley with that provider.
It's 100% up to the consumer admins to decide which identity providers they trust to provide decent identities. If identity providers are sloppy or ill-intentioned, it's against the interest of my site and my users to allow them to make part of our security decisions.
It's 100% up to the consumer admins to decide which identity providers they trust to provide decent identities. If identity providers are sloppy or ill-intentioned, it's against the interest of my site and my users to allow them to make part of our security decisions.
I dunno, I think it is up to the consumer to choose a good identity provider. The whole idea behind OpenID is that you don't have to worry about the provider. All OpenID really does is provide a unique ID for a person, so any verification and validation should really be focused on the provided data, no the provider.
tim, that would mean a website accepting openids would have to penalize every person who was using a well-behaved provider by making them validate their email address at the site even though the people have already done the email validation at their identity provider. it's easier for the site accepting openids to blacklist the misbehaving provider than to inconvenience its members.
When I have some time to figure it out, I need to change my Stuffopolis ID from the old login to my 'myopenid' account.
I don't think you have to penalize anybody. Why not validate only those email addresses that aren't already validated by the identity provider?
Is LiveJournal sloppy or ill-intentioned? When you start blacklisting what you call "misbehaving providers", you are in effect blacklisting your OpenID consumer.
Is LiveJournal sloppy or ill-intentioned? When you start blacklisting what you call "misbehaving providers", you are in effect blacklisting your OpenID consumer.
# posted by : 1:34 AM
: 1:34 AM
perhaps "misbehaving" was too strong. how about "bad manners"? :)
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.). if an identity provider supplies an email address and they're not validating it, at the least, it is bad manners not to warn the website accepting the data.
finding fault with livejournal's openid implementation would be like criticizing the mosaic browser. i would never think of doing it!
to address your last point, i don't see how i'm (in effect) blacklisting the OpenID consumer by blacklisting his provider. the consumer can choose an identity providers that meets the requirement or he can register without an OpenID. email addresses belonging to open relay mail servers are (in effect) blacklisted all the time.
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.). if an identity provider supplies an email address and they're not validating it, at the least, it is bad manners not to warn the website accepting the data.
finding fault with livejournal's openid implementation would be like criticizing the mosaic browser. i would never think of doing it!
to address your last point, i don't see how i'm (in effect) blacklisting the OpenID consumer by blacklisting his provider. the consumer can choose an identity providers that meets the requirement or he can register without an OpenID. email addresses belonging to open relay mail servers are (in effect) blacklisted all the time.
I suppose you could maintain a whitelist of providers who you know authenticate email addresses, and everyone else would be on the greylist, with mandatory email authentication.
I'd like to see some kind of system for automatic email verification; I've even written a proposal for it.
Post a Comment
I'd like to see some kind of system for automatic email verification; I've even written a proposal for it.
<< Home
