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.
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:
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 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:
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.