Each one asks me to fill in a profile, and each time I end up repeating myself. I am sick of it. This is the kind of thing OpenID was developed to partially solve, however I think this is overkill.

OpenID (as mentioned elsewhere) has problems and its uptake is declining. I rather think this is because it is trying to do far too much.

Gravatar on the other-hand is simple and to the point, requires the end user to do very little and is pretty damn simple to implement from a server point of view.

Could the same approach be used for profile fields? I think yes, and here’s how it might work…

• First of all, we have a site somewhere which lets a user create an account and fill in their profile fields.
• The profile comes pre-populated with common labels (name, description, location, interests etc), but lets users add extra fields if they like.
• The service has a REST like API at the back end which accepts queries like: http://fooprofile.com/api/[field]/[md5 hash of email address]/ to which it returns a blob of text.
• When a user creates a new account on bar.com, that site should attempt to pre-populate any profile fields with data from the service based on an md5 hash of their email address. These can of course be overridden locally.
• Periodically bar.com should update its fields via the API, unless the user has overridden the profile field (or has otherwise selected not to do so).

Crucially with this light method, the user experience of the site remains pretty much unchanged and all the hard work is done magically in the background.

I also think that there is no need to specify what fields constitute a profile. The semantics of this will likely evolve naturally over time and there is no way to predict what extra fields will be needed. You wouldn’t dictate what tags someone would use, so why dictate profile fields?

In phase two of this you could easily imagine using OAuth to decide which fields a site has access to.

You could also imagine multiple providers being possible (providing the api was consistent). So when a user signs in to bar.com they are asked who there provider is – so they could select fooprofile.com or wibbleprofile.co.uk or any other provider. This would keep OpenID’s distributed nature, but without confusing the user too much – a url is always a url in this model.

So all that leaves is the single point authentication aspect as a distinct and separate problem, and one which must be solved in a way that is transparent to the user – perhaps an encrypted and public key authenticated token exchange using a similar technology as the above?

Just pondering….

Update: I have bashed together an example of the sort of thing I was talking about over here: http://skunk.marcus-povey.co.uk/aer/

I can honestly say that the whole event came as an invigorating breath of fresh air and I want to say a great big thank you to all those who helped organise the event – as well as all those who attended!

For the uninitiated the first rule of Barcamp is that everyone needs to get involved which leads to some very exciting, sometimes heated, but always useful discussions.

One of the things that I am particularly excited about is the support there was for doing a Transparency camp in the UK… so much so that its actually happening!

The whole event has left me energised and enthusiastic. I have a stack of people I need to contact and a stack of really cool projects to read up on.

This is how conferences should be.

I will blog a bit more about it when I can, its been a bit mad so this is the first chance I’ve actually had to sit down at the computer since getting here (and I’m only able to do that because the combination of jet lag and the steak the size of my head I had for dinner last night has given me a case of insomnia).

I just wanted to share with you a thought that me and Ben had while enjoying the Californian sunshine inbetween meetings, namely a way to link ODD documents with OpenID.

For descovery of ODD documents, I was planning to use the meta / link approach similar to the way RSS is picked up. Now, it occurs to me that if we modify the spec slightly to say that a UUID should point to a page that can either be an ODD representation of the thing that it’s referring to or knows where to get it – i.e. has the appropriate header tag pointing to the url – then it becomes a trivial matter to turn a UUID into an OpenID URL.

Potentially quite useful.