The Laws of Identity: string theory for the web universe?

Kim Cameron‘s Laws of Identity have received a lot of attention, and for good reason; these laws encode properties that are very important to users and identity providers, and previous attempts at identity systems violating these laws have been rejected by these two groups.

However, there’s another important group whose needs don’t seem as well represented in the Laws as they should be. That group is site owners, or “relying parties”. And it seems to me that on the web, site owners represent “reality”: an identity system might encompass the best ideas of the day and be beautifully self-consistent, but unless it meets the needs of this group, by definition it cannot be a success.

Now, it probably says more about where my head is at than anything else, but I’ve been noticing a lot of parallels between the current state of digital identity and that of another area I pay a lot of attention to: theoretical physics. So at the risk of establishing a completely opaque metaphor, I’m going to propose that:

The Laws of Identity are like String Theory

Like the Laws of Identity, string theory encompasses the best ideas of the day and has a beautiful self-consistency. But by definition, to be a success any proposal based on this theory has to match the actual universe we see around us. And so far, string theory has failed to generate such a proposal.

Similarly, any system based upon the Laws of Identity as formulated today cannot be successful unless it meets the needs of site owners, who in the real world are the folks who have to adopt the system. And right now, I think that the systems out there don’t match what many site owners need.

To be more specific, lets take a look at two standards with a lot of momentum right now: OpenID and CardSpace.

OpenID is like General Relativity

Like general relativity, OpenID simply and elegantly solves a specific problem: how to prove to a site that you own a URL. Here’s a diagram showing at a high level how the system works:

OpenID

I’ve skipped some of the details here and in subsequent diagrams in order to create pictures that are easy to compare to each other.

Also like general relativity, OpenID is an amazingly effective but demanding tool. In particular, if used as an authentication tool, OpenID demands that the site owner integrate and keep current a block of additional code, and that the user database be altered to accommodate users who instead of a username/password use a URL to authenticate.

This makes sense for a site that really needs what OpenID offers: proof of URL ownership. And this is what OpenID was originally designed for: verifying the identity URL of blog commenters. But what about a typical site that just wants to offer its users an easier way to log in?

To me, asking a typical site to deal with libraries and database changes just to ease logins seems about as sensible as asking missile designers to use general relativity to calculate trajectories. You want to use the simplest tool for the job, and while GPS calculations might require GR, the vast majority of gravity calculations do not. Along the same lines, I’d argue that proof of URL ownership isn’t the simplest way to authenticate for most web apps.

CardSpace is like Quantum Field Theory

Now let’s consider CardSpace. Like quantum field theory, CardSpace is a flexible and powerful framework that can be used to solve a wide variety of problems. Here’s a diagram for CardSpace, simplified to be easily compared to the previous diagram:

CardSpace

CardSpace is another demanding tool for site owners: as with OpenID, they are faced with code integration and altered databases. But beyond this, CardSpace shares another characteristic with QFT: the feeling that something’s just not right. For me, QFT feels wrong because, among other things, it’s dependent upon a background metric. In the case of CardSpace, the problem is dependence upon client software. CardSpace is PC-centric, and dependence upon client software just feels wrong in today’s web-based world.

In particular, CardSpace puts the “identity selector” on the PC as software. This means that every client has to have this software, and even worse, the identity cards themselves are not web-native; they need to be transferred from PC to PC using a USB key. To me, this makes using CardSpace in place of username/password for web apps about as sensible as using QFT in place of Ohm’s Law. The PC-centric approach might make sense in the enterprise, but for consumer web apps it seems to me like a bad fit.

Another issue I have with CardSpace is that authentication with the identity provider doesn’t take place in a browser; instead, it seems to be constrained by what the identity selector software offers. If I have this right, this really limits options for the identity provider — what if they want to use two-factor authentication, or a captcha, or a personal image for anti-phishing? Only a browser interface provides the flexibility that at least I think is needed to accommodate the diverse landscape of identity scenarios.

Identity Meta-Providers are like Quantum Mechanics

OK, so what is it that web apps need then? I think that what’s needed is the analog of Quantum Mechanics: an approach that incorporates the core ideas of more complex systems yet is usable for solving practical problems.

Leaving the tortured metaphor behind, this means moving from an identity meta-system like CardSpace to an identity meta-provider. The new web is all about services, mashups, widgets — all available from any browser. Why should identity be any different?

The key differences between the idea of an identity meta-provider as opposed to a system are:

(1) the “identity selector” function is provided by a web service instead of by software on the PC
(2) rather than simply pass on whatever auth token is issued by the identity provider, the identity meta-provider translates this authorization into a form that is easily digested by the relying party

Since I’m focusing on web apps, I’ll assume the IMP translates auth into the usual username/password, which is certainly easy to digest by existing sites; but this isn’t a requirement. Here’s a picture, easily compared to the previous two:

Identity Meta-Provider

The main idea is to change two things about existing approaches:

(1) to require minimal effort on the part of sites
(2) to keep everything web-centric

To me, this approach has a bunch of incredible advantages:

– The identity provider can now use a web page to authenticate
– No cards exist on the PC to be stolen, moved around, etc
– Site integration is incredibly easy

Of course, these advantages come with tradeoffs:

– Sites must trust that the IMP actually authenticated the user; no signature proves this (sites for whom this is important can always choose a IMP that passes the native token on)
– Users can only use identity providers that the IMP decides to support (this can be addressed by competition among IMPs)
– The additional network communications to and from the IMP are attackable

In my opinion, these tradeoffs are well worth it.

The 8th Law of Identity?

Coming full circle, the idea of an identity meta-provider addresses what could be thought of as the “missing 8th Law of Identity”. This would be something like:

A universal identity system must streamline site adoption by minimizing integration requirements and supporting the identity interfaces these sites already use.

For most web sites who would like to ease user registrations and logins, this means that the system must hook up to existing username / password systems.

Is an 8th law, along with the concept of identity meta-providers, enough to get us to Kim Cameron’s “identity big bang”? I’m not sure, but I do think it’s a step in the right direction.

Get Flash to see this object.

UPDATE: Since writing this, I’ve come across a couple of proposals that have some of the same moving parts, but accomplish different objectives.

Kim Cameron proposed using CardSpace to authenticate OpenID users at their identity provider. This sounds like one way to reduce the phishing vulnerability of username/password authenticated IPs, but of course it brings back the requirement of client software.

Dmitry Shechtman proposed (and illustrated) a browser plug-in that, as I understand it, would implement a kind of CardSpace-style OpenID identity selector. This also helps reduce phishing vulnerability, and has a nice flow that simplifies the current OpenID user experience. But again, client software is required and relying parties still face the same integration issues.

5 Responses to “The Laws of Identity: string theory for the web universe?”

  1. Dmitry Shechtman Says:

    I must admit that I only read the last paragraph. I never liked physics, and I can only hope that OpenID (contrary to relativity) will be understood by the general public.

    Now, to my question. What integration issues?

  2. Adam Says:

    Well, I was worried the physics thing might not go over that well…hopefully the post is readable even ignoring it.

    To answer your question, it seems to me that one of the main reasons there’s such a lack of OpenID consumers is that it’s just not easy to adopt. You have to integrate an OpenID library into your app, alter your user DB to accommodate URL in place of username/password, and then deal with issues like linking OpenIDs to old accounts, letting users change their OpenID URL, etc.

    This might not seem like a big deal to you, but I think it’s a lot to ask of a site just to ease logins — after all, that effort will be competing with the usual pressure to work on features and bugs in the app itself. That’s why I propose that for apps without high security requirements, that an intermediary deal with OpenID auth for the site and then translate it to the usual username/password.

    Btw, I just saw your description of FreeYourID as “a lot like smoking: it’s bad for you, it costs you money, and you can’t quit.” Hah. I previously signed up and immediately regretted it when I realized I’d just forfeited marsh.name…

  3. Dmitry Shechtman Says:

    I believe OpenID is well worth admin’s efforts, since it would make users much happier (in fact, it would attract many users that wouldn’t normally bother registering). There are pretty good libraries around, so this isn’t all that difficult.

    How about standard applications? WordPress has a (yet incomplete) plugin, I’m on phpBB, and while working on the phpbb-openid site I also polished the Drupal 5 module. I’ve recently blogged about those.

    Now, another project of mine involves a different sort of intermediary. I can’t currently disclose much details. It would still require the application to have OpenID support, but will hopefully make the users even more happy…

    As for the .name domain, I wouldn’t regret it that much. Who’d want one anyway? ;-)

  4. Econometa » Blog Archive » New PrefPass service: instant universal login! Says:

    [...] of the pain points for site owners (or “relying parties”) that I talked about in my previous post on the Laws of [...]

  5. Econometa » Blog Archive » OpenID: first things first Says:

    [...] issues like security, technology, and usability, and these are all important. But as I’ve said before, the most important thing is to make it as easy as possible for site owners to adopt the [...]

Leave a Reply

Moderation is on, so your comment may not show up right away.