[philikon]

I'm curious how you would come to that conclusion.

The problem is, OpenID will still require you to remember your OpenID provider's URL. (You could also be with one of the half a dozen or so big identity providers, and then every site gets to implement the "Nascar sticker" style icon banners. Like, uh, I don't know, news.ycombinator.com for instance ;)).

On top of the OpenID URL, a lot of sites also want a way of contacting the user via email. So that's another bit of info that you're going to have to enter when you sign up for the first time. What's interesting is that your email address almost certainly identifies you already anyway.

So why not just use email addresses instead of the URL, and API calls instead of those hideous redirects to establish identity? It's not too hard to see how you would end up with "verified email" as a core identity concept, and that any of the mechanics described by OpenID aren't really useful.

[wmf]

If the browser can remember a BrowserID token, it could also remember an OpenID URL. If the browser can have chrome that triggers a BrowserID login, it could have chrome that triggers an OpenID (3.0) login and does all the redirects behind the scenes. I think with OpenID+OAuth the RP can get an email address.

[Groxx]

Thank God someone else sees it.

There is no reason that your browser can remember a unique username and password for every site you wish, but not a single OpenID url. Or that it can fill in username and passwords across wildly-varying-markup sites, but not in the much-more-frequently-identical OpenID fields. At absolute worst, the OpenID experience can be 100% identical to the Username/Password experience, but no browser I've seen has even done this trivial implementation, much less a more seamless one.