In an analogy to Pingbacks, Mike Bijon (aka Moogle1) proposes to create a higher-level specification by which bloggers can express trust in other bloggers. Actually, I think it is about people with a URL expressing trust in each other, closely related to URL-based identity. Certainly he says that it would require an identity system and I suspect he’s thinking about URL-based identity in that context.

I very much like the idea, once the somewhat difficult details are filled in. He says:

I should be able to maintain a skill profile for my trustbacks to better show the credibility of my skills and to avoid the “list of my friends” that seems to be the core of most current social networks …

As I’ve said repeatedly before, I might trust somebody to write correct code but not trust them to babysit my kids; and vice versa. There are many examples like that. So unless "trust" is qualified with "about what", it indeed turns into a glorified list of "all the people I know" very quickly.

Unfortunately, the "about what" seems to require a full, life-scale ontology in the general case, and I haven’t seen a proposal yet to simplify that dramatically without limiting usefulness too much — or accidentially expressing the wrong "about what" to consumers of trust information.

He writes:

Why can’t sign-on work like this?

1. The user goes to the site’s URL (www.buycrap.com)
2. Before they can buy something, the user has to enter their email username and password (Jason@jasonkolb.com and test123)
3. www.buystuff.com looks up the email server for jasonkolb.com from the domain registrar (using the domain’s MX record). We now have a server that can authoritatively identify the user.
4. www.buystuff.com sends the email server the email address and password that it was given. If it’s able to authenticate, the user can be positively identified as Jason@jasonkolb.com without the need for any further logins and passwords (and without even needing to STORE a password, of any kind!).

Wow. In this proposal, it only takes one single corrupt employee, or a single security breach at any one of the hundreds of sites he might want to authenticate with over a few years, to allow that single employee (and the crooks behind him — there are markets for stolen identities!) to impersonate him all across the web.

His workaround — asking for browser extensions that intercept username (here: e-mail address) and password, and hash it, and then forward in hashed form to the authenticating e-mail host — won’t fly either: how many sites today use HTTP Auth and the built-in browser support compared to their own HTML login form? I can’t think of a single site with mass appeal that does that … whatever their reasons, those reasons will apply the same for his proposal. And then there is the major issue that existing e-mail servers would all have to be upgraded.

Also, I’d wonder how many people would be happy to give our their e-mail address to any site at which they authenticate. I certainly wouldn’t …

While using identifiers that we have already — e-mail addresses — has a certain appeal over having to introduce new identifiers, like Yadis URLs (at least for those people who don’t have any home page yet), so far I haven’t seen a proposal for a viable internet-scale authentication system built from e-mail addresses.

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:

• OpenID,
• LID,
• Sxip

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:

1. I go to Lala’s for a Wild Turkey and Lonestar.
2. (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.
3. I say, “come one, I’m over 21. Look at the beard!”
4. The bartender sighs and says, “I don’t trust your claims, show me your ID.”
5. 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.
6. 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).
7. 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!

From a Higgins talk at EclipseCon.

Higgins is a software framework that integrates

• identity data
• profile data
• relationship data

within and across multiple systems.

This quote, and the accompanying 6 slides are the best summary of what Higgins is all about that I have seen so far. Recommended.

Download PowerPoint slides.

Some time ago, I decided not to regularly empty my spam folder any more. And today, I’m proud (?) to announce that it now contains 100,063 spam messages.

100,063 pieces of spam! All to me!

What is the world coming to. Two and a half years ago I wrote a piece called "Death of e-mail?", and unfortunately, my views haven’t had a reason to change on this since. We all hear lots of talk about grand plans how the spam problem will be solved, but I can’t see much actual progress.

My proposal from back was made prior to LID and Yadis, and so today I would write it in those terms. But the essence of it is still valid, I think. Anybody want to go and run with it?

Time to clean up that spam folder …