You are here: FIDIS Interactive > FIDIS Database on IMS > 

FIDIS Interactive

More about this database.

Database on Identity Management Systems

Back

“Light-Weight IDentity (LID) (Version: N/A)”:

Manufacturer of the IMS

  • NetMesh Inc.
  • URL: (Visit Homepage)
  • Nature of provider / distributor: Private company
  • Nationality of the manufacturer: N/A

Type of the IMS / Class of the IMS

  • Type of the IMS: N/A
  • Class of the IMS: Class 1

Supported languages

  • England: English

References for the IMS

Is the IMS an open/closed IMS?

State of IMS deployment

Distribution of the IMS

Geographic scope

Is the IMS an open/closed IMS?: Open

State of IMS deployment: Prototype

Distribution of the IMS: N/A

Geographic scope: Global

Hard and software requirements of the IMS

Hardware: any; Software: Web Server or Application Server, either Perl or PHP or Java/J2EE (recommended)

Installed base of the IMS (Userbase)

More than 10 million enabled users

Interoperability and supported standards

The protocol and the reference implementation are open (and quite concise), so interoperable implementations should be easy.

 

Supports the Yadis, OpenID, PGP, VCard, XML, XPath, HTML standards.

Interoperable implementations exist from vendors such as Six Apart, Jan Ran and Verisign.

 

Server-side component(s)

PHP and Perl implementations: CGI-script (The user runs the server-side-component. It is assumed, that he/she has control over the server.) Java/J2EE implementation: Server-side component is a collection of Servlets. Persistence in a relational database (e.g. MySQL)

Client-side component(s)

Can be used in thin-client and rich-client environments. No requirements in case of thin clients.

Description of functionality / features (client and server)

The salient idea behind LID is to use the URLs of CGI scripts as "smart pointers" to personal information. URLs are commonly accepted identifiers on the Internet, and the script referred to by the URL can actively check requests for the data before returning any. The architecture is totally decentralized and relies on HTTP as the only means of communication.

    

Creation of accounts/IDs:

The user creates an identity by installing a perl-script on a web server maintained by him/her or a trusted party. The personal information is stored in vcard (RFC2425) format on the web server and can only be accessed by the script. Social links to other people and another set of personal information can expressed in a FOAF ( xmlns.com/foaf/0.1/) file, again only accessable for the script.



LID allows to have arbitrarily many IDs (Pseudonyms). To make this easier, the pseudonymous scripts may delegate requests opaquely to other scripts that process the personal information.

    

Web Single-sign-on:

The users gives a website his/her LID-URL. The website then sends a redirect to the LID-URL, together with a cookie to tie the browser to the LID-Id. The redirect gives the script behind the URL additional parameters like the URL of the website, a nonce, the action requested from the script (authentication in this case) and the type of authorization accepted at the website. The user’s browser follows the redirect and calls the LID-URL with the parameters. The script signs the nonce, URL and action strings using public key cryptography (gnupg) and returns it through another redirect to the website. The public key is bound to the LID-URL, not an e-mail address as suggested by the OpenPGP standard. The website can request the public key directly from the LID-script, and check if the signature on the authentication data is valid. If so, the browser proved that it exerts control over the script behind the LID-URL, which can then be used as identity for further transactions.

    

No PKI is necessary for LID itself, the script returns its own key on request. To secure transmission of keys, HTTPS can be employed with the partial PKI already employed there.

    

Personal Information:

Personal information (vCard or FOAF) can be requested by simply calling the LID-script of the ID (the URL of the scrit _is_ the ID). The user may configure the script to act differently when given additional parameters, for example the LID-ID of the requesting party. A possible application is to give only general information by default and give selected information (phone numbers, e-mail address) only to a set of configured LID-IDs.

Encryption through PGP and Diffie-Hellman shared secrets. RESTful. Rich and thin clients. Availability, integrity and confidentiality through standard web methods (e.g. server mirroring, SSL, public key encryption etc.)

 

Through the additional Yadis protocol, LID services may run at URLs other than the identity URL. That way, a simple HTML markup in the HTML HEAD section is sufficient to turn any URL into a LID URL (without the need to run CGI scripts at that URL)

 

There are also now additional features such as authenticated messaging (similar to e-mail, but from identity URL to identity URL, without the ability to spam)

Main functionality

Purchase costs in EUR

0 (NetMesh InfoGrid LID is distributed under two licenses: open-source and commercial. The idea is a “tit for tat”: if a developer open-sources all of their code, InfoGrid LID is free and open-source, too; if not, it isn’t either.)

Flow charts of the IMS

Screenshots of the IMS

Other file resources

N/A

Evaluator of the IMS

Denis Royer (JWG)

General Comments (free text)

Though "Class 1" is correct, InfoGrid LID has many features not traditionally considered identity management (e.g. social networking)

Back (This Record was last updated on: 17-04-2008 16:21)