The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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:

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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.