Following Clickpass‘s lead, there are 3 key scenarios that a Universal OpenID Button needs to enable in order to gain widespread use on the web: 1) new user sign up, 2) existing user sign in, and 3) merge existing Identity 1.0 user with a new or existing OpenID user.
Despite the existing best practices for all 3 requirements (and many more), as you look around the web you’ll find implementations that demonstrate dozens of completely different takes on what it means to be an OpenID Relyer. One very important side effect of Clickpass’s approach is that their button essentially comes along with mandatory best practices. That is, any site which chooses to implement the Clickpass button will behave nearly identically to any other site that chooses to implement the button.
By necessity, this minimum set of behaviors will be very small–sites probably wouldn’t be as quick to get on board with the button if full-on AX support is required, for example. But the clear guidance that such a button program would provide would be invaluable in helping site owners understand what work goes into getting started with OpenID and doing it right.
Just to throw out a strawman to get some conversation going, I’d say that a Universal OpenID Button should start by supporting the three scenarios I called out above plus it should help users get their very first OpenID if they don’t already have one. This last bit might seem like it diverges from Clickpass, or even from the current practice of each site owner choosing which OpenID provider(s) to refer users to for whatever arbitrary reasons they like, but it doesn’t have to. Site owners could still choose to send their users to myVidoop.com or MyOpenID.com or Clickpass in the interest of either themselves or their users. Or if they don’t want to choose favorites, they could send their users to the OpenID Foundation for help in choosing a provider.
By the way, next post will be the one where I start going into deeper technical detail on how I think we can pull this off.
4 Comments
I don’t know if OpenID buttons are really the way to go. Users unfamiliar with OpenID still don’t know what they are actually doing if they click such a button. Of course, those buttons are convenient but they don’t educate users. I prefer a short explanation of what OpenID is about and linking users to OpenID.net, to Wikipedia or wherever to get more information. A link to a provider list should also be provided.
Shameless plug: If relying parties don’t want to choose a provider – affiliation programs might prevent them from doing so – they can direct users to http://spreadopenid.org/provider-comparison/ as well.
Carsten
I’m all for this. I look forward to seeing how you would implement it, because I still have some questions.
I just insist that the foundations wiki page has something along the lines of:
One Button to rule them all, One Button to find them, One Button to bring them all and in the darkness bind them
I’m all for this. I look forward to seeing your next post, because I think I’ll have quite a few of implementation questions.
I just insist that the foundation wiki page about this says something like:
One Button to rule them all, One Button to find them, One Button to bring them all and in the darkness bind them
JanRain has recently released an OpenID login widget, ID Selector (www.idselector.com) which addresses many of your requests Scott. There’s a recent review by Scott Hanselman at http://www.hanselman.com/blog/TheWeeklySourceCode25OpenIDEdition.aspx or other reviews at https://www.idselector.com/site/testimonials.
Cheers, Brian
One Trackback
[...] have been quite a bit of talk about the current state of OpenID login screens that are becoming cluttered with provider specific [...]