Lately i've been seeing a lot of buzz about OpenID, and i've got to admit, it's a darn appealing idea, it's just that i don't see it as quite the utopia that others seem to.
i get that OpenID is basically an identification service. What it says is that this identity is valid. In addition, it provides the identity holder a way to publish out as much personal information as they wish to remote services. It also lets those remote services not have to worry about tracking individual user information since there's another service that will do that for them.
Only, i think they still do.
Remember, we're talking about an identity here, not necissarily your identity. It could well be. It could also not be. That identity may be authenticated by an independent, third party site, or some random server. Truth is, while the identity is vouched for, there's nothing to vouch for the vouchers. What that means to me as an OpenID consumer, is that i've exchanged managing users for managing OpenID servers.
Granted, this could be somewhat alleviated by only accepting OpenIDs from a subset of "trusted" servers (which means that spammers, miscreants, and others need only abuse those services with disposable gmail addresses to build up enough OpenIDs to do whatever they wanted to my service). That kinda goes against the "open" part of OpenIDs, though.
i'm not saying that OpenID is worse than BBauth, Passport, or google's auth, since they all sort of have that same problem. The only benefit to those other solutions is that they can do stuff like block abusive users or require CAPTCHAs, additional elements of ID or other restrictions to "raise the bar" on getting an ID. Of course, that means having to put personal information on a remote server, which doesn't appeal to the "need for privacy" concern.
i'll also note that even restricting OpenID to one of the current OpenID machines still means that someone is getting a record of where that identity is going. That's solved by running your own server, but then you hit the problem that spammers and other miscreants will be doing that too.
Personally, i hope this is just another thing i'm horribly wrong about and that there's a far simpler way to address this sort of thing than i've been able to come up with. Like i said, i like the idea of OpenID. i just don't plan on implementing it until i know the answers to those sorts of questions.
I don't see OpenID as a replacement for user accounts - as you correctly pointed out, the fact that someone logged in with an OpenID really doesn't tell you anything useful about them - a spammer could create a million OpenIDs with a script. That's fine though - you just have to put anyone who logs in with OpenID through the same verification steps (a CAPTCHA, send-an-email-with-a-link) that you would normal account signups. The only difference between an OpenID account and a normal account then is that the OpenID one dosesn't have an associated password, which is a significant convenience for the user.
That's why I've been trying to push OpenID as an alternative to authentication via a username/password combination - not a complete replacement for your existing user account system.
There is one other significant difference between an OpenID account and a regular user account: you can correlate OpenID accounts with other sites. This obviously has privacy implications (my opinion is that users who are concerned about this should maintain multiple OpenIDs, potentially all served by the same identity provider so they still only need to log in to it once) but it also opens up tons of great new opportunities for sites to collaborate with eath other in ways that benefit their users.
AH! I get it now.
Ok, so in effect, OpenID really doesn't bring anything new to the table for ID Consumers (e.g. the stuff that one would create an OpenID to access), except for the ability to have a common, trackable, shared ID. One can also presume that if that ID were ever compromised somehow, both Consumer and Creator would have the same sorts of issues they would with any such ID (say, a common account and password). Again, it's about commonality, and convenience not security.
Believe it or not, I'm actually fine with that. I know a lot of folks that have the same id all over, and even more that are frustrated that they can't have one that they actually want. Sure, it might mean that two different OpenIDs identify themselves as "G.W. Bush", but at least this way a Consumer can differentiate and still allow users their preferred names.
Thanks!
Although, as Simon points out, you usually do need to do many of the things you would have done with traditionall password-based user accounts, one thing you are saved from as an RP implementer is implementing all that tedious "Forgot your password?" stuff, with secret questions and confirmation emails and whatnot. Even avoiding implementing that alone helps my sanity no end. :)
Leaving out the "Forgot your password?" functionality also means that there's one less reason for you to requre a validated email address from users, so if that really was the only reason you wanted the email address you can avoid implementing email verification as well. (Probably best to keep those CAPTCHA tests for now, though.)
Save This Page
I hope you'll let the rest of us know once you figure out the answers.