OpenID: A developers view

I've been looking at putting together an OpenID enabled site (or even making it an OpenID server) - it's quite an interesting idea, if a little complex (from a developers perspective) to get ones head round.

The big problem is that I really am not a fan of long complicated specification documents, or rather I don't mind writing them but reading is just another matter! I will probably have to fall back on hacking around with other peoples code to work out how to do it!

I found a couple of reasonably good examples that I could probably use:

PHPMyId: which is sort of halfway to what I want - it's a single user OpenID system (I'm going to set it up over at errant.livemeta.net and see how it goes). Looking through the code the actual "ask me for data and I reply" system looks fairly simple - just requires trawling through.

Clamshell: which is a full on multi-user OpenID system. This one is a bit more complex but based loosely on PHPMyId. More importantly it has long-term storage and multi-user storage examples that PHPMyId doesn't.

A bit more searching brought up a couple of handy links (OID wiki intro, A pic of the process) looking into the whole process (including one from the surprisingly useful AOL developers network)

Reading through it all the OpenID idea seems clever and logical. You set up a domain name (such as errant.livemeta.net) and provide in the page certain tags linking it to an OpenID provider. Websites making an ID request then talk to the provider (which can theoretically be anyone) and let that work out if the user at the keyboard is the user to whom that domain belongs to (i.e. with a username and password) - returning all this auth info to the original site. Clever eh?

Some people do turn round and say "that's just silly: you still have no idea who they really are", but the fact is would you anyway; it is just a valid (surely) as requiring sign-up using an email address (which can be got anywhere for free). The OpenID wiki intro puts it best (although in obscure terms: Alice is the user at her keyboard and Carol is the ID server/provider she is using):

All we know is that, according to Carol, Alice is who she says she is. If we don't trust Carol, then we really can't trust what she has to say about Alice, can we? But that's OK. What we DO know is that Alice is the same Alice that Carol always says she is, assuming Carol is consistent about this kind of thing. Further, Alice can't pretend to be someone she isn't, at least not without Carol's help. And *even then*, she can only pretend to be someone that also claims Carol as their official identity server. If things ever got this bad, we'd probably just stop paying attention to Carol altogether, as well as anyone who tried to use her as their identity server.

So with a bit of maintenance and thought you should be able to maintain a fairly secure auth system that supports thousands of people that have never actually "registered" on (or even probably visited) your site!

When I first heard of OpenID I was a bit unsure: I really wanted to create my own system. But looking at it that approach is just silly, why not build on an already well established system which will ultimately let me tap into thousands of users.

Creating a provider service seems fairly easy to do. I'm thinking an external address to my main LiveMeta website, maybe something like openid.livemeta.net OR better yet <user>.mymetaid.net, because that means LiveMeta doesn't feel "tied" to my own OpenID system (although obviously it would be closely affiliated :D)

Now after all that I'd better get to it and write some bloody code!