* * * * *

                      Identity, Authentication and Trust

I'm reading about LID (Lightweight IDentity) [1] (first at Burningbird [2],
then on Flutterby [3]) 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:** [email protected]
* **URL (Uniform Resource Locator):** 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)

* **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 (Lightweight IDentity) (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 [4] (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 [5], Techdirt [6],
Flutterby [7] 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 [8] or Thawte [9] 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.

[1] http://lid.netmesh.org/
[2] http://weblog.burningbird.net/archives/2005/01/10/your-digital-self/
[3] http://www.flutterby.com/archives/comments/7646.html
[4] http://slashdot.org/
[5] http://www.kuro5hin.org/
[6] http://www.techdirt.com/
[7] http://www.flutterby.com/
[8] http://www.verisign.com/
[9] http://www.thawte.com/

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.