SocialGraph FooCamp 2008 here I come!

I’m sitting in Frankfurt Airport (FRA) waiting for my connecting flight to San Francisco which will let me attend Social Graph FooCamp 2008.

According to the cast of people assembled on the wiki it seems that its going to be lots of fun and hopefully very productive.

I’ll be arriving to SF after noonish. If you want to meet, say hi, or anything else, Email me through the contact page.

Since this is a FooCamp, I do have a very rough on the edges topic to discuss and bring up. I wanted to write a post about it before the camp but whenever I started writing the post I kept on hitting open issues (or at least issues that must be resolved before moving on). This eventually made the post very incoherent so I thought that the best way to resolve it is by putting up a session at the camp.

I’ll guess we’ll see what we will end up doing at the end :-)

OpenID 2.0 Directed Identity and Emails

A couple of days ago I’ve talked with Eran Hammer-Lahav about an idea I had regarding his post about using Emails as OpenID identifiers.

During the talk another sub-idea came into light in regards to OpenID 2.0 Directed Identity and Emails. While I’m not sure if this has been discussed before (I didn’t have much time to go through old posts on the OpenID mailinglist yet) I thought about bringing it up here.

Directed Identity is a feature that allows a user to enter the domain in which his/her identity resides. This means that if I want to use my OpenID login at some site instead of entering the whole URL to my exact identity, I can simply put the domain name of my OpenID provider.

My provider will figure out all the rest including how to direct me back to the right site after I correctly login.

Yahoo’s implementation of OpenID 2.0 supports directed identities. At their OpenID site, they are educating users to write just “” instead of a full blown long URL to their profiles.

With a small change, a user can use his/her Email address to use directed identity, after all, users already knows how to enter an Email address in most sites to sign-in/up.

In the case of Yahoo, instead of entering “” to use directed identity, why not put your whole Email “”. The consumer OpenID implementation can simply cut off the domain name from the Email and use directed identity for the rest of the process.

I’m sure a lot of Yahoo users will find that entering their Email more natural and easier to comprehend than to figure out they should put the domain name.

The benefits for this idea is in its implementation. Providers that support OpenID 2.0 doesn’t need to do anything. The real change here is in the OpenID consumer libraries that supports OpenID 2.0. The consumer libraries only needs to use a simple regex to extract the domain name from the Email.

Do you know if this idea was previously suggested?

Do you think its applicable?

I certainly think it can make it easier for everyone and I’m thinking here in mother terms. I know my mother knows her Email and knows how to sign in to sites with it. I’m quite sure she has little understand as to what a URL is, what’s its syntax and why she would need to use it.

Plaxo OpenID support lacks OpenID Delegation support

UPDATE: Plaxo DO support delegation, just not XRDS. It seems a WP database problem caused some of my OpenID delegation plug-in to mess up settings the wrong openid.server and openid.delegate values.

It should have been for openid.server and for openid.delegate. The problem was due to the fact that XRDS is yet to be supported in Plaxo. I didn’t notice the problem with the configuration of openid.server and openid.delegate due to the fact that the XRDS settings was correctly configured and all of the sites that I use OpenID with do support XRDS.


Plaxo is a real cool tool to synchronize your calendar and address book. Their new v3.0 (still in preview/beta mode) is really really cool and can sync from everything to everything.

They just announced that they now support OpenID as a relaying party so you can sign up for Plaxo using an existing OpenID or attach OpenID identities (yes, in plural) to your Plaxo account.

I already had a Plaxo account so I wanted to attach my existing OpenID to it. My OpenID is actually delegated from this blog to MyOpenID (my OpenID provider) using the OpenID Delegation plugin. It seems as though the Plaxo implementation lacks support for delegation.

Too bad, delegation is one of the stronger features OpenID has.

Plaxo, please support OpenID delegation. Without delegation it’s not a complete OpenID solution (at least I think so).

Corporate Identity and Identity Issues

There is a lot of buzz about Sun’s announcement of OpenID support and the fact that Sun will be giving OpenIDs for all of its employees.

While this is indeed good news for the identity community in general and for the OpenID community specifically, it got me thinking about the implications for such a move in which a big company OpenID enables all of its employee.

If a company OpenID enables all of its employees and its OpenID server is usable for outside parties to authenticate against it means that now every employee of that company, when authenticating with his/her OpenID can be verified as an employee of that company (providing that no one spoofs the domain and DNS settings, etc).

On one hand, now when I read a forum post or blog comment that was created by a certain company employee which authenticated using his/her corporate OpenID account I can evaluate that this person indeed works for that company and take that into account when evaluating the things he/she said.

On the other hand, it loosens the rope around the employees necks and allowing them to express under their corporate identity which, in some cases, may circumvent the PR department. Since we already know (or can verify) that this identity did come from that company it can cause PR hell (or goodness, depends on the information :-) ).

The only way to properly utilize this power is to educate corporate users on identity issues, not just the rest of the users using the internet. The corporate will greatly benefit from that by avoiding PR hell and the users will gain better understanding about internet and online identities which is always a good thing to educate people about in this always on, publicly accessible and fast world we live in.

What do you think on the subject of corporate identities?

Will better education of people regarding their online identity and separating their corporate identity from their personal identity will help everyone better understand when they are in their corporate hat and when they are on their own?

I wonder what would be the best ways of educating people about that? Should it start from having multiple user names when sharing a single computer?

The new and slick

I’m probably the last person to talk about it, by has a cool and slick new design [via Scott’s blog].

They also added a cool new feature, client side certificate, so when you install such a certificate on your machine you don’t need to do anything to sign in. It does all that for you!

Just remember to NOT use it on public computers or on computers that are being used by more than one person and do not have a different user names for each person.

Congrats to Scott and all of the fine team at JanRain!

In the transition, one thing was lost though, my personal icon. It wasn’t a biggy cause I uploaded it again. On the other hand if I haven’t read about the redesign of the site I would have probably thought I was hijacked to a different one :-) (not!).

Twitter and OpenID

Dave Winer says:

“[…] we could make Twitter the open identity system we’ve been looking for. Make your Twitter ID the one that you use to log on to other service […]”

I say let Twitter support OpenID with all of the good Relaying Party Best Practices including (but not limited to):

  • Ability to associate an existing account with an OpenID
  • Ability to switch to another OpenID (sort of a password recovery for OpenID)
  • Ability to create a new account directly with an external (non Twitter) OpenID (be a standard relaying party)

If they want to, they can also be an OpenID provider (which should be good for them, of course ;-) ).

OpenID Vendor Lock-In (sort of)

Continuing my previous post about OpenID and Vendor Lock-In, a reader of this blog named Andrew commented on the previous post about a problem he had with and Zooomr. He has some valid points here which I wanted to highlight in this post (he also had some points that I think can be easily fixed or that are actually a non issue). You can also read my complete answer to Andrew here.

Prior to discovering the whole idea and notion of OpenID Andrew registered to Zooomr. Zooomr’s accounts are actually OpenID accounts which they provide, so every Zooomr user also gets an OpenID account that he can use on other OpenID supported sites.

Zooomr delegates the management of the OpenID to through their affiliates program. (UPDATE: Apparently, this is not true. For some reason I thought it was the case, but it is not)

After Andrew got to know OpenID he wanted to truly own his identity by using his own domain (either use delegation or run his own server, whatever he chooses), but now he could not use his identity in Zooomr since Zooomr doesn’t have the notion of supporting multiple OpenID identities tied to the same Zooomr account.

In fact, he is tied to his OpenID identity in Zooomr for using Zooomr and since he got a Pro4Life account this identity will never die.

In my previous post I’ve suggested a couple of ideas to avoid OpenID vendor lock-in. I now want to add an additional point:

  • Sites should support the ability to associate multiple OpenID identities so that a user can add, remove and switch the identity used to access a certain account in a certain site.

Jyte and claimID, for example, support the ability to add multiple OpenID identities and associate them with a single account of each site respectively. You can then login to these sites with each and every one of the OpenID identities you have associated with your account.

OpenID, Trust, Vendor Locking and Delegation

There is a lot going on about OpenID these days and a lot of claims are being raised which prevents greater adoption of OpenID by users.

One of these claims is about Trust and Vendor Locking. How can I trust a certain OpenID vendor? after all, gaining access to my OpenID account will give access to all of the sites I’ve signed in/up using OpenID.

This is a legitimate claim, since it reminds everyone of how Microsoft Passport.NET Live ID is not that successful being a one vendor, non transferable identity.

One of the key elements of OpenID is that it’s decentralized and there is no one body that controls it but if a user signed up to a certain OpenID vendor they are essentially locked into that vendor unless they have the proper skills or items that allows them to perform delegation.

Having delegation is exactly the thing to make all of these claims go away since delegation give the power back to the user. The underlying OpenID vendor will supply the service but everything MUST go through the user’s domain to get to the vendor, thus allow the user to change vendors without being locked in.

The problem with delegation, however, is that it requires a certain amount of preparation. You either need to have your own site/blog and add the necessary <head> tags or you need to use a service like (I’ve previously written about it here) which gives you a URL composed out of your name (using the .name domain).

The problem with the solution of is that its only one .name vendor that provides this service. Although they are responsible for the whole .name TLD it is still a sort of vendor locking. If all .name providers will support such a service, things will look much better.

To sum things up, a possible answer for the claims about OpenID, Trust and Vendor Locking is to simply highlight the benefits of delegation and provide all of the necessary technical means needed to make this as easy as possible.

Below is a list of a couple of ideas I thought about (some are more of a wishful thinking since it doesn’t depend on the OpenID community alone) which might make things easier for everyone:

  • Support for OpenID for .name domains available with all the .name providers
  • Built-in support for Delegation in blogging platforms including hosted ones such as, Blogger, TypePad and the rest (for WordPress blogs that you are on your own server/domain you can use my OpenID Delegation plugin :-) )
  • Support for migrating existing accounts in existing sites to an OpenID account, thus allowing users to consolidate their various accounts on various sites into an OpenID account.
  • Support for migration of accounts between OpenID vendors including support in the OpenID spec to figure out a permanent redirection and perform a necessary fix up (similar to a permanent redirection performed in HTTP).

Technology is suppose to make things easier for everyone and lower the barrier of participation so that everyone, regardless of their skills, can use technology for their benefit. Let’s lower the participation barrier for OpenID and let everyone claim their own identity.