Identity Commons has been generating some buzz recently in regards to their concept of i-names and the subsequent "WTF are i-names?" that follows. They even managed to get a Slashdot post. Now, Jon Udell is dropping their name and the people are responding. But, none of it really satisfactorily answer the question "WTF are i-names?"

i-names seek to solve the age old problem of assigning globally unique identifiers to humans. And, that's all an i-name is. You get an "i-number," which is a persistent identifier, and you get an i-name which is a human readable identifier. You link up the i-name to your i-number (like assigning a FQDN to an IP address), and there you have it.

What is it useful for? Any time you seek to join two sets of data together (like, taking two sets of identity information on a person and "federating it"), you need the two sets to share a common identifier that you can "JOIN" on. That's what an i-name/i-number gives. And, atop that, you can start building services like "login to Amazon and eBay and Slashdot with the same i-name-enabled credentials" or "personal contact gateways."

Regardless, here's what it boils down to, it is all unnecessary complexity. We already have globally unique identifiers: email addresses — jms18@case.edu, jeremy@alpha-geek.com, Hot_Chix0rs_love_me@hotmail.com — all of those are unique. Yes, email addresses can be reassigned; so can domain names or IP address. Yes, email addresses can expire; so can people (and domain names and IP address).

I do have something useful other than my jibber-jabber about unnecessary complexity. This is the presentation given at the Internet2 Fall Meeting. The presentation does a good job of giving a basic overview.

Two quotes come to mind researching this (the first quote, I can't find the exact text for, so I am paraphrasing; the second comes from the Udell article):

Any working complex system can be shown to have evolved from a working simple system

and

DNS Governance - the 4 bugs

the first bug was creating a structure which *needs* governance

the second bug was creating a monopoly to own the structure

the third bug was creating yet another monopoly to provide "governance"

and the fourth bug is not adopting distributed system technology to render the other three bugs irrelevant.

Trackbacks

Comments

The i-brokers who register and host the i-names will (progressively) provide their users with data services that utilise i-names to regulate permissions, right? So to dismiss i-names as just another "unique global identifiers" scheme is to miss the point that its implementation is organically linked to the formation of a network of organisations (the i-brokers) who will embody the ID Commons principles of data sharing according to trusted identity and mutual consent. And that's just not going to happen with email, period.

Posted by Luke Razzell on December 8, 2004 07:02 PM
its implementation is organically linked to the formation of a network of organisations (the i-brokers) who will embody the ID Commons principles of data sharing according to trusted identity and mutual consent. And that's just not going to happen with email, period.

I still am missing something. Why is the existence of an i-name a prerequisite to share data?

i-brokers who register and host the i-names will (progressively) provide their users with data services that utilise i-names to regulate permissions, right?

I still don't get how A) shared data and C) offered services need B) i-names and i-brokers.

How are i-names different than Shibb's eduPersonPrincipalName (other than being more complicated and externally brokered)?

Posted by J$ on December 9, 2004 01:56 AM