Many people know (of) Kim from his Seven Laws of Identity, but Kim’s story (like most of the participants in the community) starts much earlier. Kim began his career in academia teaching Sociology (he had concentrated in both Sociology and Math/Physics), an occupation that he loved (teaching), but a subject that he soon became disillusioned with (as he said, “There was never any way to prove who was right”). Like any disillusioned sociology professor, he did the natural thing and started a Reggae band (no, I’m NOT making this up), called the Limbo Springs and proceeded to tour the East coast of Canada and the US for the next 7 years.

Having come off his 1981 sold-out stadium tour promoting the multi-platinum “MetaLimbo” (okay, THAT I made up, but JUST that), he returned to Canada to teach Assembly at George Brown University, Canada’s largest community college (as he explains, technology was always his fall-back when he needed money—sounds familiar!). It wasn’t long, however, until he realized that teaching technology wasn’t what he wanted to do long-term, so he and the head of the IT department decided to start a technology business. As he explains, they were dead-broke at the time (as btw it seems everyone in this space is broke at some time or another—I, myself, like to go broke about once every four years), so they did what any broke technologist would do and started consulting.

Kim and his partner were obviously quite good at what they did because they built this nascent technology company into a 40 person strong outfit by 1992, which was when Kim first encountered the problem of Identity (How many of YOU can say THAT?!). The issue of Identity arose when he was trying to build an email directory for Sprint’s 60,000 employees. The problem was that those 60,000 employees had 150,000 email addresses (it was common to have an email for every ISP at the time). The question was, how do you find a way to associate each of those email addresses with the correct person in the directory?

If you know anything about Kim or his company, you will recognize this was his first foray into the technology that would put Zoomit on the map (and eventually in Redmond as part of Microsoft)—the metadirectory. Metadirectory technology arose out of the need to simplify the management of people and software in the enterprise. Anytime someone joins a company, they have to be given permission to use any of a number of pieces of software and other digital assets. The larger the corporation and the more wired it is, the larger this problem becomes. How can an administrator setup 25 accounts for every person for a company that hires 10,000 employees a year? Better yet, how can an administrator ensure that access has been properly removed for a company that fires that many people in a year?

To solve this problem, Kim and the Zoomit team came up with the concept of a “metatdirectory”. Metadirectory software essentially tries to find correlation handles (like a name or email) across the many heterogeneous software environments in an enterprise, so network admins can determine who has access to what. Once this is done, it then takes the heterogeneous claims and transforms them into a kind of claim the metadirectory can understand. The network admin can then use the metadirectory to assign and remove access from a single place.

Zoomit released their commercial metadirectory software (called “Via) in 1996 and proceeded to clean the clock of larger competitors like IBM for the next few years until Microsoft acquired the company in the summer of 1999. Now anyone who is currently involved in the modern identity movement and the issues of “data portability” that surround it has to be feeling a sense of deja vu because these are EXACTLY the same problems that we are now trying to solve on the internet—only THIS time we are trying to take control of our OWN claims that are spread across innumerable heterogeneous systems that have no way to communicate with each other. Kim’s been working on this problem for SIXTEEN years—take note!

When I asked Kim what his single biggest realization about Identity in the 16 years since he started working on it was, he was slow to answer, but definitive when he did—privacy. You see, Kim is a philosopher as well as a technologist. He sees information technology (and the internet in particular) as a social extension of the human mind. He also understands that the decisions we make as technologists have unintended as well as intended consequences. Now creating technology that enables a network administrator to understand who we are across all of a company’s systems is one thing, but creating technology that allows someone to understand who we are across the internet, particularly as more and more of who we are as humans is stored there, and particularly if that someone isn’t US or someone we WANT to have that complete view, is an entirely other problem.

Kim has consistently been one the strongest advocates for obscuring ANY correlation handles that would allow ANY Identity Provider or Relying Party to have a more complete view of us than we explicitly give them. Some have criticized his concerns as overly cautious in a world where “privacy is dead”. When you think of your virtual self as an extension of your personal self though, and you realize that the line between the two is becoming increasingly obscured, you realize that if we lose privacy on the internet, we, in a very real sense, lose something that is essentially human. I’m not talking about the ability to hide our pasts or to pretend to be something we’re not (though we certainly will lose that). What we lose is that private space that makes each of us unique. It’s the space where we create. It’s the space that continues to ensure that we don’t all collapse into one.

Well on that rather heady note, I’ll end this look into the history of iCards. I for one, however, am glad that as we explore this space and redefine what it is to be a person, that we have someone like Kim deeply involved. I want to move forward as much as anyone, but I also understand that we are touching on what it means to be a person in the 21st century, and when dealing with the core of humanity, we ought be most careful about any unintended consequences we may produce. Next up, the “original” identity metasystem, the Liberty Project, and the lightweight alternative that is taking the internet by storm, OpenID.

As I’ve explained more than once in this blog, a greater problem than finding reliable Identity Providers is getting the websites we know and love to become Relying Parties. That is exactly the problem that Pamela has deemed to attack with her eponymous project. As the project’s mission statement says, “The Pamela Project is a grassroots organization dedicated to providing community support for both technical and non-technical web users and administrators who wish to use or deploy information card technologies.” Given the difficulties I experienced even USING iCards as a non-technical web user, this seems like a pretty ambitious task, and as part of this post, I’m going to try to get my blog up and running. First, a few words about Pamela and the history of the project.

Pamela first ran into the issues surrounding Identity in her role as a technology consultant in Calgary in 1999. Anyone who’s done any large-scale enterprise software installation has likely had a similar experience–try to do anything and you’ll run into a myriad of (often semi-functional) authentication and directory services before you can even get off the ground. She’d been working at a company that does Peoplesoft installations and with Oblix (an enterprise self-service password management tool later acquired by Oracle), when she attended her first Burton Identity conference in 2001. It was here she first began to think of Identity as a (the?) core technology problem, as opposed to something peripheral to what she wanted to get done. It’s a realization that, once had, can become a little consuming (trust me, I spend WAY too much time building software to be blogging about anything–especially, SOFTWARE).

Her second “ah-ha” moment came when, if my notes serve me correctly, she was “hit on the head with a brick” by Kim Cameron at the 2002 Catalyst conference. There he drew her a brief sketch on a napkin where he showed the three party system (Subject, Relying Party, Identity Provider) that is at the core of most of the emerging identity systems. She was hooked, but it wasn’t until in 2005, when Kim added some sample PHP Relying Party code to his blog that she saw a place where she could contribute. As a sometimes PHP hacker, she took the simple code, and began to port it over to some of her favorite PHP frameworks (Wordpress, Joomla, and MediaWiki). Since that time, she and about 10 other contributers have been working to get a 1.0 version of the product out, which, given Pamela’s commitment, I suspect will be about like most other project’s 2.0 release.

Before writing about my experience installing the WordPress v0.9 plugin, a word about the seemingly self-promulgatory name of the project because I think it says a lot about Pamela as a person and the Identity movement she’s part of. According to Pamela it’s the last name she would have thought of as a woman working as a technologist. As she explains, it’s hard enough as a woman to get recognized as a serious technologist without drawing unnecessary attention to yourself. Having a wife who is one the best Java engineers in NYC, but who also is regularly asked if she REALLY wrote the stunning code she produces, I can attest this is true. It’s because of this stereotype though that Pamela chose the name. She was tired, as someone who is self-admittedly “vocal”, of this kind of self-inflicted sheepishness. So in “defiance to self-regulation”, and at Craig Burton’s urging, she chose The Pamela Project.

This is indicative of Pamela and many others I’ve met in the Identity movement not only because it demonstrates the self-reflection surprisingly consistent in this crowd. It is indicative because it shows a willingness to take a risk and do something insanely difficult in order to do something you believe in. I finished my talk with Pamela asking her why she does it. Why leave a long day of fighting with technology to spend the evening coding on something that she can never hope to gain from financially? Her answer was that it is BECAUSE Identity is still too early for many to make a living at it that she participates. It ensures that the many technologists looking to make a quick buck are nowhere to be found. It ensures that Pamela can spend time with people who do what they do, because like her, they care.

I’ll let you know how my experience actually USING the Pamela project goes in my next post. In the mean time, as you wait in breathless anticipation, why not go over to the project’s site and ask Pamela how you can be of use. This is a big project and they’re going to need all the help they can get.

Paul, like most of the people in this space is an adult (which is one of the things I find most appealing about Identity). He’s been building software companies since he left MIT in 1982. When he left his last position as President of the publicly traded BitStream in 2000, he left with the express intent of building a BIG company–one that could fundamentally transform the internet and leave a lasting legacy. So in 2000, when he co-founded Pariity with John Clipinger, did he set out to build an Identity layer for the internet?

As is the case for most people in this space (and another reason I find it so appealing), the answer is no. Paul had a vision of an internet where trust between people and organizations could be automatically brokered, similar to that expressed in the Augmented Social Network paper I discussed in my first post in this series. He wanted to surround each individual with a reputation layer and then build the algorithms that would help efficiently establish trust between those individuals. The problem that he and so many others have run into when attempting to “thicken” the data that surrounds us on the internet so that it can be shared across sites is that WE don’t exist on the internet. In other words, like so many others, Paul stumbled into the problem of Identity.

In 2003, about the time Paul ran into this problem, he caught wind of what Microsoft was implementing on the Identity layer and realized both that it would be perfect for what he wanted to accomplish AND that there clearly needed to be an open source implementation of iCards. So Paul’s project took both a turn to Identity and to open source, and Higgins, which now is primarily thought of as the open source implementation of iCards, was born.

I don’t want to go over the details that distinguish the Higgins’ implementation of iCards from CardSpace because it has been designed (intentionally) much along the sames lines, so that it remains compatible with that emerging standard. One important point to note though, is that it suffers from the same schizophrenic nomenclature as CardSpace, in that the Higgins the project encompasses BOTH the iCard selector that lives locally AND the server based technology for brokering claims.

Besides this, it does have one additional layer that is extremely powerful that deserves some discussion: the rCard. As I discussed in my CardSpace series, CardSpace supports a pCard (a PERSONAL card that allows you to assert limited claims about yourself) and mCards (that organizations with information about you use to “officially” assert information about you). So what is this “Relationship Card” (rCard)?

Two things distinguish and rCard from an mCard: persistency and bi-directionality. What do I mean by these two things and why should you care? With an rCard that is persistent and bi-directional, YOU can provide constantly updated assertions about YOURSELF to a claim provider. How might this work? Well, think about the implicit attention data currently locked up on your computer. Might you want to allow a company that serves as your “movie preference” claim provider to have a persistently updated stream of your implicit movie data? For example, if you established such a relationship with Netflix, they would have a real-time stream of your movie searching, viewing, and purchasing activity that occurred OUTSIDE of their site, and could thereby provide you and other sites where you used their “Movie iCard” with better recommendations.

So the rCard puts YOU back in the loop of the iCard claim stream and allows you to automatically update that information on a POLICY basis. In other words, with an rCard, you can set a policy that defines WHO gets updates on WHAT data and WHEN at a granular level. If PERSISTENT, GRANULAR, BI-DIRECTIONAL data links sound familiar to those who’ve been reading this series, it should. Establishing those kind of data pipes are exactly what XRI/XDI are designed to do, and in fact Higgins uses XRI/XDI in the rCard layer.

So what are the most important things to remember about Higgins?

1. The technology has been in development for FIVE years now, so you may want to think twice before duplicating it.
2. It is MORE than just the open source iCard implementation. Identity is a MEANS to an end, not the end itself.
3. With the rCard, YOU are back in the loop and can establish persistent and granular assertions about yourself.

Next up are the two final installments on iCards: a discussion of the Pamela Project and an interview with Kim Cameron of Microsoft’s Cardspace.

As I explained in that post, three participants make up this simplified view of the Identity Metasystem, a Subject (you), a Relying Party (the website that needs to authenticate you) and the Identity Provider (the service you and the RP both trust to assert claims about who you are). CardSpace encapsulates all of these entities and their interactions using the Web Services (WS-*) specifications.

Before explaining how this is done, just a brief word on the history of Web Services. Web Services are a suite of specifications that enable two (or more) different software systems to interact without knowing the details of the other’s technology. SOAP, the core specification, was released in 1998 and essentially defined a way to encapsulate data in XML. Since that time, many specifications have been developed that add advanced functionality to this simple idea. These specifications are collectively known as WS-*.

Now let’s return to Identity and our various parties in the above diagram. To represent your identity CardSpace uses the WS-Security Token. WS-Security was one of the first extensions of SOAP and, as the name implies, it specifies a way of protecting SOAP messages. Part of the WS-Security specification is the concept of a WS-Security Token, which is essentially a way to encapsulate tokens from existing security specifications into universally understandable security tokens. The cool thing about this is that, theoretically at least, your Identity Provider could use whatever security specification it prefers, convert the authentication data into a WS-Security Token and send it to the Relying Party, who could then translate the WS-Security Token back into whatever format of authentication it needed.

Now that we have a way to securely encapsulate our identities using WS-* Security Tokens, we need a way for websites (RPs) and your Identity Providers (IPs) to figure out what the RP needs and what the IP has. To do this, CardSpace uses WS-Policy and WS-Metadata. As usual the WS geniuses have named the services well. WS-Policy and WS-Metadata enable the RP to encapsulate and publish exactly what it needs (SAML token from the DMV asserting you are over 21) and WS-Metadata allows the IP to publish what it is capable of (I’m the DMV and have an over 21 claim for you authenticated using Kerberos).

Cool! Now that the RP and IP can figure out what each other has and needs, and they can both understand a WS-Security token we just need to convert their specification specific tokens into the WS-Security tokens. To do this CardSpace uses the WS-Trust specification, which, along with a LOT of other things, defines a Security Token Service (STS). The STS is a token exchange where the input can be any of five existing token profiles (Username, SAML, X.509, Kerberos, Rights Expression Language) and convert them into each other.

As you can see, all the communication technologies needed for CardSpace already exists in the WS* specifications. If you refer back to the 7 Laws of identity, you will note that I haven’t addressed Laws 6 and 7 that address making the Identity Metasystem usable by ordinary people. I’ll cover that in my next post.

In 2004, Microsoft was still smarting from its hugely ambitious and hugely unpopular Passport service. As a way to move forward, Kim Cameron, Microsoft’s Identity Architect, did an interesting thing: he started a blog. On his identity blog Kim started a discussion about why Passport had failed and how to properly bring an identity layer to the internet. In 2005, Kim encapsulated the discussion of the previous year in a white paper called “The Seven Laws of Identity”.

1. User control and consent: Pretty straight-forward—people should determine what information they share about themselves.

2. Minimal disclosure for a constrained use: This means the system should share ONLY what it needs to. The canonical example is buying booze. The Identity Metasystem should only say that you are “over 21” (necessary), not your actual age (too much information).

3. Justifiable Parties: Only parties that need to be involved should be involved. This one is a little tricky—how to we determine who needs to be involved? The short answer is you do. The point of this is NOT that there shouldn’t be a third party (like an Identity Provider), the point is that if there IS a third-party, it should be clear to YOU that they are involved so you can make the choice whether to proceed.

4. Directed Identity: A directed identity is one intended for a particular party (e.g. my medical records for my doctor). It seems OBVIOUS that an identity metasystem would do this, but REALLY what this law is asserting is that the system shouldn’t use correlatable information as your identity. In other words, an identity metasystem that decided to send your Social Security number to every site that wanted to verify you are you would be subject to GROSS abuse. Instead, the IP should send a unique token to each site, so that it isn’t easy for them to realize you are the same person across sites.

5. Pluralism of Operators and Technologies: This just means that we can’t have a single company or a single technology manage identity for the internet. The prohibition against a single company is pretty obvious, as that company would be WAY to powerful. The prohibition against a single technology is more controversial. On the surface it makes sense for the identity layer to handle any previous and future protocols and security frameworks. In reality though, the internet has done pretty well relying on HTTP, and there is a real question as to whether this law adds unnecessary complexity.

6. Human integration: Put simply this means the metasystem should be as clear as possible to ordinary people. Implicitly it means this need should overrule other considerations (like UI customization or rad design). This is also the “anti-fishing” law.

7. Consistent experience across contexts: This is kind of a weird one, but essentially it means that whether you are handing over your medical records or just your email address, the experience should be consistent enough so that in both cases you know that you are giving up a piece of your identity.

I’ll save the discussion as to whether these laws are ALL really necessary and some of the real historical reasons for their inclusion for other posts. Next up is the actual implementation of an identity metasystem that Kim derived from these laws and after that the Higgins project.

The names of Ootao and Andy Dale come up a lot when you’re looking at the identity landscape, but if you look at either of their sites, it’s pretty hard to understand why. Further Andy Dale’s got a British accent, came to the Bay area from Israel, and pronounces his company’s name “Ew’ Dow”. Pretty mysterious stuff indeed! Look a little deeper though, and you’ll find one of the most practical and passionate implementors of real world identity technologies, particularly those surrounding XRI/XDI.

Andy and Ootao (Andy is VERY quick to mention that it is a team effort) are the enterprise guys who can actually build real life, highly scalable services in the identity space. Go to an iBroker? Chances are it’s running off of Ootao’s infrastructure. Heard about Plaxo’s OpenID implementation plans? Ootao’s there too. One of Ootao’s most ambitious projects to date is an XRI/XDI implementation they’ve done for the La Leche League (an organization that promotes breastfeeding). This may sound like a strange combination, but not if you understand LLLI’s needs and what XRI/XDI are great at. LLLI wants new mothers to be able to self-organize into communities around the world. Spontaneous self-organization requires people to have both a strong personal identity AND the ability to share aspects of that identity selectively. If you remember back to my post about XRI/XDI, establishing these granular trust relationships is exactly what XRI/XDI are great at.

Talk to Andy though, and LLLI is just the beginning. Ootao has created a new services company called Wingaa (great name, great logo, TERRIBLE user interface on their site!). It takes some digging, but essentially Wingaa is offering a suite of services to Registrars that enables them to turn your newly purchased URL into you Identity Hub. Want your URL to be your OpenID address? Done. Want your home page to be your personal iName contact page? Done. Want to access all your identity related accounts (Linked In, Facebook, Blog, etc.) at a single URL? Done. And Ootao is doing this the right way by building the INFRASTRUCTURE and allowing the companies that already have a relationship the person enhance that relationship using their tools.

As I wrote in my first post about the identity movement, one of its greatest strengths is it’s idealistic roots. This has also been an Achilles’ heel though, as it’s struggled to build out the necessary technologies and find viable business models. The people of Ootao come out of the enterprise and are implementors at heart. Because of their unique mindset they have played and will continue to play an important role in the ever evolving identity landscape.

1. Finding business models for identity products is REALLY hard.
2. If you ever think of getting an iName, this stuff is pretty confusing.

If you’ve read my previous posts, you should have a basic understanding of XRI/XDI (the technology behind iNames) and know that it is now an “open” standard. But what does that mean? A few things:

1. The XRI/XDI specifications are managed by their respective Oasis (the XML standards body) technical committees.
2. The patents that govern the technology have been licensed exclusively to XDI.org, a non-profit public trust organization.
3. Anyone can implement the technologies for any purpose without the prior consent of XDI.org.

So how does Cordance, the company that bequeathed the patents to XDI.org ever hope to make any money (which if you refer to the companies history has been a pressing issue for some time)? Well as part of the bargain for handing over the rights to the XRI/XDI technologies, Cordant was granted the right of first refusal to be the GSP (Global Service Provider) for any Global Services XDI.org might want to offer for the first 15 years after the Global Registry Service went live (2005). Let me attempt to unpack this.

As I explained before, XRI and XDI are cool technologies because they allow extensible, persistent, permissioned, granular connections between two data elements (like people). Now imagine if the unique identifiers for each data element could be resolved using a web browser by referring to a global registrar (like domain names) for each of these data elements. Essentially using simple syntax, you could define what elements about you any website in the world had access to. Cordance, along with Neustar (a giant registrar infrastructure company that runs among other things the .biz domain) has built this global registry.

Since Cordance is the defacto GSP for all XDI.org services, they are essentially the wholesale registrar (think Network Solutions) of high level XRIs (think names and companies). Cordance also authorizes iBrokers (think GoDaddy) to retail these high level XRIs. If you’ve followed the history of Network Solutions, you will understand this can be a pretty valuable business. VERY valuable in fact, IF web browsers spoke XRI/XDI by default (which they don’t).

If they did, however, not only would Drummond’s patience with the technology finally pay off, it would hugely simplify building a powerful identity layer into the internet. More broadly, it would make it possible to build persistent, granular “trust contracts” that would make it MUCH easier for all of us (people and companies) to control what information we would like to share with each other.

As to whether this will ever happen is very much in the air. I hope, however, that by explaining how difficult it has been for Cordance to free the technology and yet still make enough money to provide a meaningful service, we can understand how difficult the “business model” problem for identity companies is going to be to crack. In my next (and final) post on iNames, I’ll write about the mysterious Ootao and its founder Andy Dale.

Let’s jump into the wayback machine to 1995. Netscape is still crashing your computer every time you run it because it’s a memory hog. Drummond Reed’s teamed up with Peter Heymann (ex-Microsoft, ex-Warton MBA guy–nice!) to build a company called Intermind (the first company to own the XRI/XDI patents). They’ve been working on this “Communication Objects” technology that’s kind of like RSS, and by 1997 they’ve raised around $17 million and have a team of 70 people. One morning Drummond wakes-up and Microsoft has dropped an open standard that competes directly with his proprietary one and his business evaporates. What do you do?

Well, you first probably try to shop around your intellectual property (which he did, to Netscape in particular). Assuming you don’t have any takers (which he didn’t), you probably learn from your mistake and make sure the next time you try to implement a standard, you make it an open one (which is what Drummond did). He joined the P3P (privacy platform preferences) technical committee and let Tim Berners Lee know that even though Intermind held patents that might cover what they’re trying to implement, he wanted to play open this time.

Now let’s fast forward a few months and note that Microsoft is playing a VERY heavy role in the P3P TC. Let’s also note that Netscape has noticed and is (belatedly) trying to get involved. If you’re Netscape and you see Intermind on the TC, you probably think, “Hey, isn’t that the company that was trying sell us the patents covering all this stuff”. As Netscape you probably bring this to the TC’s attention too, which they did. Tim Berners Lee asks Intermind to make a declaration of their intent about these patents.

Okay, so remember a few posts ago how Drummond’s like the drummer, who’s the only consistent member in a band that keeps changing names and members? Well Intermind has a brand new CEO from the telco industry (who shall remain unnamed because he’s about to make a big mistake). Drummond, remembering back to that painful morning when he got out-opened by Microsoft, thinks the obvious thing to do is to declare that Intermind intends to release the patents to an open standards body. Telco CEO says he’s got a better plan and announces that Intermind will charge royalties. Now wakeup to WSJ articles claiming you’re holding the internet hostage, lose your place at the P3P table, and remember really hard that next time you’re introducing a standard, it better be open.

Fast forward a few more years–new CEO, $30 million more, IP in a public trust (XNS.org), specification being managed by OASIS (the XML standards body). So far so good, but how do make money? Well, new CEO wants to build enterprise software based on the now open standards. Good idea. CEO doesn’t know how to sell enterprise software (bad), Dotcom crash (very bad), 9/11 (tragic). No more company–join the crowd.

What do you do? Well, remember, you’re Drummond Reed and you love this technology, so you get new investors, new CEO, and make one(?!!) more go of it. That company is Cordance. In my next post I’ll explain the relationships between XDI.org (formerly XNS.org, but same public trust of IP), Cordance (iNames Global Service Provider), Neustar (iNames Registrar Infrastructure Provider), and iBrokers (iName retailers).

Good question. iNames are an implementation of a set of technical specifications called XRI/XDI that has been under the stewardship of Drummond Reed since at least 1994. The specifications haven’t always been called XRI/XDI (originally Communication Objects, then XNS), and the company associated with them hasn’t always been Cordance (originally Intermind, then One Name). Drummond and the core concepts are about the only things that have survived throughout (If XRI/XDI ever really catches on, he may be known as St. Drummond for his infinite patience!).

So what is XRI/XDI and who cares? Also a good question. XRI is a way to refer to things on the internet (e.g. people, businesses, addresses, etc) that creates a permanent machine-readable identifier (a number) along with a human-readable identifier that can change over time. This is cool for identity because whereas I may want you ALWAYS to have access to my address, the actual CONTENT of that address is likely to change over time. With XRI, my address is a data element assigned a PERMANENT numerical identifier, but the human readable identifier can be changed (and even transferred) to someone else.

Okay. Midly cool. XDI is VERY cool though. What XDI enables is a way to create a PERMENANT, PERMISSIONED, GRANULAR pipe between two data elements. So taking the address example again, let’s say both you and I have an iName, which is just a specific kind of XRI for people and means we each have a permanent number and a modifiable human-readable name. Using XDI, I can establish a PERMANENT (unless I revoke it) link between the two of us that allows you to have access (PERMISSIONED) only to my work contact information (GRANULAR).

Better yet, since both XRI and XDI are extensible (that is, you can associate as much stuff as you want to them), my XRI can have ANY number of data elements associated with it (contact information, preferences, friends, music, etc.) and the link between us can have ANY number of rules (contact info: allowed, auto-update: allowed, friends: denied).

This stuff is a little complicated, but if you’ve started thinking about how to OWN and CONTROL your identity data on an INTERNET-WIDE scale, without drowning in complexity, and without having any ONE company in control, you will quickly understand that the existing internet protocols aren’t up for the task. If you were then to spend the next ten years working through all the technical and political issues surrounding what’s missing, you’d probably have something that looks a lot like XRI/XDI. On my next post I’ll write about the ownership of the XRI/XDI specifications and Andy Dale and Ootao, the primary implementers of the technology. In the mean time, take a look at this paper on XDI to go a little deeper.