Tuesday, February 01, 2005
Identity, Authentication and Trust
I'm reading about LID (first at Burningbird, then on Flutterby) and while a decentalized lightweight identification (with authentication and trust) system seems like a nice idea it comes across as being a bit clunky in actual implementation.
First, there is identity. Second, there is authentication. Third is trust. They're related, but not the same.
My identity is me. For instance:
- Name:
- First: Sean
- Middle: Patrick
- Last: Conner
- Email: sean@conman.org
- URL: http://www.conman.org/people/spc/
- Public Key: 0123456789ABCDEF…
- Address:
- Living:
- Street: 123 Main St. #9
- City: Boca Raton
- State: Florida
- ZIP: 33431
- Country: US
- Billing:
- Street: 123 Main St. #9
- City: Coral Springs
- State: Florida
- ZIP: 33065
- Country: US
- Shipping: (same as billing)
- Living:
- Telephone:
- Home: 555-555-1212
- Cell: 555-555-1213
- Work: 555-555-2121
- Credit Card:
- Type: ACME
- Number: 1234567890
- Expiration: 12/09
Basic information about me that websites typically are interested in (but not all websites want all this information about me). This is the type of information that could be stored in the browser and if a website wants any of it, it can query the browser for it (of course, I can configure the webbrowser to, say, always serve up my name, URL and email address, but ask me if a website wants anything more, like shipping address or credit card number). But LID (and most other digital identity schemes) always place this data on a server somewhere. While LID is decentralized (I can run my own LID server) it's still information that needs to be protected on a server. I personally would feel a bit better if such personal information were “closer” to me, like on the computer I'm sitting in front of. Then again … having this information on a server elsewhere means I can use reference it (use it) from any computer I happen to be using (say, one at a library).
My authentication is something that others bestow on my identity. If I want to post to Slashdot (for instance) I have to present my identity (or only that portion of my identity that Slashdot actually needs) and they have to check to see if I'm allowed. Nothing outrageous here, but I still have to be checked out by each site I'm interested in, like kuro5hin, Techdirt, Flutterby and others, but once credentialed by each site, I can then use it without having to remember (or write down) scores of userids and passwords (like I have now).
Trust is a way of saying that the identity I presented above is me and not made up or the identity of someone else. When you get a secure certificate for a website from VeriSign or Thawte you present verifiable information to them, pay them quite a bit of money and they'll give you an electronic certificate that basically says “Yup, we trust that this is the company you are communicating with.” But LID is similar to using certificates from ACME. Who's ACME and why would I trust them? At least I've heard of VeriSign and Thawte so I'm more likely to trust them more than ACME. I haven't seen anything in LID that would enable me to confer trust; it just seems to be a way to keep the number of different userids and passwords to a usable number (like one pair).
The clunkiness I see partly comes from some of the URLs used to request
various bits of information. A URL like
http://lid.netmesh.org/liddemouser/?xpath=/VCARD/EMAIL/USERID;action=text/xml
is normally not seen—semicolons are for path parameters, not query parameters. And checking the code I see:
# this is the list of all URL parameters that will be evaluated by this script.
# The CGI:: module messes up POST vs. URL args, so some of those are accessed as url_param
my $action = $q->url_param('action');
my $clientid = $q->url_param('clientid');
my $credential = $q->url_param('credential');
my $credtype = $q->url_param('credtype');
my $help = $q->url_param('help');
my $login = $q->param('login');
my $meta = $q->url_param('meta');
my $target = $q->url_param('target');
my $ticket = $q->url_param('ticket');
my $ts = $q->url_param('ts');
my $path = $q->url_param('xpath');
my $url = determineUrl( $q );
# this is the list of all URL POST arguments that will be evaluated by this script
my $username = $q->param( 'username' );
my $password = $q->param( 'password' );
To me, it looks like the author got confused as to how queries are passed to CGI scripts using the GET method (the name/values pairs are supposed to be separated by ‘&’, not a semicolon, which is used for something else in URLs). To me, this doesn't bode well.
Also, playing around and signing up (using the demo account provided) to the two sites that support LID wasn't smooth.
Given time though, this may work out.
