Equals Drummond

I could spend this entire week doing nothing but reading and posting about good post-holiday reading of recent blog posts. My theory is simple: over the holiday break, people (well, most people – not me this year) have time to take a breather and write down something that’s really been on their minds.

And because they are not rushed, they have time to condense and sharpen their thoughts, and the result is a rash of excellent blog posts.

A wonderful example is Will Norris’ post about identity and identifiers. He speaks from long experience (and he’s worked on several identity protocols, including OpenID and SAML, as part of the Shibboleth project).

Read it and weep (if you have a recyclable OpenID).

(Aside: Although, as Will’s article intimates, XRI architecture solves this problem at the structural level, the implementation of XRI across OpenID 2.0 sites and libraries is currently very uneven. So IMHO realistically a full solution to the recyclable identifier problem with OpenID is still another protocol generation away.)

The Craig Burton is at it again. Putting together all kinds of cool memes. This time he’s seen how to splice XRI into the FollowFriday endorsement system for Twitter. He calls the concept “microtagging” – using XRIs in the tag space (+plumber, +doctor, +analyst, etc.) to categorize FollowFriday endorsements for aggregation on Scott Lemon’s TopFollowFriday aggregator.

Blows my mind. Who ever thought the structured semantic web would start evolving on Twitter?? But that’s just how this organic Internet thing happens…

More about the long quiet spell soon. First I must post about a trip I made last week to spend the day with Phil Windley, his partner Stephen Fulling, and the inimitable Craig Burton down in Salt Lake City.

What Phil and company are doing at Kynetx is earthshaking. There’s not much info on the website yet, but last week Phil posted a white paper The Advent of Next Generation Browsing that introduces the whole concept of structured browsing. I won’t even bother to try to explain it here; just get the paper and read it. Then read another one of Joe Andrieu’s exceedingly cogent essays with his impressions, criticisms, and suggestions about the Kynetx vision of structured browsing and how it fits with Joe’s work on search maps. Also read Phil’s reply to Joe.

The rules language Phil wrote (KRL – Kynetx Rules Language) is at the heart of their solution for structured browsing. I am a huge fan of what rules languages can do with structured identifiers and structured information. That’s what I was down in Salt Lake talking with Phil, Stephen, and Craig about. Phil followed it up with a great post, First Class Namespaces in Programming Languages, that sums up how XRI and XDI might fit with KRL.

Did I say earthshaking? Watch out when this quake breaks loose.

Something else so good I just have to blog it: Eran Hammer-Lahav’s Discovery Coordination Report on the new metadata-discovery list he set up. Eran’s turning into a one-man hub of all things discovery as he drives forward together with the rest of the OASIS XRI TC towards the pushing out the new XRD 1.0 spec.

I have high hopes for this spec and Eran is one of the key reasons (plus the efforts of his co-editor Nat Sakimura of NRI, who is working OpenID miracles in Japan, and other new TC members who have joined to finally make simple, safe, uniform metadata discovery a reality on the Web).

For most people, watching the evolution of technical specifications is like watching a glacier move. To those of us living the process, though, there can be a great deal of drama to it — in fact it’s much more like climbing an icefall inside the glacier (anyone doubting how much adrenaline that takes should read John Krakauer’s description in Into Thin Air of climbing Mt. Everest’s Khumbu Icefall). For example, the failure of the OASIS Standard vote on the XRI 2.0 specifications last May — the first ever in 40+ OASIS Standard votes — was a watershed in the interaction of two standards bodies (W3C and OASIS).

The repercussions from that event have been equally unpredictable. Who would have thought that just four months later the XRI TC and W3C TAG would have rough consensus on how to resolve their differences? Or that the discussions would spill over to the much larger topic of uniform metadata discovery on the Web? Or that discovery could turn out to be the key to building identity into the browser? Or that interest in the XRDS discovery format would boil up enough to beget a new spec intended for uniform metadata discovery for any type of URI or XRI?

But that’s just what has happened. Two weeks ago at the Internet Identity Workshop, Eran Hammer-Lahav, author of the OAuth Discovery spec and founder of the XRDS-Simple list, led a marathon session on a new uniform metadata discovery specification to be called XRD 1.0. With 20 to 40 people in attendance all afternoon, Eran first ran through his exhaustively-researched blog post on HTTP and discovery, then through the proposed simplifications to the current XRDS/XRD schema. By the end there was rough consensus on XRD as a mechanism for uniform metadata discovery across all the different Internet identity and data sharing specs that need it (XRI, OpenID, OAuth, OpenSocial, XDI, Data Portability, etc.)

The name “XRD” is itself quite revealing of the evolutionary path to this point. When the OASIS XRI TC first developed the XML-based metadata discovery format we needed for XRI resolution back in 2003, we called it XRID (XRI Descriptor). We made it as simple and generalized as we could simply because any resource could have an XRI, so there was no telling what type of metadata might be needed over time. We focused primarily on one clear requirement: given input identifier x and service type y, define how to discover service endpoint URI z.

By 2005, when OpenID grew to the point of needing a discovery format, the authors of the Yadis (Yet Another Discovery spec) authors looked at XRID and saw something very close to what they needed. But XRID assumed you needed a sequence of descriptors corresponding to an XRI resolution chain. With OpenID a sequence wasn’t needed because an http(s) URI would have just one descriptor. So the XRI TC renamed the metadata format to XRD (Extensible Resource Descriptor) and created a separate XML wrapper element called XRDS (XRD Sequence) for cases like XRI resolution where you needed to wrap a sequence of XRDs.

However for cross-compatibility between XRI and OpenID, OpenID discovery just assumed the outer XRDS wrapper element even if it contained only one XRD. So the discovery format became widely known by the wrapper element, XRDS.

It wasn’t until Eran’s deep-dive on uniform metadata discovery that he recognized that the base case should be the other way around, i.e., for most URIs the the base discovery document should be an XRD, and only in cases like XRI resolution do you need the XRDS wrapper element.

Since the XRI TC had already made the decision in our next round of specs to split off XRDS from XRI Resolution, it was easy to just call this new specification XRD 1.0 (”1.0″ reflecting that it is the first standalone specification for XRD). However what we didn’t realize until the XRI TC F2F meeting the day after IIW was that XRD as both a metadata discovery format and protocol would be comprehensive enough that XRI 3.0 Resolution could become simply a “profile” of XRD 1.0 — and thus dramatically shorter.

We also didn’t realize how badly many different stakeholders want a Web-wide metadata discovery mechanism. Within a week after IIW we had six new people join the XRI TC to be part of the XRD work, and as of this writing nine more are in the queue.

So the roadmap of the next generation of XRI TC outputs is clear now. We will produce two OASIS Standard-track specifications:

• XRI 3.0 (including Syntax, Resolution, and Bindings) as a uniform syntax and resolution protocol for shared semantics across hierarchical URI schemes.
• XRD 1.0 for uniform metadata discovery for any URI or XRI.

Stay tuned for updates – hopefully this set of specs will set a glacier speed record.

Nat Sakimura, who is quietly implementing real user-centric identity solutions in the Japanese market while many others are still talking about them, has posted his concise reasoning why XRI abstract identifiers are the the only really safe identifiers to use with OpenID.

The whole question of the differences between abstract and concrete identifiers, currently being explored in depth in conversations between the W3C TAG and the OASIS XRI TC, may turn out to be a crucial one for the soon-to-begin work on OpenID 2.1. When it comes to security, privacy, and usability, the differences really start to add up.

Someday I’m going to write a book about primary challenge with disruptive technologies: they are always starved for resources. In fact, you could argue this chicken-or-egg problem is what defines a disruptive technology: it can’t attract enough development resources until it has proven its value, and it can’t prove its value until it has attracted enough development resources.

The effective result: a small group of people (who most of the rest of the planet consider to have at least partially lost their marbles) keeps pushing the disruptive technology forward in niches until – poof! – suddenly it’s mainstream.

As you might guess, this brief diatribe was inspired by a message I received from an OpenID developer this morning:

I’ve now read a lot about XRI, and I still just don’t get it. Do you know of any good resources that explain the flow of XRI’s?

ARRRRGGGHHHH! The question hits right between the eyes because I think of all the detail in the XRI Syntax 2.0 and XRI Resolution 2.0 specs, and all the implementation work that has been done and XRI services being delivered, and yet, I still can’t just point to a good XRI in a Nutshell guide (to borrow the standard O’Reilly name for such guides) needed by the vast majority of developers being exposed to XRI for the first time (such as through OpenID).

And I know why: the relatively small community that developed the XRI specs, early implementions, and infrastructure services just hasn’t had had the resources. We keep talking about the need for it but it keeps taking a back seat to either: a) our day jobs so we can keep from starving, or b) the need to keep pushing forward XRI specs/implementations/services so that it can succeed.

Enough of this rant. In the spirit of continuous improvement, I’ll leverage the power of personal publishing simply by blogging the answer I sent back in email this morning. Hopefully this will become the seed of a real XRI in a Nutshell document within the next few months. Keep in mind this is for developers familiar with OpenID, which assumes a basic knowledge of DNS. A little XRDS knowledge helps too.

—-

XRI IN A (REALLY SMALL) NUTSHELL

XRI is an identifer and resolution infrastructure just like DNS, except that it operates at a higher abstraction layer, just like DNS operates at a higher abstraction layer than IP addressing. XRI is to URI addressing (of any kind) what DNS is to IP addressing.

At the DNS layer, the resolution protocol is UDP. At the XRI layer, the resolution protocol is HTTP (or HTTPS for security – more on that below).

In DNS, you resolve a domain name to an RR (Resource Record). In XRI, you resolve an XRI to an XRDS document.

In DNS, the server hosting RRs for DNS zones is called a nameserver. In XRI, the server hosting XRDS documents for XRI authorities is called an authority server.

Just as DNS names can delegate to other DNS names (e.g., in www.yahoo.com, com delegates to yahoo delegates to www), XRI authorities can delegate to other XRI authorities. In XRI the delegation characters are not dots but * (for reassignable XRIs, called i-names), and ! (for persistent XRIs, called i-numbers). So the XRI i-name =drummond*foo is a delegation from my XRI authority to another one called foo. And the XRI i-number =!F83.62B1.44F.2813!24 is a delegation from my i-number to another one called 24. (Authority delegation is handled in XRDS documents using the service type xri://$res*auth*($v*2.0).)

In the resolution spec, we define two kinds of XRI resolvers: local and proxy. A local XRI resolver is just like a local DNS resolver: you call it with an XRI and a set of resolution parameters (like the service type you’re looking for and whether you want it to use trusted resolution or not) and it gives you back (depending on what function you call) the entire XRDS, the final XRD, the final XRD filtered for only the service you want, or just a list of URIs from that service. A reference API for a local resolver is provided in Appendix F of XRI Resolution 2.0.

A proxy resolver is simply an HTTP(S) interface on a local resolver, so you can call it over the net like a service. This interface is defined in section 11 of XRI Resolution 2.0. To call a proxy resolver, you embed the XRI you want to resolve in an HTTP or HTTPS URI and then add query parameters to control the resolution result you want back. The resulting HTTP(S) URI is called an HXRI.

The ABNF for an HXRI is in section 11.2 of XRI Resolution 2.0. But it’s really simple: a) you create a prefix of http://xri.*/ or https://xri.*/, b) you append the XRI you want resolved as the path (without the xri://, and c) you add any XRI query parameters.

http://xri.net is just a XRI proxy resolver run by XDI.org as a public service (NeuStar actually operates it). But there are other proxy resolvers, for example, http://xri.freexri.com (see @freexri for more). Anyone can run an XRI proxy resolver just like anyone can run a DNS server. There is no one authoritative proxy resolver.

So when you see http://xri.net/=drummond in my email sig, that’s an HXRI. It’s jus the way to ask the the http://xri.net/ proxy resolver to resolve the XRI =drummond. If you don’t give it any resolution parameters, what the proxy resolver will return is a 302 redirect to the HTTP(S) URI for whatever resource I have designed to be selected as my default service (in my case, my contact page at http://2idi.com/contact/=drummond). But if you add resolution parameters, you can get back anything the proxy resolver supports. For example, the following HXRI will give you back my XRDS:

http://xri.net/=drummond?_xrd_r=application/xrds+xml

Lastly, since you bring up security, there are two key trust features of XRI infrastructure that are good reasons to use XRI with OpenID Authentication 2.0. The first is trusted resolution. XRI infrastructure supports three modes of trusted resolution: 1) all-HTTPS resolution calls (meaning every step of the resolution chain across delegations uses HTTPS automatically), 2) SAML signatures (meaning every step of the resolution chain returns an XRDS with a SAML signature), and 3) both HTTPS and SAML. See section 10 of XRI Resolution 2.0 for details of all three. (Note: HTTPS is supported by 100% of the XRI authority servers I know of, but SAML support has so far has been limited to special cases.)

The big advantage is that since XRIs are abstract identifiers, any OpenID RP can choose to use 100% HTTPS resolution every time it is given an XRI. That means XRI users never have to type https:// or do anything special at all to always have the benefit of a secure identifier. I should be able to type =drummond into any OpenID RP and have it always use HTTPS to resolve it.

The second key trust feature is that XRI infrastructure has a fundamental solution to the OpenID recycling problem. (See this short ACM paper for a full explanation of this problem.)

Since XRI infrastructure supports synonyms (different identifiers that identify the same target resource), all XRI infrastructure rooted in the XRI registry services offered by XDI.org have the operational requirement to assign persistent i-numbers for every i-name registered (at any level) and to never reassign those i-numbers to another registrant. No recycling. For example, both my i-names =drummond and =drummond.reed have the i-number synonym =!F83.62B1.44F.2813. That’s will always be my OpenID claimed identifier to any RP where I sign in as either =drummond or =drummond.reed. It will never be reassigned even if I let both those i-names lapse.

Unlike the URL hash solution to persistent identifiers in OpenID, the XRI solution has the advantage of being fully portable. Even if I let my i-names lapse, I still have full control of my i-number =!F83.62B1.44F.2813 forever.

For example, I can transfer it to any i-broker just like you can transfer a domain name to any domain name registrar. The “elephant in the living room” of the URL hash solution to OpenID recycling is that a hash like https://i-own-this-domain.com#1234 is absolutely worthless if i-own-this-domain.com is reassigned to a new registrant (which, as we know, can happen with a DNS name for all kinds of reasons, not all of which a registrant can control). Now the new registrant totally controls the whole URL hash space! Your “secure” OpenID identifier has been completely compromised.

So the truth is that the hash URL solution only works for very large providers where you can be reasonably sure that for example http://yahoo.com or http://aol.com is not going to sell out to someone that’s going to start reassigning yahoo.com or aol.com hash URLs. But for all the smaller providers – and mostly for all the individuals that would like to have their OpenID URL based on their own domain name – it doesn’t work at all.

—-

Lastly, besides the links above, another site I recommend for more info on XRI is Markus Sabadello’s @freexri site. Markus is one of the lead developers of the OpenXRI project (a Java implementation of XRI resolver/authority server/proxy server).

Boeing has long been one of the most progressive companies when it comes to identity management and how it can enable new value chains in a large ecosystem. Marty Schleiff is one of the reasons. I’ve worked with him extensively on the XRI Technical Committee at OASIS, but Marty’s involved with pretty much every aspect of identity and directory services at Boeing.

Marty’s new blog is called Identity Happens. It was motivated by his idea of creating something like an OSI reference model for identity. Give it a read — this is going to be a great discussion.

It was stunning. 10 days ago, a few days after the voting period began on XRI Syntax 2.0 and XRI Resolution 2.0 becoming an OASIS Standard, the W3C TAG (Technical Architecture Group) came out with a statement recommending that members of OASIS – a completely separate and independent standards body – vote against it.

Despite 20 votes already being cast in favor of the specifications at that point, almost immediately a handful of negative votes were cast with comments referencing the W3C recommendation, starting with Sun Microsystems (especially ironic since Eduardo Gutentag of Sun is chair of the OASIS Board of Directors).

Although it’s not unusual for a proposed OASIS standard to have some opposition, what is strange is to have that opposition led by another standards body. What took the XRI TC even more by surprise, however, was the W3C’s sudden vocal opposition to XRI 2.0. When the W3C TAG submitted a comment on the last day of the first public review period of the XRI Resolution 2.0 specification in March, the XRI TC responded with a detailed 5-page answer to the three questions posed by the TAG. We never received any response.

In a subsequent final public review of XRI Resolution 2.0 held the following month, we didn’t hear anything more from the W3C TAG. Nor did the TAG minutes show any further discussion.

In any case, the XRI TC posted a response to the TAG’s position, and OASIS members responded by casting more positive votes, enough so that only a few days later the vote passed the minimum threshold of positive votes (15% of OASIS voting members) required for an OASIS Standard to pass.

That’s when it became apparent just how badly the W3C didn’t want that to happen. The second rule with an OASIS Standard vote is that no more than 25% of the votes cast can be negative. That’s never happened in OASIS history – in fact the highest percentage of negative votes ever cast against an OASIS standard was 9% (for the Management Using Web Services v1.0 specification in February 2005, for which a whopping 6 negative votes were cast).

But within hours of the XRI 2.0 ballots reaching the 15% positive threshold, suddenly more negative votes began appearing. Almost all of them referenced the W3C TAG recommendation. By Thursday of last week, with three days left, enough negative votes had been cast to reach the 25%-of-all-votes-cast negative threshold.

Naturally XRI supporters responded by contacting other OASIS members, informing them of this unprecedented situation, and asking for their support. In one case, a company’s OASIS voting rep had cast a negative vote apparently without knowing his company was planning to adopt XRI and XDI technology. After a hastily arranged meeting to explain the details, the company reversed its position and voted in favor.

Many more OASIS members responded likewise, and by Friday morning there were again enough positive votes to safely pass both specifications.

But it wasn’t over. More emails, phone calls, and even blog posts from W3C TAG members went out. More negative votes appeared. By Friday evening, the negative votes were again just above the 25% threshold.

Given that the final day of the vote was a Saturday (OASIS Standard votes always run the final two weeks of a calendar month), it took an extraordinary effort by XRI supporters to reach out once more to OASIS members for help. But once more they responded, and by noon on Saturday, 8 hours from the close of the vote, 72 positive votes had been cast, enough to pass both specifications.

But I had a sinking feeling as I left to work on a birthday project for my youngest son. Sure enough, when I came back for dinner that night, with only four hours left in the vote, two more negative votes appeared – just enough to cross the 25% negative threshold and defeat both ballots.

(You can see the final results here and here, however due to technical problems at OASIS, you can’t currently click through to read comments posted with a vote.)

—-

As I watched the voting period end on Saturday night, one thought kept echoing through the back of my mind: “What is the W3C so afraid of? Why do they care so deeply that OASIS members not approve XRI 2.0 as an OASIS Standard? Why on earth would they turn out such an extensive and unprecedented lobbying campaign for something they have so long ignored?”

In other words, if they thought XRI was such a bad idea – or in their precise words, “We are not satisfied that XRIs provide functionality not readily available from http: URIs.” – why don’t they just let it die a natural death in the marketplace?

—-

In any case, we’re about to find out. A number of OASIS members who voted No at the TAG’s urging noted their reluctance in doing so in their comments. They explicitly asked the OASIS XRI TC and the W3C TAG to sit down together and iron out our differences. The most eloquent was Ray Denenberg of the Library of Congress, who said:

First we reference comments of Wells Fargo, who said:

“Although we support XRI’s objectives, we urge the XRI TC to consider W3C’s comments seriously and add a non-normative clause explaining key differences between XRIs and URIs, and detail how the former address specific deficiencies of the latter.”

And comments from Nokia, who said:

“Although the XRI TC and W3C TAG have exchanged some e-mail regarding the XRI spec, it appears the engagement has been mostly superficial. Consequently, we recommend these two groups engage in detailed technical discussions (including use cases and deployment scenarios) before OASIS formally adopt this spec.”

We further observe that the body of existing documents on XRI, though abundant, all seem either too high level or too detailed. It is very difficult to get the whole picture.

The Library of Congress urges OASIS to:

1. Consider W3C’s comments seriously, explain differences between XRIs and URIs and how XRIs address deficiencies of URIs, and respond with substantive explanations (rather than existing promotional text) to W3Cs concerns.

2. Prepare a paper (or non-normative clause), perhaps 5-10 pages, that includes the above, as well as a comprehensive description of XRI, including use cases, deployment scenarios, and real-life examples.

The Library of Congress supports the XRI objectives and we are prepared to change our vote if these steps are taken.

This is highly constructive feedback by Ray, and in my personal opinion, it lays out precisely the path the XRI TC and the W3C TAG should take together. Although I obviously would have preferred other ways to get here, those who know me know that I prefer to focus energy on how to solve problems, not how to create divisions.

The past is past. With this blog post I’m personally holding out an olive branch to the W3C TAG – and encouraging other XRI TC members to do the same – and asking to begin the dialog that will hopefully result in a mutual understanding about the role a layer of abstract structured identifiers will play in the Web.

Ryan Janssen pinged me via my contact page last week to ask if I had time to share the story of how I came to be working on XRI, XDI, OpenID, i-cards, Higgins, and Identity Commons. He reached me this afternoon and we talked for almost two hours. Boy, did it bring back memories. I’m so focused on building out working identity infrastructure and applications based on all these standards and projects that I rarely have a moment to reflect on how many twists and turns (and dollars) its taken to get here. So this was a full-out stroll in the park.

He’s posted an overview and will be writing more as he talks to others who have been pounding away forging this Internet identity layer. Ryan’s really done his homework too — he even included a link at the end to the original XDI white paper that co-chair Geoffrey Strongin and I contributed at the start of the OASIS XDI Technical Committee in early 2004. Wow, did that trip off the old synapses. Most fascinating is seeing the original proposed XDI schema which had just four elements. Four years later, after numerous twists and turns (and by my count 23 intermediate proposals), the XDI RDF model has…four elements (plus the XDI wrapper element). It’s not the same schema (now it’s based on the RDF graph model) — and in fact the preferred serialization is no longer even XML (it’s X3). But it’s uncannily close.

Deju vu all over again…

Identity Woman (Kaliya Hamlin) posts about why current “friend formats” like FOAF and XFN don’t satisfy the need for privacy and personal control of data that she – and many other women – want before they are comfortable sharing personal information online.

She mentions that XRI and XDI provide this capability. Chris Messina comments that:

As it is now, there are few applications that actually support what
you’re talking about in terms of giving you fine grained control over
your relationship lists… It’s something that I hope is coming down
the pipe but is not something that has to do with the format; instead
it’s all about consistent citizen-centric access controls over their
data.

Let me explain why I believe it does indeed have “something to do with the format”, and thus why XRI and XDI are so relevant to this problem.

The core idea is that to provide the control Kaliya wants — over who has access to what parts of her profile — you can’t tie the access control format down to a specific blog, domain, application, or i-broker that you are using. You need the access control format to be as portable as the data it is controlling, or else we’ll never get to real portable data – data (and relationships) you can “take with you” across different communities and applications as your life and work evolves.

XRI and XDI provide a open standard way to do this. They break the problem of portable access control into two parts. The first part is a portable addressing format — a way to address the data being controlled that is domain- and application- independent. That’s the job of XRI (Extensible Resource Identifier). It enables a layer of abstract addressing on top of any network-addressable resource that enables portability of data across domains and applications.

The second part is a portable format for expressing the controls an individual (or other data authority) wants to assert over access and sharing of their information. That’s the job of XDI (XRI Data Interchange), a very simple XML format in wich every node of a data graph is XRI-addressable. Within this graph, certain nodes are used to store the access control metadata. In XDI these are called link contracts.

Link contracts are are the portable access control format Kaliya is asking for. As she mentions in her blog, XDI link contracts have already been implemented by Andy Dale, Steve Churchill, Barry Beechinor, and the team at ooTao in a large scale data sharing project for La Leche League International. ooTao used the original XDI data graph model, called the Authority/Type/Instance (ATI) model, For more about this implementation, see Andy’s blog, The Tao of XDI.

An even simpler XDI data graph model, XDI RDF, has since been developed based on the RDF graph model. To see examples of what link contracts look like in the XDI RDF model, see the current XDI RDF Model writeup.

With the XRI Resolution 2.0 spec going final (public review will begin next week – I’ll blog more about this shortly), I look forward very much to diving much deeper into XDI RDF and link contracts at the Internet Identity Workshop, coming up December 3-5 at the Computer History Museum in Mountain View.

I’ve never been part of a self-organizing community as large or as effective as the Internet Identity Workshop. If you care about the emerging user-centric identity layer for the Internet – or even if you only only care about the applications that are possible on top of that layer (which frankly are a whole lot sexier than the infrastructure), then don’t miss this next one, Dec. 3-5 at the Computer History Museum. I know of more groups pre-planning sessions for this IIW than ever before, including sessions on Higgins 1.0 (due out at the end of the year), new Identity Commons Working Groups, the new XRI Resolution 2.0 specification (note that the final-final link will be available before IIW), and XDI-RDF.

Paul Trevithick just posted about a significant new step for the Higgins Project – the first contributions adding support for SAML 2.0. At first blush that may not seem surprising – SAML is the granddaddy of modern Internet identity protocols – but it speaks volumes precisely because Higgins established its early reputation as an alternative implementation of CardSpace and WS-Trust.

What this reinforces is that Higgins is really protocol-independent. As Paul puts it:

Higgins is about a consistent card-based experience over whatever protocols have traction in the marketplace.

I’m spending a lot of time with Paul and the Higgins team now working on integration of XRI and XDI for the same reason. Both are open protocols being developed at OASIS for digital addressing and data sharing. Both “plug in” to the Higgins framework and its abstract data model. By serving as a “interchange hub” for data and tokens from different protocols, Higgins has the potential to do for identity interactions what TCP/IP routers did for the net itself – finally get us all speaking to each other.

Certain events scream out for live blogging. The Data Sharing Summit is one of them. So these are my notes from first half of Day 1. (Then why are they being posted at midnight, you ask? Because there was too damn much to talk about during the second half of the day. More on that tomorrow.)

First, this is the list of problems that attendees want to see addressed:

• The distributed schema mapping problem – how do you map across zillions of different local schemas?
• The “Social Web Bill of Rights” or “identity rights agreement” problem – how can you have “Creative Commons licenses for data sharing”?
• The protocol problem – how do you move social graph data around?
• The “too many IDs” problem – how can we not require more IDs (even with OpenID there is starting to be a proliferation of IDs)?
• The directory or “friend discovery” problem – how do you find other people in the social graph (a “People’s Guidestar”)?
• The addressing problem – how can data be addressed in a consistent manner across distributed locations?
• The user privacy and control problem (also called the “fear” or “surprise” problem) – how can users not be spooked by the idea of their social graph data “getting loose”; how can they maintain control over portable social graph data?
• The granular access control problem – how can control be easily brought down to the individual attribute level, e.g., date of birth?
• The regulation problem – how can social graph portability be accomplished within the bounds of data sharing regulations that currently do not permit certain types of personal data to be shared across certain jurisdictions?
• The safety problem – how can portable social graphs not be subject to the same spam, phishing, and phraud problems as email and the Web?
• The political problem – how can we make it “politically necessary” for sites and applications to offer social network graph export?
• The “friend description problem” – how can we have a interoperable means of providing richer description of “friend” relationships?
• The calendar sharing problem – of all the different types of social graph data, how specifically can we reach alignment over sharing of calendar data?
• The adoption problem – what are the compelling uses of social graph portability that will drive large-scale adoption?
• The internationalization problem – how can attribute sharing work across all world languages?
• The user experience problem – how can social graph sharing operations be made simple and understandable to everyday Web users?
• The operational problem – how will large-scale data sharing affect network loads, caching, firewalls, security perimeters, etc.?
• The “invitation fatigue” problem – how can we stop being overwhelmed by yet another source of messages and “click-to-accept” links?

Second, this is the list of solutions being offered at the DSS:

• An OpenID interoperability testing service (Marc Canter)
• A new open source project & community for social data portability using Higgins and Higgins context providers.
• A community dictionary service for schema mapping (Markus Sabadello, Drummond Reed, Paul Trevithick)
• Different companies offering the potential to have open APIs for sharing their social graph data (AOL/AIM, Yahoo, Google, Cyworld).
• OpenID-based attribute exchange (Dick Hardt & Sxip)
• An open API format for social network portability and sync’ing (Brad Fitzpatrick and David Recordon)
• A social network export service (Upscoop from Rapleaf)

Third, here are the demos that were shown before lunch:

• Cloudtripper: Paul Trevithick and Markus Sabadello showed how Higgins in conjunction with Higgins context providers (code chunks that know how to talk to specific data sources) can be used to pull a user’s social graph data together directly to their own desktop client.
• Community Dictionary Service (CDS): Markus Sabadello and I demo’d a new service contributed to the Identity Schemas Working Group at Identity Commons. Intended to help solve the schema mapping problem for highly distributed data sharing, the CDS is a “Wikipedia for machines” – a way for applications to discover and map elements from different data schemas. (I’ll blog a bunch more about this after the Summit is over, but please do see it for yourself.)
• FOAF crawler: David Recordon (now back at Six Apart) showed a service that crawls public FOAF, XFN, or other relationship metadata to produce aggregated social graphs.
• Pownce: Leah Culver demo’d a social network aggregation service that lets users aggregate their own social graph.
• XRI-based data sharing: Mike Mell showed an implementation of a data sharing solution based on XRI structured identifiers for La Leche League International.

I just added XRDS (Extensible Resource Descriptor Sequence) as a new category on my blog because this simple XML document format, created by the OASIS XRI Technical Committee to provide XRI resolution metadata and subsequently adopted by Yadis, is starting to gain attention as the discovery format for OpenID.

Phil Windley just posted a good overview of XRDS today. For even more detail about XRDS (and OpenID in general) see this article written for the Java community — perhaps the single best technical article on OpenID I’ve read.

I haven’t blogged in a month because I’m so heads down with XRI 2.1 specs, prep for IIW (next week), and the business side of user-centric identity (yes, this really needs to turn into an industry if it is to ever really matter). But I could not help but note the explosion of discussion around Tim Bray’s post that Sun will be using OpenID and — gasp! — actually providing a semantically meaningful OpenID identifier! I can’t reference the discussion on the Identity Gang mailing list per community agreement, but see:

• Paul Madsen’s post.
• Eve Maler’s post.

If this raises a ruckus, imagine the concept of an entire LANGUAGE for machine-proveable assertions using machine-readable identifiers. Imagine if Sun could move from it’s current “tincture of trust” to a simple yet provable assertion like…

@sun+employee=example.name

…which is itself would be a valid OpenID under the proposed OpenID 2.0 spec and the proposed XRI 2.1 syntax.
With XRI 2.1 and the XDI RDF model, about which I’ll start blogging much more extensively after IIW, that’s what we’ll have laid the foundation for. A semantic web where the semantics are actually in the identfiers.

Exactly the way it works with human language.

What a concept.

Last week I had a long talk about XRI with Phil Windley and Scott Lemon that they just posted as an IT Conversations podcast. If you ever wanted to know the full XRI story from start to finish (verbally, at least), this is the podcast for you. Phil tends to draw out the details from me, so there’s quite a bit of “verbal whiteboarding” (I live for whiteboards), but altogether it amounts the most comprehensive oral summary of XRI I’ve ever done.

After all, the point of this blog is that identifiers matter. Few people understand just how much.

Kim Cameron has done another great post about how Cardspace and OpenID can work together, and specifically about the potential relationship of information cards and XRI i-names and i-numbers. This continued a thread that started with a post I did January 22 suggesting that it would be ideal for the CardSpace schema to support XRI identifiers as a specific claim type. In his response that same day, Kim said:

“…just a small clarification. Drummond talks about the “default CardSpace schema”. He’s really talking about the “default Self-Issued Card schema.”
CardSpace itself handles tokens of any type, containing claims of any type. There are no limitations on your schema if you create a managed card. I’ll make that clearer in my next post.
Further, we tried to keep the ”bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology. But one of those initial claims is a URL… I thought an i-name or i-numbers would be able to go there. Is more needed?

As usual, Kim’s architectural instinct goes straight to the heart of the matter. In fact he poses such a important question that I’m going to provide a very detailed answer, starting with a use case involving the very blogs on which we are holding these conversations.

The Power of Abstraction

In Kim’s post, where he responds to this excellent post by Andy Dale explaining why the i-name and CardSpace value propositions are so complementary, Kim was particularly kind about the work we have been doing on identifiers at the OASIS XRI and XDI Technical Committees. He gives the example of using his own i-name on his blog. To quote his post (including the links):

By the way, I’ve been using my =Kim.Cameron i-name for a couple of years now – ever since I started this blog. It has been a life-saver. It has been my email conduit to my readers and allowed me to interact personally with many people all over the world – without ONE piece of spam.

Thank you again Kim for your kind words about what I believe is currently one of the most useful features of i-names – they come with contact pages that let you be reached on the net without opening yourself up to spam. But now let me drill down into a crucial feature of how i-names and contact pages work.

First, if you hover over Kim’s “=Kim.Cameron” i-name link above, the underlying href value you will see is:

http://2idi.com/contact/=kim.cameron

Interestingly enough, this is not the original XRI. XRIs are abstract identifiers, so to go to a specific location they are resolved into URIs. The HTTP URI at 2idi.com (2idi is Kim’s i-broker for his =Kim.Cameron i-name) is actually the default HTTP URI that =Kim.Cameron resolves to if you use an XRI resolver. (Why that particular URI is the default is beyond the scope of his post; the complete details are in the current XRI resolution spec.)

The original XRI for Kim’s i-name, in pure XRI format, is:

=kim.cameron

That’s right, there isn’t even an “xri:/” scheme name. That’s optional in XRI syntax because XRIs are protocol independent, so the XRI “scheme” is actually indicated by one of give global context symbols as the first character of the XRI (=, @, !, +, $). That doesn’t mean an XRI can’t use a domain name to specify the authority; it can, just after the prefix “$dns” (or “$ip” if you want to use an IP address). While this syntax is not yet recognized yet by today’s text editors and browsers, the same was true 10 years ago of www.*. That will come in time if XRIs prove as useful as those of us developing XRI infrastructure believe they will be.

To solve the problem of how XRIs can be used immediately with today’s Web infrastructure, the OASIS XRI TC defined an HTTP(S) XRI format called HXRIs. This adds an http(s) URI scheme and domain name as a prefix to the pure XRI. The two rules for an HXRI are: a) the domain name must start with “xri.” and b) the first character of the path must be an XRI global context symbol.

An HXRI is sent to a web server called an HXRI proxy server. Anyone can operate an HXRI proxy server just by creating an “xri.” subdomain and running an instance of XRI proxy resolver code available from the OpenXRI project (see dev.inames.net for more info). So the second form of Kim’s i-name is a HXRI that uses the xri.net public HXRI proxy resolver operated by XDI.org.

http://xri.net/=kim.cameron

If you click this URI, it calls the xri.net proxy resolver which looks up the target XRDS document (I can’t display it here but you can view the XML directly).

Since the xri.net proxy resolver was not given any other instructions about what service type to select, it selects the default service (again, out of scope for this post), which in this case is a contact service, identified by the following XRI in the Type element:

xri://+i-service*(+contact)*($v*1.0)

(Note that this XRI is in URI-normal form, which is why it shows the “xri:” scheme name.)

The xri.net proxy resolver then follows the instructions for composing the final target URI, which is to append the original pure XRI (=kim.cameron) to the value of the URI element (http://2idi.com/contact/). This gives you:

http://2idi.com/contact/=kim.cameron

While this is the HTTP URI that Kim cut-and-paste to put on his blog (probably because that’s what appears in his browser address bar when he goes to his contact page), that’s not actually the HTTP URI he should use if he wants the link to persist. He should use the original HXRI of:

http://xri.net/=kim.cameron

Why? Because this is the full abstract identifier that will continue to work even if Kim later changes i-brokers to a different i-broker (such as 1id.com, Encirca, Initech, or LinkSafe – more in the pipeline). In fact if Kim wants to, he can gain even greater persistence by making the underlying link for “=Kim.Cameron” to his i-number instead of his i-name. You wouldn’t see it unless you hovered over it, but this would look like:

http://xri.net/=!BC75.AD44.D370.C0A0

This is the safest and strongest link Kim could put up because unlink global i-names, global i-numbers will never be reassigned to another XRI registrant if the original registrant expires– all global i-numbers are permanently globally unique.

The moral of this story? While XRIs (in URI-normal form) are technically URIs, they are a special kind of URI intended to be resolved into other concrete URIs that actually indicate the current network location of a particular type of resource. An XRI by itself doesn’t indicate the current network location of anything. It’s purpose is to represent an abstract identity – the real world entity that has a representation somewhere on the network (or is in fact represented entirely by the identifier, in the case of purely abstract entities like tags).

Finally Answering the Question: XRI Claims for the Self-Issued Cardspace Schema

With this background laid, we can now finally start to answer Kim’s original question:

Further, we tried to keep the ”bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology. But one of those initial claims is a URL… I thought an i-name or i-numbers would be able to go there. Is more needed?

My answer is that while it is technically possible to put an XRI (in URI-normal form) into a URI field, and such an XRI would carry the necessary identifier metadata to indicate its URI type (the xri: scheme name), this would be akin to putting a fax number in a phone number field. Yes, technically, a fax number is a phone number, but it’s a special kind of phone number capable of a special kind of phone service, and this is typically indicated to both humans and devices by providing an input field that is explicitly typed to contain a fax number, even though the format is identical to that of a regular phone number.

The same applies to XRIs—in fact even more so because:

• There are explicitly two different kinds of XRIs: i-names and i-numbers. The first is reassignable and the second persistent.
• XRIs are explicitly intended to come in synonym sets, for example one-or-more i-names paired with a persistent i-number. In fact when you register a global i-name with the XDI.org global registry service, you are automatically assigned a global i-number (unless you have one already, in which case you can choose to make the new i-name a synonym to your existing global i-number if you want).

So the bottom line is that for the Microsoft default schema for self-asserted cards to fully support XRI i-names and i-numbers as privacy-protected digital identifiers, I recommend that it include two claims for this purpose: one for a human-readable i-name, and one for a persistent i-number. Ideally both can support multiple instances, though in 99% of the cases only one i-number field will be needed, while in some cases users may wish to share more than one i-name synonym.

I look forward to working with Kim and Mike Jones and the CardSpace team to figuring out the best way forward to full interoperability — and synergy — between CardSpace, XRI i-names and i-numbers, and OpenID.

If you want to follow the real down-and-dirty of what the identity layer will become, catch Jeff Hodges blog at identitymeme.org. Before he joined NeuStar two years ago (lured by Peter Davis among others), Jeff was with Oblix and Sun and is the editor of several Liberty Alliance specifications. He also co-chaired the OASIS Security Services TC (producers of SAML). He’s currently working with Eve Maler’s “SAMListas” looking hard at the intersection of SAML, OpenID, and XRI.

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.