@Kevin, I understand the appeal of avoiding account management overhead when developing a web site, but I don’ t think current OpenID solutions solve this problem. If we start to see widespread adoption I’m worried we’ll see “forgot OpenID” forms pop up where “forgot password” forms used to live. Also, your OpenID provider doesn’t secure your data, they secure your identity. Your data is still stored all over the web.

The basic point was that the proliferation of OpenID providers has made getting in to the technology more confusing and ideally you would use the same account each time using tools like the ID Selector or Emailtoid to make it so you just have to remember a username or email address that is easy to remember.

Also that sites like Ma.gnolia accept only externally verified identities because that frees them up from creating a way to manage accounts, to focus on making an awesome social bookmarking site. With OpenID You can have your data secured with a provider whose sole focus is securing your data online.

Great point about people already being conditioned to remember usernames/passwords. Remembering which account you used is a new paradigm which people aren’t used to. If they forget which account they logged in with, what is the recourse? Logging in with OpenID, however, is essentially the same as just remembering the “username” portion of the username/password combo.

The idea with IDSelector is to help the user log in *and* educate them about OpenID. For example, if a user selects Livejournal from the IDSelector box, while they type their LJ username into the box the widget fills in their full OpenID URL into the OpenID input field. Other implementations, like Magnolia, ask for the LJ username and then generate the OpenID URL for them behind the scenes.

This little bit of education is important, so that when the user visits another OpenID enabled site, or when that cookie expires, they have a better chance of remembering their OpenID and logging in successfully.