OpenID aint evil, it's just a pain

So a friend of mine sent me a link to one of Prok’s latest blog posts- “The Evils of OpenID“-, probably expecting me to agree that Prok is being a raving loony.

Unfortunately, there are some things in the post that I do agree with.

Prok’s points:

I won’t be responding to all of Prok’s points, just the first few:

1. OpenID is hard to use and misleading in its claims.

I have to agree here. And I’m not talking from the end-users’ perspective. I’m talking from a developer’s perspective.

My SLOpenID project- using OpenID to allow Residents to authoritatively log in as “themselves” has been through three different versions in it’s history. SLOpenID v1 was a heavily modified version of a now discontinued “standalone server”. SLOpenID v2 was a slightly tweaked distribution of WordPress MU. SLOpenID v3 totally abandoned the concept of attempting to be an OpenID provider (which is something that Linden Lab should really be doing themselves).

I abandoned the idea of trying to be the OpenID provider for Agni, mostly because there wasn’t enough demand for it, and partially because some changes in the WPMU platform “broke” the modifications I’d made that were necessary in integrating things in-world.

Operating software that accepts OpenID logins (a “relying party”) is almost as complex than operating an OpenID provider.

The problem lies in that you have to use some beefy math libraries (GMP or BCMath- at least on the PHP platform) in order to bring support for OpenID out of “dumb mode”- some 3rd party providers won’t log in if the relying party is stuck in “dumb mode”. In order to get these installed, you have to either contact your web host and ask them to make the libraries available- or make them available yourself.

For a total beginner to compiling software, the prospect of compiling PHP from scratch just so they can use this one feature will scare them off. For myself, I’ve had persistent problems getting the compile to run on this blog (though rarely is it a problem on SLOpenID/swslr), so even if you know how to get the libraries available, it doesn’t guarantee that you’ll be able to use OpenID.

2. OpenID is decentralized and therefore not the same everywhere.

This has caused me persistent problems on swslr. Not because of OpenID in general, but a specific, optional feature that’s touted as a means of “making it easier for end-users”- directed identity- the idea that you only have to put in “” anywhere you see an OpenID login.

Because of the existence of this single feature, I can’t currently rely on the OpenID data to allow people to quickly switch between their accounts, since it would allow anyone with a yahoo account to login and take control. I’m sure if I delved into the specs and libraries, I could figure out a way of supporting it, but given that the XMN stuff I’ve been working on allows people to “opt-in” with regards to linking their accounts (with the OpenID method, they could accidentally tell the server they own another account without meaning to), I don’t really have the inclination to go investigate too deeply.

Another issue I came across that Will Norris helped me out with was that the various libraries used didn’t treat URLs the same way. Some OpenID providers accepted the URLs, while others reported a vague error (to which I never received any useful help). The fix was relatively simple- just use rawurlencode() instead of urlencode(), and add in some mod_rewrite rules to enforce “+” for spaces instead of “%20″.

3. OpenID accepts other services’ log-ons, but would I give my email password to everybody?!
The system isn’t at all immune to abuse by geeks who might like to track you if they hate what you say. Christiano who raged at me for criticizing his IP captures and captures of email addresses as they came through his system screeched that the former were never used to track people to their actual homes and the latter weren’t saved but discarded. But both those pieces of info, when simply culled out and reviewed and matched against posters you don’t like, can lead you to out alts, for starters (remember the Phaylen scandal), and track people close enough to their homes to be a nuisance

I’ve always had a relatively paranoid approach with regards to the data I accept on my “public” projects- OnXiam for instance, doesn’t provide any means of “proving” that a given person owns a particular account, or is who they say they are etc. If someone wants to say they own two accounts via the XMN data, they have to log in as both avatars and say “hey, that other avatar is mine”. This would then allow the person to log in once, and “fast switch” between the different accounts- without having to log out or use multiple browsers.

Requiring explicit action on both accounts leaves out any worries that the user will accidentally expose their private alts to the world. If I were to use OpenID, the process would be more automated- just a simple SELECT/JOIN query. However, if the user associated the same OpenID with their “public” and their “private” accounts, they’ve inadvertently made it possible for me to see the private activities they get up to.

With great power comes great responsibility. I shouldn’t have to put the people who use my site into the position where they have to trust that I won’t do bad shit with their data.

My own issues with OpenID

The major feature that’s been touted about OpenID is that if you own your own domain name, you can run your own server. The average internet user wouldn’t be able to do this- previously because it meant setting up separate software to do the job. More recently, people can install a plugin on whatever blog software they happen to use- but they’d still have the issue of needing to make those math libraries available. This leaves you with the option to delegate your OpenID out to another provider, which actually relates to Prok’s 6th point- that OpenID isn’t as decentralised as it’s made out to be, since most people will gravitate towards a few well known, existing platforms (LiveJournal, Blogger,, even the bane of web design- MySpace), leaving only “the geeks” to utilise the actual decentralised provider features.

In the current sea of login systems, OpenID only theoretically makes things easier. You can enable millions of people to log into your software by using fewer (albeit more complex) software libraries/procedures. The only alternative would be to support the ability for people to log in with their Google account (via AuthSub), with their flickr account via flickr’s authAPI, and I’ve even noticed Facebook login support popping up on nearly every other site I stumble across. While that does mean you need to maintain another set of code for each additional service you want to enable logins for, these “non-standard” methods are typically easier to support- not requiring people to recompile PHP from scratch for example.


OpenID does still have it’s uses- I do still strongly believe that Linden Lab should start acting as an OpenID provider, as it would give 3rd party developers an existing set of tools to work with that would allow Residents to log into a wide range of SL-centric websites, without needing to go through the current paranoid methods of going in-world to prove you own the account you want to use (the alternative would be for Linden Lab to acquire each and every website that’s specifically targeted towards Agni Residents so that they don’t have to :-P)

OpenID is currently very much a double-edged sword, it has good and bad points, though its still very much a pain to learn to wield correctly.

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to OpenID aint evil, it's just a pain

  1. Here are my remarks regarding those points:

    1. I agree, it might be hard to use and understand right now but there are lots of efforts by Google, Yahoo, Facebook and others to get the user experience right. There was an FB OpenID UX summit recently and a working group is about to be founded. So in the long run I think this problem will go away. Another point is that there is also discussion about using an email address as OpenID as this seems to be more understandable.

    2. As for Directed Identity, shouldn’t you get the real OpenID URL from the OP which you then can use to associate an account with it?

    3. IMHO this seems to be something which the user needs to be aware of. Usually I guess they trust those services to not do any bad stuff with their data, however true this might be in reality. But you have the choice to use any OpenID you want and that’s good IMHO. Whenever you leave some information on 2 sites or entities there is a chance of correlation. And if it’s just a cookie. So I don’t really see this as an OpenID problem.

    As for decentralization: Technically it is and it enables choice. If you very badly want your own OpenID server you can have that. And together with OAuth (which will soon replace AuthSub and the flickr thing anyway) it’s a very powerful tool IMHO.

    Lots of things are of course left to be solved but as it gains quite a lot of traction recently I think it will be solved eventually.

    As for LL being a provider I disagree. We don’t need more providers we need more consumers. I really would like to have LL support an OpenID login in their viewer and thus being a consumer. Maybe not as the only option but as an additional option.

    As for those websites IMHO LL should also support OAuth so that those websites can e.g. read your profile data or whatever if you allow them to access it.

    But in general my opinion is: Give users more choice!

  2. 1) You can already use your email address, assuming the relying party’s libs supports it. Its mostly a case of email address translation, since it is way too early (and because of email to url translation, not really needed) to have SMTP servers talk OpenID.

    2) In theory, yes. But the URL that I get back from yahoo is different every time the OpenID process completes- the Zend Lib wrappers I’m using report “Identities do not match”- that is to say, the OpenID end point returned after the login process does not match the one currently in the database. My code is written that way so that if a Resident’s OpenID account becomes compromised, they can just re-associate a new one- without having to worry about someone else logging in using the old one.

    3) The phishing thing is more of an abstract. OpenID can’t (currently) function without redirecting you from one site to another. Google’s AuthSub stuff also opens up users to phishing- just as much as OpenID does- so the problem isn’t specific to OpenID, so much as its a problem to delegated login systems.

    Decentralisation: see previous blurbs on the difficulty of actually setting up your own OpenID server (and not delegating it out to a 3rd party provider).

    LL being a provider, or at least doing what I’m doing and acting as a delegate (your profile on swslr can be used as an OpenID delegate) would allow 3rd party websites to use the OpenID protocol to authenticate Residents.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>