A while back I read a post by Boris about how OpenID is not really easy to use (yet). He is completely right, and if Boris can’t use it, our moms definitely do not stand a chance.

I had a conversation about this with Ted Rheingold of Dogster, who was thinking of implementing OpenID for their users so people could user their Dogster logins to log in to affiliate third party sites.

A very important issue for him is that a lot of his users are not geeks and do not really want to get into the technological side of things. In most cases people will not be familiar yet with OpenID and you want to shield them from the complexities while still offering the benefits.

Do I have a OpenID?

When confronted with an OpenID login box, this is the first question that people —like Boris— are confronted with. What is this OpenID thing and do I have one or where do I get one?

Luckily more and more sites are offering hosted OpenID identities to their users. Wordpress.com does this for their blog owners and LiveJournal does this as well. Most people will probably prefer to use one of these hosted solutions offered by a third party site instead of hosting their OpenID themselves.

This way identities will be created until most people will have multiple OpenIDs. That still does not solve the problem of knowing that you have an OpenID and knowing what it is. I will propose a solution to this problem just after the next point.

URLs for what?

The whole concept that you use an URL to login —though I think it is quite elegant— will be difficult to explain to users, who already have trouble telling their login names and e-mail addresses apart. Adding another entity that you can use to login at sites, will only add to the confusion.

Signing in with e-mail addresses is firmly settled but it did take some time to get there. We may get to the same level with OpenID (and hopefully replace e-mail based logins altogether) some day but that is too distant currently. URLs are generally perceived as user unfriendly and normal users should not have to deal with them too much (yet).

Maybe i-names will be a solution to this sometime, but I don’t see it becoming mainstream any time soon.

Solve away the URLs

Taking both previous points together: most people will use a hosted OpenID solution and people do not want to type URLs, we can just abstract away the URLs completely.

When logging into an OpenID consuming site, that site can provide a selector with a couple of well known sites providing OpenIDs. This list of OpenID providers should be attuned to the target audience so they are familiar with these sites. With a fairly small list of providers, you can probably cover a large part of your user base.

I have made an example login box that works this way. It gives users the choice between several well known sites or the possibility to fill in your own OpenID. This is just a mockup which you can adjust in any way you like. You could expand the different login options or present them anyway you like. A site which already takes such an approach is the site for the band Rooney. You could also display the generated OpenID to the user at some point to get them accustomed to the OpenID they will be using.

Using that selector and a textbox users can pick a site they have an account on and fill in their username. The consuming site can then construct an OpenID URL from the given username and use that to log the user on. So taking my Wordpress.com username illustir it would construct my OpenID http://illustir.wordpress.com/ automatically (see the example).

What site are you taking me to?

The step where you leave the site you are logging into for another site can be a bit distressing for users. The approach that sites such as Wordpress.com take by having their own identity provider which looks and feels familiar dampens this transition a lot.

Large sites using OpenID should generally have their own provider so that they can control and attune the experience for logging users in.

Dogster’s use for OpenID

Suppose Dogster wanted their users to be able to log into third party sites using ther Dogster login credentials. This seems like it is exactly the kind of problem that OpenID is meant to solve. Especially in the case where the login is more a dependent syndication —a third party site affiliating with a bigger site— than that it is a general login (though nothing stops it from working that way as well).

So in the Dogster case they should start their own OpenID provider and OpenID enable all their accounts which are both relatively easy steps. Then, third party sites could use a Dogster login to log onto their site by simply becoming an OpenID consumer and by constructing the correct OpenID from the Dogster login.
The only problem with the Dogster case is that they use e-mail addresses as usernames and you would have to construct an URL with the e-mail in it. You probably would not want to spread e-mail addresses in that fashion.

This approach can be taken by any big site which wants to enable its users logging in elsewhere with the same credentials.

Update: I updated the example to be more clear and more educational about the actual OpenID that is being constructed.
Besides that a lot of people are missing the point. I am completely in favor of browser integration rich identity homepages and everything. Go out and build them already, but should/could/would are not going to help us right here right now. Given Livejournal+Wordpress+AOL almost everybody already has an OpenID but most of them do not know it yet. This —admittedly trivial example— is meant to fix that.

(This post got stuck somewhere in the queue. Tomorrow my longer post about Portable Social Networks.)

Willem Velthoven was scheduled to speak about anyMeta on the second day. I was already familiar with Mediamatic and their work and Willem had already contacted me about their social networking offering but his talk provided a lot of insight anyway.

Willem on the left (picture by Julian Bleeckr)

I did not know that Mediamatic is significantly in the social networking business. They seem to implement a great number of them on top of their standard anyMeta platform. Having done this a number of times, they began to wonder if they could abstract away the commonalities to reduce the duplication of effort. Willem talked about how his personal information is duplicated on a great number of websites and how this gets tiring.

AnyMeta is also the system as it has been used for the Reboot.dk website for before, during and after the event itself. It is a structured wiki which takes some getting used to but I think is quite rich in functionality. The only thing I am missing right now is a fine grained setting to receive notifications from the system.

Willem also talked about the API which any anyMeta site exposes at a standardized URL and which provides hooks to do pretty much anything you would want to with the site.

OpenID support both ways —by which I think he means both being an OpenID, accepting OpenID logon and being an OpenID provider— is supposed to be forthcoming.

In his talk Willem outlined the use cases he envisioned a networked social networks should accommodate and what the problems would be that come up with that. He was also very curious if other people had already started doing the same so that no effort would be duplicated.

I had registered myself on the Reboot site to host a conversation about the technical aspects of implementing social networks using OpenID. I mentioned that this could be a great follow-up to Willem’s talk to first talk about the need and the use cases for an open social networking system and then talk about the technical means we already have to our disposal to realise such.

See the following post on my talk.

Sorry about the delay, my stay in Copenhagen was busy and exhausting, both of which are not very conducive to coherent writing. I will post my report of Reboot as a series of posts in the course of this week. Today part one.

I had booked Reboot blindly because my experience from the previous year had been so positive. I expected it to be a mixture between the new and the old. Getting new ideas and concepts by talking to interesting new people but also getting in touch again with the familiar faces from the previous year.

I flew into Copenhagen on Wednesday with my plane landing around five and the Preboot drinks starting in Kongens Have at six. Seeing as I had to check into my hostel first, this made for a tight schedule. I’m glad I was still a bit familiar with Copenhagen so I could find my way around easily. Like last year I was joined at Sleep in Heaven by a couple of other Rebooters.

This year’s Reboot also coincided with a major change in my life. My activities in various spheres on- and offline had dropped to near zero while I was busy graduating and I have only just begun taking them up again.

After having finally graduated in March, everything is more or less up in the air. I have started reorienting myself but I’m not in too much of a hurry. Reboot looked like it should be a nice break and a good place to refocus on what I should do next.

I had thought I would be less busy after graduating, that however proved to be false. Seeing as I still have to finish a course at university, wrap some stuff up at my graduation, do the odd web development gig, help Tipit.to make true on its promise and pursue my diverse passtimes of writing, photography and sports, I keep busy.

This mix also made the default question asked during a conference ‘What do you do?’ a bit hard to answer. I usually defaulted to Web Developer which is the easiest to explain and understand.

The Preboot drinks pretty much confirmed my feelings. In a very relaxed atmosphere in the park, preliminary introductions were made, hands were shaken and interesting conversations had. Seeing all those known faces and friendly words, was like taking a warm bath.

After some drinking, the evening ended with everybody finding a nice place to eat in town. I turned in early to be fresh for the first day of Reboot of course!