=victor.grey weblog

In the beginning, OpenID was created as a method for mitigating comment spam on blogs. It requires that you provide to the blog (the RP or Relying Party) a URL to which you can be redirected. At the node to which you are redirected is a process (an OP or OpenID Provider) which is capable of doing a little Diffie-Hellman dance with the RP, or an ordinary web page with an HTML tag delegating to another URL where such an OP resides.

This is just fine for the purpose of mitigating comment spam, which only requires that some friction be thrown into the commenting process that makes it too slow or effortful enough to not be worth it for the spammers, but relatively easy to set up for the legitimate commentators.

Where OpenID went off the rails imho, is when the OpenID community starting seeing OpenID as a form of single sign-on (SSO) authentication. First of all, it's not any kind of meaningful authentication. It's trivial to set up an OP that just verifies anyone or anything that applies, and there are a number of such "services" around, but in fact it would be just as trivial to set up an OP that verifies anything that is bounced off it without even any application process. (Since I first wrote these words, I'm informed that there already exists such a wide-open OpenID Provider.)

Worse, SSO even as practiced by other communities such as I-Names and Liberty Alliance where something like real authentication may be accomplished, has several fatal flaws:

• Phishing - the end user is allowing themselves to be redirected somewhere and asked to provide their authentication credentials there. This is only safe if the user is sure about where they have been redirected. That surety depends on the user noticing some subtle cues. Phishing mitigators have concentrated on making these cues less subtle. But phishing, like direct mail, is a game of small but predictable percentages, and counts on the fact that some people will be too tired, distracted and/or in a hurry to notice that the cues are wrong. If you are never tired, distracted and/or in a hurry, you're OK.
   
• Trust - in a system intended to be global or internet-scale, how do you know which OPs to trust? Current systems leave this as an exercise for the developer, who generally has no idea what to do. Since trusting no one is not that useful, most current implementations "trust" everyone.
   
• Logout - an end user has a reasonable expectation that if they log in somewhere, that when they log out again they are, you know, logged out. SSO routes around this assumption because the login takes place at a different site than the logout. Even if the RP is responsible enough to redirect the user back to the original OP after logout, it is an entirely un-scalable notion that the OP would then initiate some protocol to log the user out everywhere else they might have used SSO.
   
• Not as sexy as you think - engineers, coders and early-adopter types like the idea of SSO. "You don't have to create accounts all over the internet, it's all handled in one place!" But if you emerge from your den and go out and talk to "real-user" units, you'll find that they are for the most part indifferent. It's just not a killer app.

A small shift in thinking began to remove the scales from my eyes. Single sign-on is essentially third-party authentication, but it's *introductions* that we need from third parties, not authentication! Now, this is certainly not a new or original idea , but I want to share a bit of clarity that has descended on me.

Introductions are a fundamental aspect of our socialization as human beings, perhaps even archetypal. The Granovetter diagram is often used to represent them formally. In the diagram, Alice is connected to both Bob and Carol, and Alice introduces Carol to Bob. The fat arrow on the connection between Alice and Bob represents the introduction itself. It is the technical nature of that introduction that I am discussing here.

The advent of the XRDS standard, which ironically may turn out to be the most important (and not coincidentally the simplest) contribution of the OASIS XRI TC, makes possible a very simple introduction protocol using an SPKI system that might actually work. The rest of this discussion presupposes a familiarity with XRDS.

Here's how it goes: first, the connection between Alice and Bob means that Bob has already been introduced to Alice, either at some time in the past via the protocol we are about to describe, or a priori via configuration. This means that Alice knows how to get Bob's XRDS from a source she trusts. To proceed with an introduction, Bob must have made himself available by publishing an allow-me-to-introduce SEP in his XRDS. A two step process follows.

First, Alice POSTs to the URI in Bob's allow-me-to-introduce SEP with -her- name for Carol, Carol's CanonicalID, Alice's CanonicalID, and Alice's signature over both her and Carol's CanonicalIDs. Her name for Carol is a URI or an HXRI that dereferences to Carol's XRDS, something like "https://xri.example.com/*carol". (This form of an HXRI is admittedly a bit avant-garde, since it doesn't yet exist in the XRI spec, and is only being discussed off-line at the moment. But I'm going to go out on a limb and use it. It's not essential to the protocol and can be modified to match a spec for URI-hostname-based community roots in HXRIs, when there is one.)

Bob's allow-me-to-introduce URI is a "factory" resource - POSTing to it creates a new introduction if successful. Bob already has Alice's public key on record, and/or knows where to look up Alice's XRDS to get it. He should also look up Carol's XRDS to verify her CanonicalID and record her public key for future use. Bob then verifies Alice's signature, and creates the new introduction resource, initially in "expecting" state. He returns a 201 (created) HTTP status, along with a Location header for the new introduction.

So far, all this has taken place server to server, in the background. It could probably be combined with the next step to make a "one click" experience for the user, but as a rule I think it will be better to keep the process as two steps, to facilitate asynchronicity and agent-on-both-sides possibilities, as well as to shield the user from high-latency processes.

In step two, Alice makes the new "expecting introduction" resource available to Carol in the UI as a form button. In the best of all possible worlds, Alice would make the raw introduction URI available to Carol, and Carol would be able to sign and deliver her own response to it from desktop software. But until that happy day, I'm going to assume that Alice is acting as an introduction agent, and has the ability to sign stuff with Carol's private key on her behalf.

Since clicking on the "complete-introduction" button is going to change the state of the introduction resource from "expecting" to "consummated", it should trigger an HTTP PUT, but alas browsers don't do PUT in the early years of the 21st century, so we'll use an overloaded POST. The POST body contains Carol's CanonicalID and her signature over it, so that Bob knows this is really Carol. Bob can now begin his relationship with Carol, which will probably begin with returning a UI to establish a local account for her so that she can authenticate locally with Bob from then on.

Both of the steps are idempotent, i.e. they only work once and further attempts to access them don't change anything. So we don't have to worry about replay attacks, and nonces are not necessary.

Since we are using URI-hostname-based community roots that are not privileging any particular registry, it will be useful to craft a CanonicalID that is globally unique. This can easily be done in a standard fashion by using a UUID. The XRDS will also contain a public key for its entity, in a <dsig:KeyInfo> block.

Now the HXRI dereferences to a globally unique CanonicalID and a public key, as well as a list of service endpoints. The public key can be given a short TTL, thus solving the PKI revocation list problem by totally distributing it.

As long as the HXRI dereferences to the same CanonicalID, it represents the same entity as the last time you saw it -- the fundamental meaning of identity.

Having been introduced to you, we know each other's CanonicalIDs and we each have a way to look up the other's public key. I can then give you access, on my terms, to any data that I control, by having my software agent craft a URI that contains an access key which becomes valid when signed with your private key. That access key thus gives you and you only, access to whatever it is programmed to enable, for some given duration. User-centric data sharing!

Coming next, a more complete description of an implementation of the introduction protocol, and then, working code :-)

I’ve been thinking about how to use JSON as a data interchange format using XRI identifiers and IRAs. You have to love a protocol that can be specified on one page, and there are some compelling reasons to use JSON as an alternative to XML for this purpose. Since XRI data interchange has been known as XDI, I’ll call this JXDI.

This will be a resource-oriented protocol (i.e. REST for the irreligious). Let’s assume that all interactions must be authenticated.

There was a heated discussion a while back between some members of the XDI TC about whether REST was worth pursuing, or whether it even meant anything meaningful in the XDI context. It’s clear that REST has its religious zealots (RESTafarians). and that purity is not possible or even desirable for the rest of us. But as a thought process, REST is seductively elegant—think of everything that your application exposes to the user as a resource rather than a service. It’s a subtle but powerful difference.

Many of the tech and crypto people working on phishing mitigation seem to think that the problem is “how can I connect with anyone in the world in a trustworthy way?” Personally I don’t think it’s all that compelling to be able to communicate with 6 billion strangers. It’s much more interesting to be able to communicate from anywhere with people whose identity and reputation within my circle of communities can be ascertained in a trustworthy way.