Howdy,

I’ve recently been looking into OpenID 2.0. I think these particular issues are mostly perceived rather than real. Which does not necessarily mean OpenID is problem free, but…

Regarding issues 1&3: There is no need for users to see or even know their OpenID 2.0 URI. You know, even with traditional authentication, it’s common for back end systems to know users by a number or string that makes for a good database key, rather than by their username or email address. With 2.0, an OpenID can be thought of as the same sort of thing: an ID that backend systems use, and about which users do not need to concern themselves. On each web site where a user signs up for an account, they will pick a conventional username that is specific to that site, same as ever.

Not only that, but with OpenID 2, there should be far *less* need for users to remember usernames than with traditional auth. For example if you signed up to foobar.example.com as “foouser22” and later you forgot that username, no problem. The web site will be able to remember your username once you’ve authenticated. The only piece of information you’ll have to supply will be your identity provider (eg: “yahoo.com”).

Regarding issue 2: Yeah, I can see the point, but there’s a counterpoint too: using OpenID, a user can have one single sign-on screen rather than one per website. Currently, without federated ID’s, every site manages it’s own unique sign-in function with it’s own unique look and feel, it’s own unique “forgot password” feature, it’s own rules for password complexity, etc. So I ask, from a lay-user standpoint, which scenario is truly the more confusing?

Regarding issue 4: Centralized identity management is indeed a different problem. OpenID does not attempt to address it, but IMHO, that is as it should be. Identity Management is a whole big ball of wax unto itself.

Regarding issue 5: I beg to differ with this assumption. First off, there are a very large number of web users with a lot more than ten accounts. Whether it is “most” users, I cannot say (but suspect it is). But even if it is not “most”, I’m sure we can stipulate that it’s probably a very large number, which speaks to a serious need. Just about everywhere you go these days wants you to sign up for something — even sites that offer free services. But even for just ten accounts, keeping track of and managing the usernames and passwords for all of them can be cumbersome. It’s well known that most people end up re-using the same password on multiple sites, and that the practice of periodically changing passwords is largely neglected because of the amount of effort involved.

The amount of work needed to responsibly change your passwords from time to time scales badly with traditional per-website passwords. Even ten websites can be a chore, and beyond that it gets truly painful. But with federated ID’s, the amount of work needed is small and constant, regardless of the number of sites one uses.

There are other real problems that OpenID also addresses. For example: with current non-federated password authentication systems, users are repeatedly entering passwords and sending them all over the place. That is a serious security risk, especially coupled with the tendencies of users to reuse and not change their passwords. OpenID addresses this by allowing users to authenticate just once, to a chosen and trusted provider; all other web sites then leverage that but get nothing that could expose the user’s main authentication credentials.