I’ve recently begun to look into OpenID and like what I’ve seen so far…the idea that I control my identity and can choose who I want to provide the service appeals to me. When I first began evaluating OpenID, I found out that I already had an OpenID courtesy of AOL. That’s cool, I thought, but I don’t want to be affiliated with AOL, even if it’s just a URL. Next I looked into myOpenID as a provider, and it occurred to me that switching to a new provider, in this case, meant changing my OpenID URL! So every time I switch providers I have to update all of my sites with a new identity URL? Fortunately, using delegation, this is not necessary. Using a personal URL as my OpenID URL (my blog URL, for example) I can switch providers whenever I want/need without having to update this URL on every site. Delegation adds an additional degree of persistence, since my blog URL will probably not change as frequently as my provider preference.

Ok, but what happens when I change my blog location, switch to a different domain or service provider, etc. (basically any change that will affect my personal URL)? Enter the i-name. As you participate in various activities on the internet, URLs that point to your activity change over time. The abstract notion of your identity, however, is not something that ever changes. An i-name/i-number is a handle for your identity that should rarely (never) change. You can read more about the concept at Xdi.org, but the idea is that you register an i-name for yourself (mine is =jmpease) that never changes and use that as your OpenID. Further extending this idea, you can have “permanent” handles (tags) using i-name forwarding that redirect to your blog (=jmpease/(+blog)), email/contact (=jmpease/(+contact)) , homepage (=jmpease/(+home)), etc., regardless of the locations for each.

Good stuff! Right? Unfortunately, the lack of OpenID consumers isn’t making the technology very useful at this time, but it’s early and it seems that some of the major players are backing it (to some extent). The issue with the support thus far, however, is that everyone wants to be an OpenID provider without providing any consumption. In other words, they’ll give out an identity you can use at any OpenID-enabled site, but their sites aren’t OpenID-enabled. This kinda defeats the purpose of OpenID, don’t you think?!

Aaron Toponce writes in his blog on this very issue:

Supposedly, news has hit the front that Microsoft will be supporting OpenID as a provider, and rumors have it that your GMail account can be used as an OpenID identity. But what about logging into these providers with an existing identity? Here’s the question posed: Can I login to AOL, or create and AOL account, with an already existing OpenID identity? What about LiveJournal? Wordpress? Yahoo!? Blogger? etc.

NOPE.

Dare Obasanjo provides some good reasoning why this is so in his blog entry entitled “A Proposal for Social Network Interoperability via OpenID“:

If you look around, you’ll notice that the major online services such as Yahoo! via BBAuth, Microsoft via Passport Windows Live ID, and AOL via OpenID all provide ways for third party sites to accept user credentials from their sites. This increases the value of having an account on these services because it means now that I have a Microsoft Passport Windows Live ID I not only can log-in to various Microsoft properties across MSN and Windows Live but also non-Microsoft sites like Expedia. This increases the likelihood that I’ll get an account with the service which makes it more likely that I’ll be a regular user of the service which means $$$. On the other hand, accepting OpenIDs does the exact opposite. It actually reduces the incentive to create an account on the site which reduces the likelihood I’ll be a regular user of the site and less $$$. Why do you think there is no OpenID link on the AOL sign-in page even though the company is quick to brag about creating 63 million OpenIDs?

Why would Facebook implement a feature that reduced their user growth via network effects? Why would MySpace make it easy for sites to extract user profile information from their service? Because openness is great? Yeah…right.

Openness isn’t why Facebook is currently being valued at $6 billion nor is it why MySpace is currently expected to pull in about half a billion in revenue this year. These companies are doing just great being walled gardens and thanks to network effects, they will probably continue to do so unless something really disruptive happens.

Well, I hope that OpenID is the disruptive force, because, conceptually, it makes for a great end-user experience. Of course, the requirement is that the major players act as OpenID consumers as well as producers!

I’ve also done some thinking in terms of tying OpenID into our enterprise systems. It’d be great if I could use my OpenID locally, but there also needs to be a way to link it to my organizational identity controlled within our local identity management solution. So, even though I’m authenticating my identity using an external OpenID provider, my identity is tied to some local collection of access rights. I’m looking for a solution that doesn’t require me to use my local organization as an OpenID provider as do current solutions I’ve seen, such as CrowdID (Atlassian Crowd) and OpenID-LDAP. Requiring users to use a specific OpenID provider defeats the purpose of OpenID, does it not? I’m thinking along the lines of something like an initialization phase where I authenticate locally using an institutional username/password and provide details regarding my OpenID. From then on I can authenticate via OpenID to gain access to all systems that my linked institutional identity has access to. Regardless, it will be interesting to see how enterprise identity management and web identity management (particularly via OpenID) converge.

I’ve recently switched gears from Java development to investigation of the various advances in web 2.0 and am ready to conclude that there is entirely too much stuff. Participation in even a small portion of the available networks requires a great deal of time that is much better spent elsewhere. How can I possibly keep tabs on what’s available, what works and what doesn’t, actively participate in the tools/networks that I like, create content to contribute, share the content, maintain a social life offline and remain employed?

The problem is not with the large number of choices, though, because choice is great. Rather, the issue is that each tool is just another silo of participation, information and content. For the most part, any given tool requires me to create a separate account and profile, which allows me to contribute content that is stored in a proprietary format, accessible only via proprietary apis. I think this video accurately sums up the issues: http://mashable.com/2008/01/14/not-sure-what-dataportability-is-see-the-video

Creating content takes time and effort. If I create content using one tool, can I reuse it in another, or am I doomed to reinvent the wheel?

I was thinking, the other day, about writing a Firefox extension to integrate Google Reader with my live bookmarks (where is the Google Reader API, btw?), but thought it would be great if I could, instead, select from a list of available feed service providers. This would certainly require me to write custom code to interact with each different api. What about a tool(s) that provide an aggregated view of recent activity in the selected social networking tools that I participate in? Maybe this idea is old, I haven’t checked around yet…but such a tool would be great, I think, and much easier to develop if each supported a standard api.

Is OpenSocial the answer? I don’t know, but it’s certainly a start in the right direction. Where does RDF fit into the grand scheme of things (including projects like FOAF and SIOC)? Worth watching is the efforts of the DataPortability group currently taking initiative to address these very concerns (referenced in the video above).

Bottom line, we need a way to ease the burden on the end user so they can do more with less effort. In my opinion, there is a bottleneck created by issues such as multiple account maintenance, content recreation and limited integration between services with disparate apis. Such a bottleneck must be limiting users’ ability to do the very socializing the services are trying to support. I think future trends of adoption will favor those services that are easiest to use and through which data can move effortlessly…those services that support the data interoperability and standard apis mentioned above.