Clarifying some things about LID

It’s quite a surprise to me to meet so many people at Digital Identity World who know what LID is, who have heard my name and even some who knew about the 4-Point Architecture that I recently blogged about. There are some frequently asked questions that I’m getting on LID that I’d like to answer on this blog as well for everybody else who probably has similar questions.

Why do you use PGP/GPG for signing in LID?

It was the simplest and most widely available algorithm that we could think of, and thus a good candidate according to the old principle of "don’t reinvent unless absolutely necessary" (that’s also why we use XPath, and XML, and URLs instead of, say, URNs, new web services protocols and browser plugins or whatever else we could have thought of.) Note that if you don’t like GPG, for whatever reason, you can simply specify a new value for the credType tag, convince people that your alternative is better, and that’s it. There’s nothing in LID that prevents that and by explicitly making vocabularies extensible, we really want to encourage you to try out new things if you think they are better for some reason.

Does LID use the same trust model as PGP?

Yes, but it improves on it. PGP suffers from the problem that key servers (that exist so Alice can find Bob’s public key) can be spammed as they only use Bob’s (often unauthenticated) e-mail address as a means to identify a public key as being Bob’s. LID does not need key servers as each LID URL is its own key server (by using the meta=gpg%20-export%20--armor argument). As each LID URL is under control of its owner, PGP public keys used in conjunction with LID are actually safer than PGP is on its own.

How do you prove in LID that it is really you?

That’s a question I’m hearing quite often. And it is best answered by a counter-question: without LID, how do you prove it is really you, on the internet or elsewhere? Some people answer: I can show you my driver’s license. To which I respond: which proves nothing, other than that you have the ability to pull out a card from your pocket with a picture that looks more or less like your own. (Anybody, like myself about 11 years ago, who in response to me showing my passport at the check-in to an international flight got the following response: "Oh, that is quite obviously a fake passport." can relate to my point here. The way I convinced the scpetical security officer was by also showing him a driver’s license, several credit cards, etc.). All the problems that LID may or may not have in this respect are the same as in the real world. But:

There is no reason why you can’t return a picture or a fingerprint from a LID URL, just like a driver’s license does, and some LID users actually do that (not the fingerprint, just the picture ;-)) We also recently added a protocol for third-party confirmation of assertions (aka claims) that somebody is making about themselves via their LID. It’s described in the white paper on the LID site. That way, you can serve all information on your driver’s license to whoever you’d like to make this available to. And using this protocol, you can then get the government to agree with you that you are making the correct statement (assuming you can get the government to support LID 3rd-party confirmations, and assuming that your client actually trusts your government’s assertions about you). And all without the government (or whatever 3rd party) knowing who is asking for confirmation from you and for what purpose.

Can my ISP masquerade as myself?

If you let an untrustworthy party host your LID identity, they will indeed be able to masquerade as you. If you don’t like that, you should host your own LID URL or find a more trustworthy provider.

Isn’t LID too simple?

That’s my favorite one. I’m tempted to respond: why are you asking? Did anybody tell you that digital identity had to be mindbogglingly complex and that’s the reason you had to buy their very expensive product or implementation services? They would also probably tell you that SMTP was never going to fly, and certainly not HTTP because it was waaayyyy too simple. It turned out that these protocols’ very simplicity made it possible for others to build on them as a trustworthy (because easily comprehensible) platform, and we would never have gotten the internet as we know it today if it hadn’t been built from those simple parts. I’m very tempted to predict that if we ever going to get the Digital Identity Big Bang that so many are predicting (hoping for?), the underlying protocols are going to be much closer to LID in complexity (or lack thereof) than they are going to be to, say, an entire WS-* web services stack.

What’s your measure of how complex a single-sign-on technology can be so it can be adopted broadly?

A weekend of implementation effort, maximum. Here’s why: SSO only makes sense if basically everybody can implement it. That includes a lot of players, from your 401k plan (who could probably afford a lot more than that) down to the message board of the parent-teacher assocation that’s run by Joey’s dad on his home Linux server. Joey’s dad is not going to spend more than a weekend of his time to make it work. He’s also not going to go out and buy expensive software. He might download some Perl, but that’s about it. Ergo: one weekend, no more.

But implementing LID SSO right now requires more effort than that.

Touche. But not for much longer: we are working on a blueprint for a LID SSO site that makes it really easy for existing sites to support LID SSO. The NetMesh Developer Website is going to be the first site following that template, and we hope to have it ready in a week or so.