October 25th was the one year milestone for the Early Global Services (EGS) Program, the first i-name registry and i-broker service. On October 25th, 2004 at 17:08:02 PDT the very first global i-name (=mmell) was registered, followed eleven seconds later by =victor.grey, and 38 seconds after that by =fen.labalme. Three other i-names were also registered in that first minute.
With the new year coming up, I’m feeling motivated to blog a bit about where I see 2idi going in the next year. The first quarter of next year will see the launch of the “Global Registry Services for I-Names and I-Numbers” (GRS) by Cordance and Neustar, under the governance of XDI.org. At that point, the EGS program will officially come to an end, and global i-name resolution will be transferred to the Neustar authority servers. 2idi plans to continue to offer i-broker services to the EGS registrants, and will very likely be grandfathered in as a global i-names accredited registrar.
Meanwhile, under the covers changes have been brewing. We have had a year of real life experience with i-names, and we’ve come to some tentative conclusions. The most important of these conclusions is that selling identity services to end users is still a very immature market, and may take longer than we thought to become viable. Meanwhile there are compelling opportunities in the immediate future, through which we will develop required infrastructure, while at the same time providing much needed services, educating and inspiring end users, and sustaining our business.
The real interest in identity services that we are seeing right now is from organizations and businesses who see it as a means to accomplish two things. The first serves an immediate need, to glue web service applications together within and across organizations.
Imagine that you are a non-profit organization that has created a website where you can sign up members, and allow them to log in and create a personal profile. Now you wish to provide them with collaboration tools - blogs, wiki, mailing lists, etc. There are many excellent open source versions of these tools, so it would be pointless to recreate them yourself, except for one reason: you want your users to be able to log into the main website, and then access these tools as logged in users. The user experience should be that it’s all part of the same organizational website.
Third party authentication (an i-broker) solves this problem. Log in at any entry point in this constellation of online tools, and your experience is that you are logged in everywhere. Each tool has a menu of links to the other tools and the main website, and each one of these external menu items encodes the i-name you logged in with. When you arrive at another part of the site, the presence of that i-name in the link triggers an authentication redirect to the i-broker. Because you are already logged in, the i-broker instantly redirects you back to the application — the experience is that you are just logged in everywhere. (The exact methodology is described at http://ibroker.idcommons.net/moin.cgi/SingleSignOn - it will be evolving in the near future.)
In most cases, you will also have a need to ascertain that your user, now that you are sure of their identity, is authorized to access the particular service. This can be accomplished as a background request between applications and the main site, but for this to work, you must have robustly identified your user first, in a way that the authorizing agent understands. I-names and their associated i-numbers make this easy. (I-numbers are non-reassignable permanent identifiers.)
There is one more point I’d like to make about this, and it is the part that excites me the most. There is no reason why gluing applications together as I have described cannot happen just as seamlessly across organizational boundaries when desired, enabling various organizations to work collaboratively on projects in a very agile manner.
The second opportunity is more forward looking - to bust community based reputation out of the single web service jail.
I have described how robust identity facilitates authorization across applications and even across organizational domains. Authorization can be thought of as a very limited form of reputation. If org B asks org A if a certain user is authorized to access a wiki, a positive response is in effect saying that this user is a member in good standing of org A - a little chunk of reputation.
It’s an easy leap to imagine aggregating my membership-in-good-standing in various organizations with my seller’s reputation on Ebay, my reviewer’s reputation on Amazon, and my proxies on Smartocracy to produce a kind of community credit rating (or Whuffie, if you’re a fan of “Down and Out in the Magic Kingdom”).
Of course, this is very sensitive and must absolutely be under the user’s control. There are parts of my life that I may not wish to share in other settings. There is a balance that free societies must achieve between what others must be able to know about you to make an informed trust decision, and what you must be able to keep to yourself in order to live your life as you choose. 2idi is dedicated to guiding the evolution of this technology in a direction that supports this balance.
There is a lot of architecture and coding work happening behind the scenes right now to facilitate these possibilities. We see community i-brokers being less monolithic, more modular, and more distributed and tightly bound to specific organizations while able to share authentication with each other under the user’s control. We see various services as modules, talking to the i-broker but not part of it. I’ll be blogging more about the specifics in the near future.