Overloading username and openid_url

DHH, who is promisingly writing a Rails plugin for OpenID with Rick and others, has made a case for applications to store a user’s openid_url in place of their username, and present a unified login form which hides or reveals the different processing of openid & password logins, based on the presence of the http prefix.

When users start typing an OpenID identifier URL into the username field, the web app transparently turns it into an OpenID login action.

The common implementation today is to add an openid_url field alongside the existing user data, provide a login screen that offers regular and OpenID login, and often internally maps OpenID’s nickname (from the Simple Registration Extention) to the username/login.

What are some pros/cons to the proposed overloading approach?


  • For users, the the login or signup screens aren’t complicated further with another visible alternative
  • As a developer, you don’t have to use an additional field in the database
  • As a developer, you don’t have to deal with potential uniqueness conflicts between one person’s OpenID nickname, and another person’s username (which may require an additional username/email form to be presented during account creation in the case of a conflict)


  • According to Spec (s 3.2.1), the user shouldn’t be required to prefix their identifier with http (basically, a usability issue)
  • The gentleman’s standard (also in the spec) of naming the form field “openid_url” to allow it to be auto-populated across sites is lost.
  • Both OpenID users and traditional users may be confused by the overloaded form. If the OpenID logo is displayed, it doesn’t have a natural home which won’t confuse one party or the other
  • The application no longer has a place to store a friendly name for the user. So views display a URL, which will typically be much longer than a username, and require some additional view logic to turn into a link
  • OpenID accounts are at a privacy disadvantage vs. username/password accounts, because their visible username tracks directly back to them
  • For the developer, the code for the two authentication methods (password, openid) becomes even more coupled

Wrong on anything? And other major pro/cons missed?

On the whole, what’s common with current implementations (separate openid form on the login page for the user, separate openid field in the database for the application) is both in line with the spec, and still the better compromise. As the core team’s Rails Plugin quickly evolves, expect details and directions to change.

OpenID protocol diagram

OpenID Protocol Diagram

There are a number of diagrams illustrating OpenID, including the flow diagram in the spec, this one from Brain and JanRain, and this nice one from Paul and Technometria. But none yet matched what I needed.

The diagram is part of a future OpenID cheatsheet, which itself is part of the future screencast on OpenID development for Rails. And I’m happy if others use it for other things. As usual with a diagram, there are tradeoffs and opportunities for errors or misunderstandings. I’d like your feedback.

I split out the HTTP requests from responses, so the order of this could be more clear, even though this adds steps. I also skipped certain details for brevity. I considered coloring actions that involve the user, but just used the text (e.g. “user logins in …”).

I’m sure I let some errors creep in. Any comments for making this diagram more accurate & effective?

Why the lack of OpenID-enabled Rails apps?

OpenID has been quickly gaining momentum this year, with Microsoft’s future role as an identity provider, and AOL’s sudden, wonderful announcement that all 60+ million AOL/AIM users now have an identity provider.

But where are the OpenID-enabled web applications to log into? What we have so far is nice, but it’s not the kind of riches we’re seeing on the provider side of the OpenID equation.

With Rails being the platform of choice for many new & emerging web sites, you’d expect to see OpenID support here first. So really the question is — Why don’t we see more Rails apps with OpenID support?

  • Most OpenID-enabled sites still need to support password authentication. There are some good choices today for creating a new Rails app that only supports OpenID login (the ruby-openid gem’s generator is good for that), but it’ll be some time before all users are comfortable with OpenID. So sites need to be able to add OpenID support alongside password login — and that’s a non-trivial challenge today (see bookmarks for one example, but it’s not yet solid).
  • Competing authentication plug-ins. For OpenID, there are two major competing plugins: JanRain’s generator that is included in the ruby-openid gem, and Eastmedia’s generator (used in the bookmarks example). And to combine with password authentication, there’s a more confusing jumble of choices. If you’re running Rails 1.2, restful_authentication is currently the strongest choice for password login because of its cleanliness, tests, and feature support for remembered logins (cookies) and optional email activation, etc (<1.2, acts_as_authenticated is strongest). And on the OpenID side, Eastmedia's generator is better configured to mashup with other login systems, but it still requires a substantial amount of customization, and it suffers from lack of tests and some out of sync code.
  • The right user interface hasn’t been settled on. Should we present password & openid login on the same page? A set of choices with fancy UI (tabs)? Should account creation be automatic for OpenID? Should OpenID SRE nickname and email be assumed to be configured?
  • The right internal structure involves some difficult tradeoffs. Just at the top level — should different authentication methods all store their data in a unified user model? Should the application’s login and OpenID’s nickname be treated as equivalent? If so, how to handle uniqueness? etc. etc.
  • Disagreements on the wisdom of drop-in authentication. The best hope for making this all more approachable is better plugin support, including authentication plugins that play well together so a single application can support multiple authentication mechanisms. But there has been some disagreement among the community — some would argue that authentication of this type is too tied to unique aspects of the application and too important from a security point of view to be realistic as a dynamic plugin or works-out-of-the-box generator. But without out-of-the-box ease (like what aaa or restful_authentication provides for password authentication), combined OpenID+password authentication will trail in adoption.
  • In short, the killer OpenID plugin has yet to be written. For an excellent spec for what is needed and an incomplete implementation, see Hark.

OpenID is poised to take off. Support from an army of up-and-coming Rails sites could be the turning point.

Are there other tools that make this more approachable for Rails developers?

Microsoft: Windows-OpenID interoperability

Working at Microsoft, it was frustrating to see “not invented here” and “we have to own it” attitudes often dominate when it came to interoperability and standards. Not only did this cause immediate harm to the consumer, but it was also self-defeating — it has unavoidably done great damage to Microsoft’s long-term position in the industry. Hopefully this will change, and is changing.

At the RSA Conference today, BillG made a keynote announcement that future versions of Windows Identity solutions will interoperate with OpenID. Work on the details is just beginning now.

A key part of Microsoft’s identity solutions is the new CardSpace (previously called InfoCard), which is included within Windows Vista, and is available as an optional add-on for both Windows XP SP2 and Windows 2003 Server SP1 (tied to the .NET 3.0 runtime). CardSpace provides software for the user, and a set of APIs for web servers and services, which helps users manage and take control of their identity and and desired level of privacy for those services. Once OpenID is working with CardSpace, you could think of it as just another OpenID provider with some advanced identity management and authentication features.

This is still ultimately an “embrace and extend” strategy for Microsoft. But that is much healthier for everyone than no interoperability at all. OpenID will gain support on the majority platform, and a useful new authentication service (CardSpace) for those users. And Microsoft gains a feature that actually works with the rest of the ecosystem to keep people on Windows. And it’s optional in both directions — CardSpace does not need OpenID to work, and OpenID will continue to work with many other providers, on the Windows platform or not.

Good news.

Read more at Scott Kveton’s blog (CEO of JanRain)

JanRain will never require users of our libraries or services to use Windows CardSpace ™. We offer support for this technology as another option for users much like using our Safe SignIn and Personal Icon technologies on MyOpenID.com. We’ll also continue to support the OpenID efforts going on with Mozilla and Firefox.

And the announcement and news from Kim Cameron at Microsoft.

For us, its clear that OpenID is a really great technology for doing public identities – the simplicity is stunning. I really like your work. OpenID is clearly an important part of the identity metasystem. We really hope to see the synergy keep expanding.