OpenID Fan Club Is Shrinking

A.B. VerHausen writes "Even though there's a whole new Web site devoted to understanding and using OpenID, some companies are dropping the login method altogether. OStatic is reporting that the 'free Web site network Wetpaint announced recently that it will no longer support OpenID as a login option for its wiki, citing low usage and high support costs as reasons.' Apparently, fewer than 200 registered users bothered with OpenID, and the extra QA and development time doesn't make it worthwhile to support. This can't come as welcome news on top of the internal issues the article mentions the OpenID Foundation is having now, too." I've actually been quite happy with OpenID, since I have spawned far too many username/password pairs over the last 20-plus years, but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ...

Comments

a site that uses nothing but OpenID

[marhar]

Stack overflow took an interesting approach, and only uses OpenID. They don't even have a non-OpenID option. Proprietor Jeff Atwood discusses some of the tradeoff at his blog.

Re:a site that uses nothing but OpenID

[Kent Recal]

If you have a better solution, I'd like to know what it is.

Well, I can offer the obvious solution.

Put authentication in the browser. Oh my god, what a novel idea!
Have the user enter his password once, at the beginning of the session, and create a unique token for each site from that.
Submit that token along with every request, in a HTTP-header.

No login required ever. Sites can distinguish users by their tokens (even when they're not "logged in") and a registration merely consists of connecting a token to whatever metadata (a username, address, whatever the user wants to give out to a particular site).

Paranoid users could choose to suppress the token by default and only start submitting it when they hit the "Login" button on their browser chrome - without typing in a username or password ever.

Better yet, add a bit of cryptographic trickery and these tokens can easily be revokable, updateable etc. for the cases where a password is stolen or "lost". And ofcourse browsers could easily store multiple "identities" and provide a dropdown to switch between them on the fly.

It's not rocket science, really. The whole system could be designed and spec'ed out over a weekend and would work better than anything that we had before. No third parties involved and everybody (even the data collectors) happy.

Problem? Oh, right. Getting it into the mainstream browsers... Well, give it another 20 years.

I Wonder Why...

[bradgoodman]

Shrinking support? I wonder why...

Hmmmm...

I checked out the "Explaining OpenID" web site referenced in the article, and it didn't make a whole lot of sense.

It did tell me that my OpenID is: www.google.com/o8/id

I undoubtedly will not remember that, nor do I believe it is even accurate.

I then read how I could integrate it into my own web site - and despite doing a ton of web development and XML stuff, had no idea what they were talking about - at either a high or low level.

In conclusion - If they want to get users and developers on board with OpenID - their going to have to do a hell of a better job. Either that, I'm just too stupid to understand their "OpenID for Dummies" web site.

Now I'm of course just an engineer and developer - I'm sure users like my parents, grandparents and kids would understand this stuff much better.

Obstacles to implementation

[pvera]

I am a web developer by trade, and so far one of the most infuriating things that I have to deal with on a weekly basis is that my customers simply can't bring themselves to care enough to remember their admin logins. Every week I have to unlock a handful of administrators. It doesn't matter if I provided them with a proper password rescue option, it is simply too much for them.

The second big problem is that we have multiple branches of certain products running at the same time, so at any given time one of my customers may have to login into her production, staging or 2-3 development servers, each with its own username and password.

We are a .net shop, so my original idea was to use the new membership and role providers and remove the login mechanism from all sites from a given customer. This works, but it is hard to get all sites in line since there is always something else going on that is more important. They still screw it up, but at least they only have to remember one username and password that works at the same level (production, staging, dev, etc.).

When I heard about OpenID I tried to see if I could implement it in any of our sites that use .net 2.0-style security. I was glad to see that somebody already had thought of this, and I found a ready to run library with a very nice login control for .net that uses OpenID.

It wasn't easy, but it was interesting, and within 10 or so hours invested I had:

1. A .net web app that used ANY OpenID instead of the built-in aspnet_* tables hierarchy.
2. A recovery page. You type your email address and it emails you a list of any OpenIDs in the system that match that email address.
3. A self-registration page. If you arrive at the web app, and you authenticate through OpenID successfully, and you don't have a local profile, it asks you to fill a quick form.
4. Security roles are used just like any standard .net app that uses the SQL membership/role providers.

The beauty of it is that I can even run my own OpenID server for my customers. All they would need to remember is that they login by typing a URL like:

userid.ouropenidserver.com

and it would do the rest for them.

One customer, three projects, three environments per project, that's nine login/password pairs that I am expecting them to remember. Instead all they need to remember is the URL and the password. If they lock themselves out, all they need to remember is the email address used to register, which emails them their OpenID URL. If they forget their password, that is handled at the OpenID provider level, not at the end user application.

Even if nobody else in the world uses it, to me it clearly means that I can spend more of my customer's money in building new things instead of on troubleshooting and damage control (even if the two figures are identical, customers will bitch more about paying for repairs than paying for work that can be recognized as new). And it is an easy concept, if they have a Google or AOL account, they already have an OpenID.