Coté, software industry analyst with RedMonk, posted in detail on what he calls "Identity 2.0, Trustless Redirects, OpenID, LID, and Friends…or, Learning to Spell ‘Centralized’". He investigates, in some detail:
and also mentions Livejournal, ClaimID, Yadis, MicroID, and our MyLID.net (linked correctly, but misspelled as MyLID.com).
I’m going to cherry-pick a bit on what he says and comment:
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.
Exactly. And there are a number of people trying to figure out today where exactly they meet, and how to make that meeting as useful as possible for both sides.
first big leap..: a user’s attributes should be associated with that user’s identity
Sounds kind of obvious if put that way, but of course it isn’t for everybody, so it’s very much worth mentioning.
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…
.. an “Identity 1.0” way of doing identity .. depends on a trusted authority. What gets weird in much of the Identity 2.0 talk is the dismissal of trusted authority… 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.”
I almost agree with that, but not completely. Funnily enough, he discusses his “identity 1.0” example largely in user-centric identity terms:
- I go to Lala’s for a Wild Turkey and Lonestar.
- (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.
In my mind, the difference between old-style identity assumptions and internet-scale, decentralized, user-controlled identity is not so much that there are no trusted third parties (because if there weren’t, many important use cases (like buying booze) could not be addressed), but that there is no default assumption about who the trusted parties are.
For example, in a typical corporate identity implementation, if I claim to be a manager, that claim can be easily proven or disproven by the corporation’s HR system, which is the trusted authority that everybody touching the identity system implicitly trusts. On the open internet that is not true. For example, it is entirely possible that some people will not trust the state of Texas, and thus do not trust any Texas-issued driver’s license (happened to me one day: a car rental agency in Washington state refused to accept my California driver’s license… and we are not talking about Somalia here…)
In Coté’s example, he and the bartender have a bit of negotiation on who is the trusted authority; the bartender does not accept Coté as an authority making statements about himself, but asks for a Texas license. This kind of negotiation does not happen in traditional identity implementations, because they are limited in scope (e.g. within one enterprise, within the context of one government, within a trusted trading federation …), and one can “hard-code” the authorities such as the HR system.
Moving on, after taking SXIP and us to task for conversation style (and very justly so!), he has these nice words for LID and OpenID:
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.
Not only that, I’d like to add, but there are multiple implementations from multiple parties, interoperating, and, as Brad Fitzpatrick said so memorably on the OpenID page, don’t "… entirely crumble if one company turns evil or goes out of business".
Then he has a great diagram on the gory details of browser redirects. Because he did ask for comments, I’d like to quibble with it:
- In all three cases (Yadis, LID, OpenID), prior to step “Redirect to URL”, the entered identity URL is accessed by the Relying Party (he calls it the Server in his diagram). In LID’s case (now obsoleted, due to Yadis), to determine the version of LID running at that URL, in OpenID’s case (about to be obsoleted for OpenID 1.2, due to Yadis) to determine the location of the identity server and an optional delegate, and in Yadis’ case, to obtain the content of the XRDS file. So there is a back-and-forth missing. (Also, to further complicate matters, in LID we do now capability caching, so depending on the state of the cache, some of this does not actually occur any more)
- There is also communication between Relying Party and Identity Provider (he calls them Server and URL Server, respectively). In LID’s GPG-based SSO case, the Relying Party obtains the public key for the identity. In OpenID’s case, the Relying Party creates an association or performs a check_authenticate operation. This operation is not visible in the browser, because it does not involve the browser, that’s probably how he missed it.
He goes on to ask what happens if somebody else takes over your URL (e.g. because you didn’t pay for the domain name renewal.) This is a good point, and some version of it is a risk in any identity system I am aware of. In LID, we recommend that Relying Parties cache the user’s public key and become suspicious if the public key changes. While this is not a full solution, it does make short-term DNS poisoning a bit harder, however.
Finally, he makes a quite compelling case for where traditional identity ceases to be useful and user-centric identity becomes essential. Let me quote the entire paragraph:
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).
Which is why user-centric identity is finding adoption first on the public internet, and while traditional identity technologies are virtually invisible on the open internet.
All in all, great post, Coté, I very much appreciate it, please write more! ;-)