I've been very busy lately working on my next project: an online Texas Hold'em poker site. It's been a lot of fun, and I have most of the actual gameplay functionality working. Now I'm working on the less-fun but just as necessary part: the authentication and login infrastructure.
Since I'm using Django, I can piggyback on its useful authentication module. That's a nice start, but users still need to choose a username and password before they can use the site, not to mention filling out their name, email address, and date of birth. My goal is to lower the barriers to potential users - both psychologically and in terms of effort. Folks are hesitant to sign up for yet another login and password, and to go through a lengthy registration process
Enter OpenID. OpenID sounds like a very promising standard. Unfortunately, the standard promises more than the implementations deliver. Or rather, the standard doesn't quite promise what it seems to.
The idea is that our buddy "Frank the User," instead of having to create a new account on our site, can log in securely using his Google account, or his Yahoo! account, or any of a number of OpenID Providers. At our site, he enters a URL, gets redirected to the provider's site for authentication, then redirected back to our site, all nicely logged in.
Fine. The problem is we need more than just "logged in." After that whole dance of typing in yahoo.com, signing in to Yahoo!, then coming back, all we at the cient site have available to us is a randomly generated token and assurance from the provider site that the user is indeed logged in -- somewhere. We don't know that his name is Frank, we don't know he was born in 1962, we don't know his email address. In other words, we know nothing more than we did before the dance. On my Texas Hold'em site, as is the case on most sites, I need more. I need a way to identify the user to other users. Something like, oh, I don't know, a NAME? I'm shocked that not even the user's name is available from most OpenID providers.
The OpenID specification includes provisions for exchanging profile information. There is a long list of possible attributes. Unfortunately, none of these things are required, so each Provider can choose to share as much or as little as it wants. Google shares an email address, and nothing more. Yahoo! shares absolutely nothing. AOL has the potential to share a good set of information, but the user needs to individually enable each piece of data through a series of checkboxes.
What would be useful is if there were a defined minimum set of information, or even a way for the Client Site to request a certain set of information. And if that info is not available or the user does not want to share it, the login should fail.
Until that happens, OpenID is going to stay a nice idea with no real use in the real world.
Anyway, not sure when this article was written, but janrain's RPXnow completely eliminates the barriers to OpenID.
I had similar issues trying to implement on my own site. My biggest one, though, was the barrier to entry because the user had to know what his/her 'uri' was!
I currently use the free version of RPXnow, where the only real drawback is that the redirect is to .rpxnow.com instead of my own domain, which may make some people feel uneasy.
From what I've seen from your site, I imagine that you could probably write your own framework to simplify the experience for users and get back the info that you need (that they allow you to see).
One more comment about getting "info" on the users.
While it would be great for users to be able to fill in their personal info (name) with their openid provider and then share that with the openid consumers, many people would feel more comfortable simply authenticating and filling in their details separately for each site.
Basically, to use your sites with openid, you would still need to register, but use an openid instead of creating a new username/password on your site.
You still need to have a user db, but don't have to deal with passwords, etc.
You could still even allow people to use the site unregistered, and just enter a temporary name and not store any info about him/her.