XRI and I-Names: The Good, The Bad, and The Unfinished

Posted on 12/19/2006 by Drummond Reed

I hadn’t blogged yet about the excellent session Salim Ismail led on Creative Uses of I-Names at Internet Identity Workshop two weeks ago, but Phil Windley did, and then yesterday he posted a longer piece about XRI and i-names on his ZDNet blog. So now I’ve really got some responding to do. Herewith a frank assessment of the current state of the XRI/i-names universe.

The Good

Phil’s writeup is a great overview of what this new type of Internet identifier is about and why it’s relevant to user-centric identity. He sums up the value proposition of a personal i-name this way:

What’s the point? Easy: I own =windley, my i-name, for the next 50 years and I control the resolution. If my blog URL or my Skype handle changes, I can change how those XRIs resolve and you can still find me and all the services related to me. Plus, the XRIs above are (mostly) based on a standard semantics, so if I know your i-name, I can easily find your blog.

Phil nails the fundamental reason that the XRI standard was created: to add an additional layer of indirection on top of DNS- and IP-based URLs that gives an XRI registrant (a person, an organization, or a standards body) control over their persistent identity and relationships.

Phil also nails the second key benefit of this additional layer of indirection: semantic mapping. XRI is (to my knowledge) the first Internet identifier syntax designed expressly for the sharing of identifiers across domains. In fact two XRI syntax characters are reserved for this purpose: +, for general dictionary tags like +blog, +salmon, +love, +jupiter; and $, for special dictionary tags like $v (version), $d (date), and $l (language).

These $words, as they tend to be called, are defined in XRI dictionaries by standards bodies like OASIS specifically to enable resource identifiers to share semantics. For example, the $v space provides a domain-independent, machine-readable syntax for describing the version of a resource. Take the following three XRIs: they all identify version #2.1 of a resource (a blog post, webpage, and newspaper edition, respectively).

  • =drummond/(+blog)/(+post)*88*($v*2.1)
  • @cordance/(+website)/(+page)*143*($v*2.1)
  • @example.newspaper/(+edition)/($date*2006-12-19)*($v*2.1)

The Bad

Phil also hits on one of the main complaints about XRIs: they look strange and their features are as-yet little understood. As Phil says:

XRIs are more complicated than URLs, but I remember everyone screwing up their face when URLs were new too and somehow we got used to them. XRIs make up for their additional complexity in semantic mappings and flexibility.

I think Phil’s right about people getting used to the syntax (especially for easy XRIs like =windley). We’re also doing more on the OASIS XRI TC to continue to make the syntax more human-friendly. But that’s not the most confusing part. By far the hardest-to-understand feature of XRI architecture is how it enables persistent Internet identity. Phil’s article puts it this way:

Further, i-names are not reassignable (unlike domain names), so when you contact the person at =windley, you know it’s me, not just the next guy to pick up the name when I let it expire.

Unfortunately that’s not quite right – which reflects how hard this part of XRI architecture can be to grasp initially. Here’s a brief attempt to unfog it:

To solve the problem of persistent identification of a resource — anything from a person to a white paper — XRI syntax defines two forms of XRIs, known informally as i-names and i-numbers. I-names are simple and human-friendly identifiers like =windley. I-numbers are typically ugly machine-friendly identifiers like =!92E6.7E3C.B5D0.9D7E. Note that both start with an equals sign to tell you they are in the same XRI global namespace, in this case = for individual persons (as opposed to @ for organizations, + for generic tags, $ for standardized tags, and ! for networks). What distinguishes the i-number from the i-name is the ! (bang) character after the initial symbol. Bang is the XRI prefix character for a persistent identifier.

The reason for this special syntax character is that unlike i-names, which are intented to be reassignable identifiers just like domain names, i-numbers are intended to be persistent, i.e., never reassigned. (Technically this latter type of persistent identifier is called a URN – Uniform Resource Name).

I say “intended” because the persistence of an identifier cannot be enforced by technology alone, but only by the operational policies of the assigning authority, in this case an XRI registry. That’s why when you register a global i-name with an XDI.org-accredited i-broker (similar to an ICANN-accredited DNS registrar), the XDI.org Global Services Specification policies require that:

  1. The XRI Global Registry Service (GRS) must assign you a synonymous i-number, and
  2. The GRS must NEVER reassigned this i-number to another registrant again (for eternity). For example, the i-number synonym for Phil’s =windley i-name is =!92E6.7E3C.B5D0.9D7E, and this i-number will NEVER be reassigned to another registrant.

However Phil’s =windley i-name can be reassigned, just like a domain name, either when it expires, or by Phil selling or transfering it to someone else, just like a domain name. Phil has the ability to do that as long as he’s the registrant, which in his case is at least 50 years (because he registered it during the special XDI.org beta program – now that the GRS is live the longest registration currently available is 10 years, the same as most DNS registries.)

However Phil was right on about his identity being protected from “takeover” by another registrant of =windley because XRI-based applications always key on the persistent i-number and not the reassignable i-name. For example, the OpenID Authentication 2.0 specification (which is tantalizingly close to being final, and which supports both URLs and XRIs as user identifiers) explicitly states that when a user logs in with an XRI (typically an i-name), the relying party MUST resolve it and store its synonymous i-number as the persistent identifier for the user. The reason is simple: the user’s i-number will never be reassigned, so even if the i-name =windley expires and is re-registered by someone else (or Phil sells or transfers it), the i-number for the new registrant will be different. So the new owner of =windley can’t go to websites where Phil has used =windley and login as Phil because the website’s database “knows” Phil as =!92E6.7E3C.B5D0.9D7E, and the new owner of =windley will have a different i-number.

There’s another benefit to this XRI synonym architecture, by the way: Phil can register other i-names in addition to =windley as synonyms for his =!92E6.7E3C.B5D0.9D7E i-number and then use any of them to login as this “persona” because they will all by synonymous with the same i-number. For example, I use both =drummond and =drummond.reed as synonyms for my i-number =!F83.62B1.44F.2813 (the one I use depends on the context of where I’m using my i-name, i.e., do I want to reveal my last name or not?)

The Unfinished

So we’re making progress, and it’s very encouraging that digital identity experts like Phil are recognizing the power of the XRI layer of indirection to provide control, persistence, and semantic mapping for the emerging layer of user-centric identity. But as Phil discussed with me after the IIW session on i-names, the remaining hurdle is finishing all the pieces of XRI infrastructure necessary to fully support identity-enabled applications the same way DNS infrastructure had to be in place to support the emergence of the Web.

He’s hardly the only one. That same week on the OpenID mailing lists, David Recordon forwarded a message from Brad Fitzpatrick, originator of OpenID, that summarized one of the main things he doesn’t like about XRI:

– implementations lacking. probably because spec not stable?
particularly hate the answer of using proxy resolvers because it’s
too difficult(!?) to do otherwise.

At IIW, my XRI TC co-chair Gabe Wachob and I found ourselves apologizing to person after person who buttonholed us about the status of specific elements of XRI infrastructure. We sounded like a broken record: “We know it’s not all done yet; we’re working on it as fast as we can; please be patient.”

Gabe took out his frustration by writing a blog entry called The Thrill of the Hack (TOTH) in which he says:

I’m concerned that the i-names community has failed to enable TOTH. We have efforts in most of the directions (hangout, open source, a good IPR policy, a busy developer guide, community support), but they all need more work. Much of the effort on i-names has focused on communicating how i-names are usable to end users. But we haven’t enabled developers to make i-names (and even XRI, which doesn’t necessarily rely on the global root directories) ubiquitous and we haven’t enabled developers to go beyond what we’ve envisioned and come up with the really killer apps.

I’ve heard a lot of the frustration from folks who are interested in playing with i-names, and I want to you know that we hear you, and we understand. In fact, I share that very frustration with you.

So here’s my early New Year’s Resolution, to Phil and Gabe and everyone else wanting to see XRI infrastructure turn into the tool we all want to be. I will do my utmost to see the following completed as early in 2007 as possible:

The OASIS XRI 2.0 specification suite. While XRI Syntax 2.0 has been done for a year now, and XRI Resolution 2.0 has been stable at Working Draft 10 since the spring, both still need one more set of revisions before they are ready for a full OASIS Standard level vote. The third specification, XRI $ Dictionary 2.0 (formerly XRI Metadata), is especially needed for interoperable identifiers in the enterprise space, so we want to get that out ASAP too. Cordance is committed to hiring another full time spec editor to help make this happen.

The OpenXRI 2.0 open source code base. The OpenXRI project was started to become the “BIND of XRI” (Gabe winces when I say that because BIND was notorious for its security flaws; we’re not planning to repeat that here.) This is the code that anyone from from an individual developer to an huge ISP or portal shoud be able to use to operate their XRI infrastructure the same way they run BIND (or another DNS nameserver/resolver package) to operate their DNS infrastructure. It’s currently in Java; we need to complete the resolver, authority server, and proxy server to the 2.0 specs, then start porting it to other platforms.

Documentation, tutorials, and examples. The XRI/i-names community needs to make it exponentially easier for developers, Web architects, ISPs, governments, and others who are interested in deploying XRI infrastructure to get the information they need quickly, easily, and reliably. Several projects such as dev.inames.net have started to fill this need, but they need much more work before they come close to filling the need.

Those of you who know me know how hard I am working personally – and how hard I am flogging Cordance, NeuStar, AmSoft, XDI.org, XDI.org-Accredited I-Brokers, and other companies supplying XRI infrastructure and services – to complete these crucial pieces of the XRI puzzle. I promise that Gabe and I will blog regular reports on our progress throughout 2007.

Also, if you know of individuals or organizations who may be interested in helping, please send them to Gabe or myself (via his or my i-name contact page of course) and we’ll make sure they are plugged in to the right place.

Posted in Blogging, General, I-brokers, OpenID, Practical I-Names, XRI | Leave a comment

Mike Jones on Cardspace & OpenID Synergy

Posted on 12/19/2006 by Drummond Reed

Ever since the last Internet Identity Workshop I’ve been running like mad trying to finish spec assignments, catch up on email, and prep for the holidays. Not to mention catch up on blog posts (Why anyone calls December “the holidays” is beyond me 😉

First up is a comment back from Mike Jones of Microsoft regarding my plea that CardSpace and OpenID UX designers help each other in the user experience shift embodied in user-centric identity. Mike says:

In response to your question “How can we help each other?”, the first step to me seems to be for the OpenID providers to allow people to sign into their OpenIDs with InfoCards, rather than username/password. Then OpenID users will automatically gain all the benefits of the CardSpace user experience ceremony.

Mike’s right that Microsoft has put thousands of man-hours into designing the Cardspace UX, including the extensive anti-phishing provisions. Any OpenID provider can take advantage of that just by supporting Cardspace-based login instead of much weaker username/password login. That’s a great first step.

I think there will be much more to Cardspace and OpenID integration if the demos at IIW were any indication, but I’ll reserve that for future blog posts (after I finish my Xmas shopping).

Posted in Blogging, General, I-Cards, OpenID | Leave a comment

User Experience in the OpenID and Cardspace Paradigms

Posted on 11/15/2006 by Drummond Reed

Aldo Castañeda has just posted a new installment of his The Story of Digital Identity podcast series which will be the first of several about user experience for OpenID. It’s a lively discussion between Johannes Ernst, Chris Messina, and myself about the unique user interface and education challenges of the OpenID user-centric identity paradigm. Johannes has posted a summary of several of these challenges.

In the podcast I compare the early days of usage of OpenID digital identifiers such as i-names to the early days of credit card usage. It was just an entirely new “ceremony” (to use Kim Cameron’s term, originated by Carl Ellison) to pay for a purchase with a piece of plastic instead of cash or a check. But it had numerous advantages for all three parties (the consumer, the merchant, and the banks) or it never would have happened.

The same is true here. The ability to login to a website without requiring a separate username or password must have clear benefits for all three parties (the end user, the website, and the OpenID identity provider offering the service) or it will never happen. The growing community working on OpenID clearly believes in these benefits or it wouldn’t be growing. But growth will be gated by how fast users, websites, and OpenID IdPs all come into alignment on a common understanding and experience of the OpenID login ceremony.

What’s fascinating is that there is a completely parallel effort going on for Cardspace. I know how much work Kim, Mike Jones, Bill Barnes (program manager) and the rest of the Cardspace team at MS have done around developing the new ceremony of presenting and using infocards to login to a website. Bill even has a new blog devoted largely to this subject (his post today on Password Gravity is fantastic).

Kim recently upbraided me for OpenID “confusing the issue” because OpenID can be construed as introducing one new paradigm/ceremony — based on user-controlled digital identifiers — at the same time Cardspace introduces another — based on user-controlled digital information cards. I have argued strongly in the past that address-based identity and card-based identity are complementary and not competing concepts. So now I issue a challenge to both the OpenID and Cardspace communities: since we’re both fighting the same user experience battle at the same time — and since our goals are complimentary and not conflicting — how can we help each other?

Atfer all, the big win (Kim’s “Identity Big Bang”) will come when the experience for the user (and the organization) is one consistent ceremony and paradigm for understanding how to safely use a digital identity in the context of all the transactions for which it may be needed. Sort of like we do for credit cards today.

We just don’t want it to take 10 years to get there…

Posted in Blogging, General, OpenID | Leave a comment

Paul Madsen on OpenID & SAML Convergence

Posted on 11/10/2006 by Drummond Reed

Paul Madsen, a key Liberty architect, has posted a wonderful insight about the relationship of OpenID and SAML. He plots both of them against the axes of:

  • The selectivity of an OpenID relying party (a website that accepts OpenID logins, also called an RP) about the OpenID identity providers (IdP) the RP will accept OpenID authentication from, vs.
  • The level of security the RP needs (think blog comments vs. banking).

Paul’s graphic illustrates that while both OpenID and SAML have their respective sweet spots today, the real potential is for the two to converge on a much bigger sweet spot that could handle the whole gradient.

I for one find this prospect very exciting. I don’t for a minute think it will be easy, or that it can happen overnight. But the synergies are growing so fast — and the prospects of a unified user-centric identity layer so compelling — that what only a few months ago seemed improbable is starting to look inevitable.

I expect this to be a major locus of discussion at the Fall Internet Identity Workshop Dec. 4-6 in Mountain View. Don’t miss it.

Posted in Blogging, General, I-brokers, OpenID | Leave a comment

Eve riffs on SAML, OpenID, XRI, and privacy

Posted on 10/23/2006 by Drummond Reed

In my book Eve Maler’s about as cool as it gets. XMLGrrl was not only one of the inventors of XML, but deeply understands many of its richest applications from DocBook to SAML. And she’s been a pioneer in applying all of this to the challenge of Internet-scale digital identity.
Her latest blog entry on Pushing String (“The future’s so bright I gotta wear shades“) explores a number of recent developments by Jeff Hodges, Scott Cantor, and Peter Davis for lightening up SAML to make it easier for developers who are jazzed about OpenID. In it she asks about the new “directed identity” feature:

I tried figuring out if the OpenID V2.0 work includes this approach [directed identity] as a possibility for URL-based identifiers, and it appears to go part of the way, though the underlying purpose seems to be different. Revision 10’s Appendix C.1 says “Supports IdP-driven identifier selection. This new variation of the protocol flow is initiated by entering an Identifier for an IdP instead of an Identifier for an End User, and allows the IdP to assist the End User in selecting an Identifier.” But I’m having trouble finding where in the normative spec this is defined.

Although I’m not one of the editors, I have worked quite a bit on this feature in the 2.0 spec and I apologize if it’s not clear in Draft 10. However Eve is exactly right: starting with OpenID Authentication 2.0, a user will have two options for logging into an OpenID-enabled site: with their personal identifier, or with the identifier of their OpenID provider (IdP). If the user chooses the latter option, the IdP will let the user choose the identifier they want to share with the site — anything from a specific persona to a one-time URL/XRI generated by the IdP just for this relationship.

This will significantly increase the privacy options available under OpenID. Add this to the prospect of new ways to converge OpenID with SAML, and it’s no wonder Eve is singing this merry tune!

Posted in Blogging, General, OpenID, Privacy, XRI | Leave a comment

Blog-Driven Micromarketing

Posted on 10/17/2006 by Drummond Reed

I receive a contact request through my contact page today to look over a new published guide to preventing identity theft at the Your Credit Advisor blog by Jimmy Atkinson. Not knowing the site, I didn’t know what to expect, but the article impressed me — it even detailed some risks I had not been aware of.

What also caught my eye was no ads. I had to search the site to see that what they are doing is producing leads for credit card applications. I’d never seen all the credit card options laid out this way (they actually get their info from CardOffers.com), but this site performs a real service just by making all this info so easily accessible.

I expect we’ll see much more of this form of blog-driven micromarketing.

Posted in Blogging, General | Leave a comment

Identity in context

Posted on 9/29/2006 by Drummond Reed

“Context” has become the second-most-commonly used word in the identity industry after “identity” itself. And rightly so, since its practically mantra now that identity only exists in context, and — at least for people — is so incredibly context-sensitive.

Paul Madsen, editor of many of the Liberty Alliance specifications, gives a good example of this when he blogged about how I identify myself in the context of different specifications of which I am an editor or contributor. We all do the same thing when we consciously choose which affliations (if any) we list on a business card, a sign-in list, a conference badge, etc. (The irony of the particular example Paul gives is that Peter Davis, who wrote the SAML XRI Authentication Service specification at XDI.org, was the one who decided what addresses would be used 😉 )

But Paul’s right: one of the very most basic ways in which individual’s control their identity is by the affiliations they reveal (or not) in the addresses they use. Email addresses, for example, may or may not place an individual within the context of a particular community or company. me@personal.name.example.com asserts a personal context, whereas me@company.name.example.com asserts a company context (particularly if the company name is recognizeable to the reader).

Wouldn’t it be nice if you could could always have 100% control over the context in which you were asserting your identity? In other words, I could be =drummond.reed in a global context, but then assert myself as:

=drummond.reed@cordance
=drummond.reed@oasis
=drummond.reed@xdi.org

That’s one of the key features we’re working on for i-names.

Posted in Blogging, General, XRI | Leave a comment

XDI Round Two

Posted on 9/15/2006 by Drummond Reed

As I found myself explaining to a number of folks at Digital ID World this week, the XDI Technical Committee at OASIS has been relatively quiet this spring and summer while so many of the TC members worked on: a) completing the XRI 2.0 suite of specifications, and b) bringing up fully operational XRI infrastructure, including the XDI.org Global Registry Service and the initial set of XDI.org-Accredited I-Brokers.

Now that this has been accomplished, it’s time for the XDI TC to kick back into high gear and start putting out the XDI 1.0 specification suite. In many ways the job has become easier because we’ve learned so much from XRI infrastructure, plus cross-domain data sharing requirements are becoming much better understood through projects like Higgins.

I had a great chance to talk XDI with Johannes Ernst at Digital ID World, who has been developing a framework called InfoGrid that uses many similar concepts. He blogged his initial impressions, and I encourage Johannes and any other distributed data architects who would like to help in the birth of a universal data interchange protocol to join us on the XDI TC as we ramp up our work again this fall. If you have any questions just drop me a note through my contact page.

Posted in Blogging, General, XDI | Leave a comment

Doc sucks

Posted on 9/13/2006 by Drummond Reed

I want you to know right away that I’m writing this post to boost Doc‘s Google suckiness rating. It was revealed during his closing keynote at Digital ID World today that his suckiness rating is only 1/3 of that of Cingular, which is 1/3 that of Verizon. Bob Morgan discovered this when googling Doc during his talk (and shared that as part of the audience participation portion of the talk, to gales of laughter.)

Given how amazing Doc is, I couldn’t let him suffer from that low suckiness rating, so I’m giving him as big a boost to his suckiness rating as I can.

With that established, Doc’s main point today was that the main action in identity is going to happen on the Live Web and not the static web. The reason is that the Live Web will help drive the Intention Economy, and the Intention Economy is a whole new frontier. The Intention Economy has no marketing or advertising — it’s about sales. It’s the “upside down buyers guide” — the buyer specifying what they want, and the vendor producing it. All the world of advertising and marketing is an outmoded way to try to get attention from consumers when we really should be helping those customers who are ready to buy.

So what we need are tools for relating – helping customers and suppliers relate. We don’t really need “identity management” products and services — we need relationship management products and services.

Posted in Blogging, General | Leave a comment

The Limited Liability Persona (LLP)

Posted on 9/13/2006 by Drummond Reed

In Jamie Lewis‘s talk at Digital ID World this morning, one idea stood out as a real mind-bender: the Limited Liability Persona (LLP). Jamie was careful to give credit to several folks from the Burton Group who came up with this idea: Mike Neuenschwander & Lori Rowland. I captured the high-level bullets from Jamie’s slide on this concept:

  • Individuals can have multiple LLPs, each for different modes, roles
  • Compromised LLPs can be shed under certain circumstances
  • Could even be sold, like an online game idenity
  • But LLPs don’t absolve us of civic responsibility, criminal liability
  • Reputation damage, other consequences much like the physical world
  • Legal symmetry between all parties

This is a fascinating new idea that gibes very closely with the emerging new industry of i-brokers. I’m going to give this one a deep think.

UPDATE 2008-01-04: Jaco Aizenmann, XDI.org trustee from Costa Rica and founder of VirtualRights.org, has in fact been advancing the concept of a legal “virtual personality” (the best English translation of the Spanish term for “digital identity”) for years now. He has been a passionate advocate since I first met him in 2003 that virtual personality should be a full-fledged legal entity at the same level as a corporation, LLC, sole proprietorship, etc. He helped pioneer the concept in Costa Rica and organized the Virtual Personality forum held at the Costa Rican Congress, 10 May 2005. To my knowledge Costa Rica is the first country considering a constitutional amendment to recognize virtual personality/digital identity as a first class legal entity. You can read more about the legal concept on the virtual personality page at Identity Commons. I look forward to more updates on this from Jaco.

Posted in General, Identity Rights Agreements, Limited Liability Persona, Privacy | 1 Comment

Microsoft makes the promise

Posted on 9/12/2006 by Drummond Reed

Today Microsoft made good on the promise that Kim Cameron and Mike Jones made to the Identity Gang members many months ago: that the IPR necessary for CardSpace (formerly InfoCard) would be made available so that anyone, on any platform, using any license (yes, even GPL), could use it.

But it goes further than CardSpace — it’s the for the WS-* stack (well, most of it — there are still a few more details on coverage to work). They call it the Open Specification Promise, and it’s worth reading in depth. Johannes Ernst has a more detailed post that points to additional coverage.

On a personal basis, I just want to give Kim and Mike a giant high-five for perservering with what many thought was a near-impossible task. They deserve a standing ovation.

Posted in General | Leave a comment

I-names for anything you want

Posted on 9/12/2006 by Drummond Reed

I-name forwarding service is finally here! At last we’re tapping some of the power of XRI resolution infrastructure — and demonstrating why I named this blog “=drummond”. Following is the new i-name of my blog:

http://xri.net/=drummond/(+blog)

And following is the i-name for my current work context, whatever that may be at any point in time (currently Cordance Corporation):

http://xri.net/=drummond/(+work)

Both examples use the very simple first-generation XRI tag dictionary (+names) that’s in the XDI.org Forwarding Service specification. The advantage of +names is that as the +tag dictionary grows (and the XDI.org community has grands plans for how to do this), it makes it easy to find what you’re looking for without having to guess what someone else called it. (It also explains the funny parentheses — “+blog” is its own separately-resolvable XRI, and the parentheses tell an XRI parser this. To make it easier for people to type in an address bar, it will actually work without the parents, i.e., http://xri.net/=drummond/+blog.

But a forwarding XRI doesn’t have to use an i-name dictionary — it can also use standard HTTP URI path and query syntax. For example, I created the following XRI…

http://xri.net/=drummond/sws

…just so I never have to remember the website name for my son’s school (Seattle Waldorf School).

Finally, a simple way I can manage the names I want for anything on the Web I want.

Posted in Blogging, General, Practical I-Names | Leave a comment

Bob Blakely: What is Privacy?

Posted on 9/12/2006 by Drummond Reed

This is the title of Bob’s talk at Digital ID World today. Now that he’s at the Burton Group, Bob can really run with his paradigm-inverting views about information systems as they really work in society.

Bob answers the question, “What is privacy?”, this way:

“The ability to lie about yourself and get away with it.”

Bob notes that this does NOT mean the right to lie about yourself and get away with it, just the ability. He places this startling definition of privacy in the context of what he calls the “Identity Oracle”, which is his name for an identity provider (“i-broker” in i-names parlance). What Bob contends is that if an individual designates an i-broker as authoritative, the i-broker should be able to protect the user’s privacy by actively giving out falsified data in response to questions that a third party (typically called the relying party) should not ask. In Bob’s model for an Identity Oracle, anyone can ask it about any identity for which the Identity Oracle may have information. The ability for the Oracle to respond with a lie is simply a very clever defense against parties asking for information who have no legitimate right to ask for it. Bob uses a great quote from Sir Winston to explain this rationale.

“In wartime, trust is so precious that she should be attended by a bodyguard of lies.”

-Winston Spencer Churchill

Talk about a head-banger. As always, I’m going to be thinking about this one for weeks.

Posted in General, Privacy | Leave a comment

$5 i-names — Now That's Practical

Posted on 9/12/2006 by Drummond Reed

I haven’t posted for a month. Beside’s the fact that it was August (a sacred month in Seattle), it was also prep for Digital ID World this week in Santa Clara, where XDI.org-accredited i-brokers are introducing support for OpenID 1.1, as well as interoperable contact and forwarding services.

And during the three days of the show (Monday-Wednesday), you can register a 1-year global personal i-name (=name) from any XDI.org-accredited i-broker for just US$5.00. A true personal digital address you can keep for life for less than a domain name.

Now that’s practical.

P.S. During this special, 1id.com is also running a special contest this week for a U2 iPod. Just submit your idea for the coolest i-name application.

Posted in General, Practical I-Names | Leave a comment

Kvetch with Kveton

Posted on 8/10/2006 by Drummond Reed

Scott Kveton is not only the new CEO of JanRain (he was formerly the head of the OSU Open Source Lab), but he’s started a new blog that’s rolling a mile a minute. JanRain is the leading developer of OpenID libraries and also an XDI.org-accredited i-broker — plan on lots of cool stuff coming from them as they start working their way up the OpenID 2.0 stack.

Posted in Blogging, General, I-brokers, OpenID | Leave a comment

Johannes on XRI resolution

Posted on 8/10/2006 by Drummond Reed

Johannes Ernst just created an excellent blog post out of an email dialog he and I had about the “big picture” of XRI resolution. It’s true that the concept of an identifier resolution network based on HTTP that parallels the DNS resolution nework based on UDP is unusual at first. But for RESTful architects like Johannes, the lightbulb goes on when look at the power of using the HTTP layer to do for digital identification what the DNS layer did for host naming — especially leveraging the simplicity and extensibility of XRDS documents (the XML format returned by an XRI resolution request, and also the format used by the Yadis URL service discovery protocol of which Johannes was the co-instigator.)

As the XRI Resolution editor’s team starts work this month on what we hope is the final working draft of XRI Resolution 2.0 (currently at working draft 10), I plan to blog more about other key features of XRDS documents — CanonicalIDs, Refs, ProviderIDs, and Service Endpoints — that all help solve higher-level identity and trust problems at a layer higher than DNS was intended to function, much like DNS solved a set of problems of logical naming and redirection at a layer higher than IP addressing was intended to function.

Posted in General, XRI, Yadis | Leave a comment

More on I-Cards and I-Names

Posted on 7/27/2006 by Drummond Reed

Paul Trevithick let me know that the notes from the i-card session at the Berkman Identity Open Space last month are posted at http://wiki.idmashup.org/I-cards.

I continue to find it very helpful to make the distinction between address-based identity and card-based identity. It helps me gives much shorter and more understandable answers to questions like “What’s the difference between an i-card and an i-name?”

It also makes it much easier to talk about how an identity framework like Higgins will work with both forms of identity. Paul’s understood this intuitively all along, which is why he’s been creating a pluggable framework to help developers write identity-empowered applications, no matter whether the underlying systems/protocols are address-based or card-based.

 

Posted in General, I-Cards | Leave a comment

INITECH Goes Live with I-Services

Posted on 7/12/2006 by Drummond Reed

INITECH is the first XDI.org-accredited i-broker to provide three i-services for their i-name customer — they just went live with SAML-based i-name Single Sign-On (i-SSO), Contact and Forwarding services.

You can see these services at work with their own i-name, @greenbutton. You can visit their contact page at http://xri.net/@greenbutton and see how contact requests are authenticated with either an i-name or email address, effectively eliminating spam (more on that subject in a future post).

Note that only SAML authentication is available currently, but OpenID authentication will be available by September. I-names will be the first digital address to support both SAML and OpenID authentication.

For more about Greenbutton, INITECH’s i-broker service, visit them at http://www.gbtn.biz/.

Posted in General, I-brokers, Practical I-Names | Leave a comment

I-Cards: Convergence on a Metaphor

Posted on 7/12/2006 by Drummond Reed

At the Berkman Identity Mashup two weeks ago, at an open space session proposed by Paul Trevithick (“Professor Higgins” ;-), the Identity Gang reached consensus on a fundamental metaphor for interoperable identity systems: the i-card.

This consensus was rooted on the fact that, at least in English, the noun “card” (in the general context of communications) is widely understood to mean “a container of information”, or even more specifically, a “container used for purposes of sharing or exchanging information”. This differentiates it, for example, from the term “page”, whose connotation is more of a fixed set of information available for viewing, such as “a page in a book” or “a web page”.

Why the “i”? As Doc Searls put it in the discussion, “A metaphor describes how something is like something else, but not exactly the same as something else.” So the “i” in “i-card” serves the same purpose as the “e” in “e-mail”: it’s a way of suggesting that an i-card is a metaphor to a physical card, such as an ID card, business card, or credit card, but not an exact duplicate. Dale Olds of Novell pointed out that this is just like the graphic folder metaphor used by most file systems: it is similar to a physical file folder, but not the exact equivalent.

When it comes to cards, “i” word better than “e” for all the same reasons it does for “i-name” and “i-broker”, namely that it connotates and abbreviates:

  • identity—the assertion of equivalence to something that exists elsewhere (in meatspace or headspace)
  • information—what is exchanged using the card.
  • internet—the medium of exchange in the broadest sense.
  • intelligent—in a digital format, the card can be “smarter” than paper.
  • I—the English word for “first person singular”, which in a strict identity graph context can be though of as “the implicit starting node for any relationship”.

This consensus has been badly needed because the Identity Gang (as a loose proxy for the Internet identity community as a whole) has been struggling to settle on a common metaphor for how to describe the set of information that is exchanged in the context of establishing a identity relationship.

The primary need for such a metaphor, as everyone at the session agreed, is to enable consistent user experience—something that is all but impossible without a simple, universal conceptual model users can grasp. The importance of his factor is captured in Kim Cameron’s 6th Law of Identity. Kim has often explained that Microsoft originally chose the card metaphor because it was such a clear analogy to the familiar experience of showing a physical identification card such a driver’s license or credit card. (Microsoft was not the first—Novell’s DigitalMe initiative featured “meCards” all the way back in 1999, and undoubtably there were others before that.)

A related lingering problem was also solved a few weeks ago when Microsoft choose the name “Cardspace” for its implementation of the WS-Trust-based authentication and attribute exchange infrastructure that has been code-named “InfoCard” for the past few years. Suddenly the pieces all line up: i-card as the generic term for “a container of information exchanged for the purpose of identifying or describing the parties to a relationship”, and Microsoft Cardspace as the trademarked name for Microsoft’s specific implementation of i-cards using a specific protocol (WS-Trust) on a specific platform (Windows).

As big a problem as this solves for consistent user experience, I have a different reason for believing it is a profound step in the evolution of interoperable Internet identity. For me it solved of a longstanding identity conundrum I liken to the longstanding debate in physics, “Is light a particle or a wave?” In the end the answer was mu (“unask the question”), because it turned out light could be treated as either a particle or a wave. Both were valid models and the one to use depended on the problem being solved.

Translated to identityspace, the analogous question has been: “Is identity an address or a card”? Or to use the new terminology, “Does one establish an identity using an i-name or an i-card?” At long last this question can be answered exactly the same way the physicists did: mu! Both are valid models and the one to use depends on the problem being solved.

In a session about i-brokers at the Berkman conference, I described the difference between “address-based identity” and “card-based identity” this way:

  • Address-based identity can have the property of being “resolvable”, i.e., a digital address can serve not only to identity a digital subject, but when needed, as a way of enabling further discovery about or communication with the subject. Address-based identity is required, for example, when two parties need to establish a bi-directional messaging relationship (email, phone, IM).
  • Card-based identity has the property of being descriptive, i.e., of being able to represent attributes, claims, or other metadata and data associated with a digital subject. Card-based identity is required, for example, when a relationship is predicated on one or both parties having certain attributes.

From these descriptions, two conclusions immediately fall out:

  1. These two forms of identity are not mutually exclusive, i.e., an address-based identity can be used to discover/request a card-based identity, and a card-based identity can contain one or more address-based identities.
  2. Neither form inherently implies or requires the other, i.e., an address-based identity does not mean that a card-based identity is available (or, if available, that a contact has access to it). Nor does a card-based identity mean that an address-based identity is available (or if available, that a contact has access to it).

Whatsmore, both address-based identity and card-based identity can be further classified in some very helpful ways:

  • Address-based identities can be broken into resolvable and non-resolvable. While an address-based identity is always unique in the address space in which it is assigned, that doesn’t necessarily mean it can be resolved, i.e., dereferenced via a mechanism or protocol that provides further discover or communications with a digital subject. An email address is a good example of the former; a browser cookie a good example of the latter.
  • Card-based identities can be broken into addressable and non-addressable. This means that some card-based identities may contain an address-based identity and some may not. A business card is the classic example of an addressible card-based identity; in fact the primary purpose of most business cards is to share address-based identities. On the other hand a coffee-shop loyalty card is a good example of a non-addressable card-based identity: while it describes identity-related attributes of its owner (how many cups of coffee they have purchased), it may not contain any address-based identity whatsoever (not even your real-world name).

With these distinctions made clear, we can now propose an “Eighth Law of Identity”:

An interoperable identity metasystem must support both address-based identities (resolvable and non-resolvable) and card-based identities (addressable and non-addressable).

In other words, i-names and i-cards will not only co-exist, but they are highly complementary. For example, i-names can be used to request i-cards and i-cards can be used to share i-names. And both can be more user-centric and privacy-protecting than anything we have in the physical world, or even anything else that we have developed in cyberspace to date.

And i-brokers, for their part, can provide both address-based identities and address-based identity services and card-based identities and card-based identity services—and all of them can live happily ever after together.

And the clouds part and the sun comes shining through just like it did through the leaves of the elm trees where we sat outside the MIT Media Lab for the i-card open space session. Sometimes it takes the light of many minds shining on a subject to make it clear to all of us.

Posted in General, I-Cards, XDI, XRI | 2 Comments

Inflection (and Reflection) Points

Posted on 7/12/2006 by Drummond Reed

Every so often we reach what seems to be one of those special inflection points in time: a period that acts like a gravity field for change. June was such a month for me. First my oldest son graduated from Seattle Waldorf School. Then we launched the i-names global registry service at the Berkman Identity conference. I returned that weekend to Seattle to begin preparation for my brother’s wedding the following week, only to learn the news that my mother passed away from advanced emphysema. We put together a beautiful service for her, followed the next day by my brother’s wedding, which was equally inspiring.

But by the 4th of July it was time to just take a deep breath and watch the fireworks dissipate into the clear night sky. I’ll be digesting these events all summer.

In the meantime, however, this digital identity infrastructure we’ve been building is starting to happen for real. It’s like finally beginning construction on a large bridge once all the engineering and site prep is done: each new piece put in place enables many more pieces to be put into place. Having a full commerical-grade global XRI registry/resolution service up and running is just such a step. This summer I plan to start blogging more about some of the other pieces XRIs and i-names can now fit into.

Posted in General | Leave a comment