At the moment, the phrase "Identity 2.0" denotes a different, very web- and consumer-tech centric, approach to identity management. Another phrasing of the idea, "user-centric identity," makes clear that Identity 2.0 is more concerned with making a user's life easier rather managing a system that grants or denies permissions to a user. In fact, at this point, Identity 1.0 and Identity 2.0 (to get all whacky on the concept versioning) are complimentary rather than in opposition.
All Inclusive Identity
Identity 2.0 systems are interested in using the concept of a user's identity as a declarative bundle of claims about the user: from things like their name, address, to less traditional things like their desires, customer service history, and other attributes that are usually not so much associated with a user identity. That's the first big leap of Identity 2.0 think: a user's attributes should be associated with that user's identity.
In the real world, this is obvious. Just think of the phrase "identity politics." It involves a lot more than drivers licenses, social security numbers, and other credentials. In software, the two concepts of a user's identity and the attributes of a user are classically kept separate. Technically, they don't need to be, but once seperation of concerns has been applied to most systems, it's rare to see something like a zipcode associated to the identity centric entities in an architecture.
Trust and Identity
The second big leap in Identity 2.0 thinking is dropping the focus on trust, at least for now. "Trust" in identity means that you can feel safe in assuming that claims made by a user are true, for example, "I should have access to this system." Identity 1.0 is very good at what we might call trust based identity. Here's an example of trust based identity in action, by way of a chain of trust:
(Theoretically) I get asked to see my ID to prove that I'm over 21, the age you're allowed to get drunk, legally, in Texas.
I say, "come one, I'm over 21. Look at the beard!"
The bartender sighs and says, "I don't trust your claims, show me your ID."
I show my Texas Drivers License, which indicates that I'm over 21. Now, The State of Texas is the one claiming I'm over 21.
The bartender trusts the ID's claim about my age because she trusts the State of Texas (and that the drivers license is both real and mine, instead of another bearded man's). Thus, she uses a chain of trust, based on a centralized authority (Texas).
The bartender servers me the requested drinks.
The above is what you might call an "Identity 1.0" way of doing identity. It depends on a trusted authority. What gets weird in much of the Identity 2.0 talk is the dismissal of trusted authority. That changes the model a bit. Instead of trusting a user's claims -- in the trustless URL model I'll discuss below -- you focus on trusting a user's claims of ownership. In particular, you want a way to trust the claim: "I control this URL, so any questions you ask it, you can trust come from me."
Trustless URL Redirects
The two evolving standards I looked at were
OpenID and
LID. Both are different implementations of the same general idea: use URL redirecting and parameters in those URLs to verify a user's claim of URL owenership. Once a server, for example, livejournal.com, trusts the claim of URL ownership, it can programatically collect information from that URL, such as prefered user name, the user's photo, and other "profile" information.
The simplistic meaning of this is that I can go to
livejournal.com, go through the trustless URL redirect, and then livejournal.com can "feel safe" in sucking down all the information available at that URL about me. The alternative is that I could point livejournal.com to any old URL, that I didn't control, and use someone else's information. The difference is subtle, so worth calling out: in the second version I can use
any URL, while in the better, first version I can only use
URLs that I control.
Looking at OpenID and LID brought in several supporting protocols and technologies, esp. Yadis. I say those are the two I looked at, because I know there are many more projects, and even companies, that are tacking "Identity 2.0," and even this approach to it. I haven't looked at them indepth yet. I'd appreciate pointers in the comments or email.
As always happens in new technlogy (be it closed source/vendor sports, or open source/open standards), there seems to be a school-yard fight level schisem going on between SXIP and the LID/OpenID/Yadis crowd. For outside observers like me, with a train-wreak watching passion, it just makes for
some lol moments. For everyone else, it just means more crap to keep up with and deal with. Anyhow, enough about the politics. I get my fill of that in
the Enterprise RoR wars.
I will, of course, be filling the SXIP knowledge gap. I'd rather "post early, post often" than not.
Establishing Trust with 302 Magic
One nice thing about LID and OpenID is that their low-level technical documentation is out in the open. An even nicer thing is that there's actual running code and services. This means that after reading over the specs, you can see it in action and reverse engineer them with something like
LiveHttpHeaders.
So, here is my understanding of how these schemes work:
The client logs in to the server. Logging in just means that the client is trying to establish it's claim of identity to the server. For example, "I am user cote."
The server asks the client to give it's identity URL. This URL is LID or OpenID enabled, meaning that there are services behind that URL (on "URL Server") that can do the LID or OpenID protocols.
This finishes the HTTP request/response cycle.
The client gives the server the URL.
The server takes this URL, adds several arguments to it (the URL to return to if the user is successful in their claims of identity; the URL to return to if they fail; a token of some sort, perhaps "signed" by the server or the URL server; and many other arguments that the server is passing to the URL server), and then tells the client to redirect to the URL. Now, this is kind of funny: the server is telling the client to go to
their own URL.
The client receives this redirect command, and obeys it, requesting the new URL, which is the client's own URL.
The URL server gets the request. Assuming the Client has already authenticated with their own server, the URL server can use standard cookie session tracking to authenticate the client with the URL server. (If the client hasn't already authenticated, the URL server will ask the user to login to it, and then do the next redirection. This adds a new request to the cycle at this point.)
Once the URL server has authenticated the client, the URL server adds still more parameters to the URL. The net result of these additional paramters is that the URL server is saying "the client does, indeed, own this URL." Signed token(s) can be used to prevent spoofing of this verification. (I'm always a bit fuzzy on public key encryption beyond what the end goals are, so pardon looseness in that explanation.)
Now, still within the same request, the URL server sends yet another redirect to the client to go back to the server. Except, this time the URL is encoded with all sorts of arguments. These argument contain information that allows the URL server to vouch for the client's claim that the client controls the URL.
The client gets this redirect, and redirects it's request to the server.
The server looks through all the parameters that the URL server added, and can now trust the client's claim that it owns the URL.
And that ends the second, redirect-heavy HTTP request/response cycle.
The end result is that the server can trust that any information it pulls from the original URL the client provided is information the client specified. That is, the URL and all of the data it provides is part of the client's identity.
Security Concern: Hijacking the URL
While we've been saying that trustless URL redirecting verifies the claim that a user controls a URL, to be more precisise, it only proves that the user
at some point controled that URL. Someone could hijack control of the URL after that point, feeding it bogus data.
Another, very simplistic problem, is forgetting to pay your domain name bill and loosing control of the server. While you don't have to own a domain name -- you could use a sub-domain -- that's certainly an annoying problem.
But, those concerns are asking a bit too much of the scheme. The goal is to allow an incoming user to tell a server they're connecting to that the server can get data from the URL. Again, this is really just way to allow servers to suck in data from a URL. Granted, people may figure out how to layer more clever things on top of that infrastructure.
What Good Is This?
Profile Sucking
At this point, the primary thing this is good for is doing a variation of single sign-on you might call "single profile registration." As I've complained about many times, every time you create an account at a new site, you have to re-type in all your account and profile settings. Using something like microformats, you could capture all of that data behind one URL.
Whenever you sign up at a new site, you could just point the new site at your URL and tell it to suck down the data. The problem is that other people could hijack your data, using it to sign up with new accounts. By using a trustless URL redirect scheme you can provide a level of trust and authentication to the "suck down the microformat" process that would (hopefully) prevent people from using your information.
Identity Management
As I mentioned at the begining, I don't see this scheme (at least as it is now) replacing what might be called Identity 1.0. Identity 1.0, at least the enterprise version of it, is more concerned with reducing the costs of
managing 1,000's of user's identities and the permissions assigned to those users. Granted enabling single sign-on is a large part of IdM. But, Identity Management has more (important?) goals than SSO: making the provisioning (creation and configuring) of users quick and cheap, finding access violations (someone giving themselves permissions the shouldn't have), and otherwise making all the disparate systems behind the firewall "work together."
These concerns aren't really the same as making user's lives easier by allow new web sites to suck down profile information from the user's URL. Those kinds of problems are not always too relevent in a single silo, a homogenous environment.
And, BAAM!, there's where the fun comes in: once you move beyond your own silo, or otherwise increase your heterogeneity, something like Identity 2.0 does become helpful. If you can control, or establish, a centralized authority, then user-centric identity is not (technically, at least), too important. I'd argue that that "if" is an impossibly huge one: one that will never be 100% possible. Thus, the kind of user-centric thinking behind trustless URL redirects becomes handy to start considering in both consumer driven software (multi-silo) and enterprise software (which is becoming multi-silo, or, at least,
is very heterogeneous).
Related Technologies
To round out the discussion, and to leave some new topics open for future posts, here are some related topics:
You'd think
claimID would be a natural user of OpenID, LID, or other schemes.
MyLID.com is essentially a version of claimID that is more than just a "read only" service.
Yadis, which both the OpenID and LID people are involved in, is a service descriptor for all identity protocols. From that comes "discovery," and all the other things accosiated with service descriptors in SOAP and SOA-land. I'm not too keen on declarative service descriptors, prefering the type of "figure it out on the fly" discovery that you see in the systems management world. BUT, so far Yadis looks light-weight enough to not set off my XML based, meta-service alarm bells.
microID is another idea to consider when looking for even simpler approaches.
Like I said, I need to look at SXIP. It's a different, and VC funded, approach to user-centric identity. And those presentations sure are snappy.
Previous Topic
