TABLE A – Verification of Data 

Data held in database 

Yes/No 

Correction / Completion 

Evaluation of IMS 

Evaluator:  

Martin Meints 

Organisation:  

ICCP 

Date of evaluation:  

04-Jun-2005 

N 

substantially extended since 

Identification of IMS 

Sources of information:  

Version:  

N/A 

Manufacturer:  

NetMesh Inc. 

Nature:  

Private company 

Country:  

USA 

Regions:  

Global 

Language:  

ENGLISH 

State:  

Prototype 

No 

Beta; deployed both on the public internet and inside corporate enterprises today 

Open/Closed:  

Open IMS: the identities work with several systems or applications. 

No 

Not just “several” but LID has been constructed explicitly with the goal of “internet scale”: thousands or millions of systems and applications from a variety of vendors, open-source projects etc. 

LID functionality can be extended and augmented by implementers / deployers. 

Platform & Environment 

Requirements:  

Hardware: any; Software: Web Server, Perl, Open Source components 

No 

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

Number of users:  

unknown - because of decentralised approach 

addition 

More than 10 million enabled users 

Standards:  

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

addition 

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

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

Description of Server - Side components:  

CGI-script (The user runs the server-side-component. It is assumed, that he/she has control over the server.) 

No 

In the PHP and Perl implementations, this is correct. In the Java/J2EE implementation, the server-side component is a collection of Servlets. Persistence in a relational database (e.g. MySQL) 

Description of methods:  

Addition 

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.) 

Descriptor of Client -
Side components:

Addition 

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

Seals:  

No  

Which seal:  

Third party:  

no 

Yes 

Which third party:  

Yes 

Versign, Six Apart, Jan Rain, RSS, Atom etc. 

Features:  

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 ( http://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. 

Addition 

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) 

Screenshot picture:  

http://lid.netmesh.org/

Flowchart:  

TBAL

Cost 

Price:  

0 

No 

NetMesh InfoGrid LID is distributed under two licenses: open-source and commercial 

Comment to the Cost:  

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. 

Type & Class of IMS 

Type of IMS:  

Type 3: IMS for user-controlled context-dependent role and pseudonym management.  

Addition 

Also suitable for Type 1 

Class of IMS:  

Class 1: Pure IMS which main objective is to support or implement identity management functionality. 

Addition 

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

Functionality:  

decentralized SSO, Globally Unique Identifiers, "Smart Pointer", social networking functionality 

Addition 

Profile exchange, authenticated messaging, sessions, public key distribution, account management functionality, logging, access provisioning, filtering of incoming communication, single-sign-on 

Suggestions: