OpenID, and making glue

Except that most non-OpenID systems still use username/password which is Very Bad for security and UX in general.

A username+password tuple is admittedly pretty bad. It’s security weakness derives from its reliance on two, rather than a single secret.

Email+password has its own problems—these are largely addressable with social + UX mechanisms.

Heh, you know I'm not going to agree with you here. But since you put it as you did, I'll bite.

First, I agree with you that email-formatted identifiers are both more convenient and better understood by a lot of people (which is why I've advocated for emails to be usable in OpenID flows — resulting in the EAUT spec and Emailtoid.net service).

Still, the real value of OpenID, regardless of the format of the identifier (about which I could care less — though we will need to make it *easy to remember* at least for the foreseeable future) is that it provides a web-friendly equivalent for someone on the web that you can inspect with HTTP. An email address fails this test since you can't "open it" in a browser. And that means that every service needs to internalize what "stuff" a certain email address is tied to, regardless of what the owner asserts.

So, it is true that email addresses can be confirmed by sending tokens that the email address owner proves she received, the out-of-band experience (having to visit your inbox) coupled with having to then go and supply pointers to all your other services or facets of your identity where this scheme breaks down.

Let me make this personal: when I visit ydnar.com, I can learn a whole lot more about you, based on what you want me to know, than I can from your email address alone. And, you can change the information in your sidebar at any time — with email-based identities, you constantly have to go to each place where you left "identity droppings" and keep things up to date. Maybe not a problem for most people, but a pattern (to use your word) I'd like to see eradicated from the web.

;)

On the contrary, OpenID is even more necessary than every before. The fact that the UI and UX issues are being addressed and coupled with OAuth, we'll wonder in a year or so (fingers crossed) how we got along without it.

I'm looking forward to the OpenID tipping point, especially the realization by many users (Yahoo, AIM, etc.) that not only do they already have an OpenID, they can use it right now.

I think both of you are right...

The problem with email is that it is not actionnable as a url is... (unless you extract the domain, but then you might need a better path) and the problem with url is that it wasn't build to identfiy users, but rather resources, so it is not user friendly at all.

We would definetely need to have a true user "identifier" that would be both actionnable and and "pointing" to a user more precisely than what a url does.

People put up with u/p not because they like it but because they don't have well-packaged, easy to use options. People are rightly scared of identity theft and I suspect annoyed by password requirements. I love the WordPress OpenID plugin, which is easy to use for tech hobbyists but beyond the practices of most people. OpenID needs to be a consumer product, and it still isn't.

I wouldn't say that OpenID has failed yet. I just see more adoption day-by-day.

As a web developer, my experience with user registration/login/authentication stacks is that they take a fair amount of work to integrate properly. Broadly speaking, even basic integration is messy. It's costly to go beyond plain username/password auth. OpenID is usually approached as an add-on auth mechanism which takes even more time to get working properly and happily integrated with the username/password auth scheme.

However, web stacks are still evolving rapidly. Expect to see authentication move out of the frameworks and into middleware. That will be a big change. I expect that middleware auth applications that do a nice job of integration with OpenID, Facebook, and whatever else will be the popular ones.

OpenID is an extensible set of technologies. Expect to see even more support for automating signup and registration and account lifecycle maintenance.

I have over a hundred different username/randomly-generated password combinations I have to manage now. Whenever I see a new service where I can just use OpenID to log in, I breathe a sign of relief, and pledge myself to buy the developer a beer if I even meet her/him.

I don't think OpenID can win by fighting a problem that was already resolved — but it might, by helping developpers set up system like what Adina Levin describes. So far, I've only seen Facebook Connect try it, and it's very beautiful. I'd love to have the same one-click system from my ISP (as a proxy to official matters) or from my delivery service (I get registered parcel delivered to a box, with a web-site enabled service behind it), and maybe my banks (one has fancy card readers, the other is far more fearful)

As someone actively building little nifty webapps as a hobby, I can't be bothered writing signup, login, password recovery, and having to architect my systems to store secret data like passwords and hope that my webhost maintains everything nice and securely. So for me, OpenID is not about centralized logins and security for users so much as just saving me effort. All I need is a reasonably usable login page, and a controller in my ruby code to handle the openid transactions which I can copy from app to app and get working within minutes!

I feel secure, and safe, but most importantly, I've eliminated a huge chore from the routine of trying out a new idea. I don't expect OpenID to be integrated in to many existing app's, but I expect more and more, people like me, trying idea's will start with it because that's the thing most compatible with rapid prototyping, and eventually, some of those webapps are bound to be a success. :)

The main thing that makes OpenID a good solution, is directed identity. Any OpenID providers not supporting this (in the way yahoo.com does) are forcing me to reduce usability if I choose to support them, so they risk having any nice UI at all, and could become only accessible via the 'login with openid' option in my form, only via an annoying and complex url.

IMHO, Information cards can do everything OpenID can do and more. OpenID naturally leads to InformationCards, or i-cards. InformationCards can also avoid passwords altogether and save developers all the time to code a un/pw/captcha/secure solution. It can also create a persistent opt-in customer connection for sites. As long as the user wants to stay connected, they can regardless of how many email accounts you have, where you move, etc.

mmkay, because of some of the comments here, I'm going to point this out for the umpteenth time:

http://username@domain.tld/

Is a valid HTTP url. Obviously, the provider has to put something useful there, but there's no reason they can't.