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.