Clarifying some things about LID

[Ernst Johannes]

A number of people on this list seem to think that LID is hideously  
complex. A number of people (mostly off this list I think) seem to  
think that LID is so simple that it cannot possibly be useful for  
anything.

This is somewhat amusing, and I suspect the truth is somewhere in the  
middle. Let me try to clarify.

First, LID 2.0 is built from profiles, and the implementor decides  
which and how many to implement. See http://lid.netmesh.org/wiki/ 
LID_2.0_Profiles for a list.

Each profile adds additional capabilities -- if you don't want, say,  
LID-authenticated messaging, well, don't implement the LID POST  
profiles. There is no requirement at all that you need to implement  
all, or even most, LID profiles.

LID 1.0 wasn't built from profiles -- consequently, when Brad looked  
at it, it had more features than he needed for his purposes and said  
it was too complex. That's where the quote comes from that seems to  
be floating around.... We realized the same thing around the same  
time, as we discovered more and more cool things that one could do  
with LID, and so we broke it into profiles for LID 2.0 -- so people  
can implement what they think is useful for them, and skip the rest.

The LID SSO Profile and the LID Relying Party Profile are together  
about as complex or simple as OpenID, as they solve largely the same  
problem in largely the same way, except that OpenID uses DH and LID,  
by default, uses GPG. I'd be very surprised if the code required to  
implement either was very different in length either.

When there is discussion now to use certain LID features (e.g. VCard  
profile exchange) with OpenID in connection with YADIS, some people's  
gut reaction seems to be "but I don't want to implement the OpenID  
SSO functionality again the LID way, AND then add the LID profile  
exchange and a zillion other LID features that I don't want". Well,  
the good news is that you wouldn't: you would not implement LID SSO  
and LID Relying Party (because OpenID provides that functionality),  
you wouldn't implement any other LID profile you don't want, just the  
LID Traversal Profile and the LID VCard Profile -- which boils down  
to the following:

To use LID profile exchange for VCard-type information, your OpenID  
identity server should respond with the user's VCARD to queries like  
this one:

IDENTITY.SERVER?id=OPENID&xpath=/VCARD

Parameters:
     IDENTITY.SERVER: the URL pointing to the openID identity server,  
obtained from the HTML HEAD section
     OPENID: the URL that identifies the user whose profile we are  
querying
     /VCARD: the expression that says "we want this user's VCARD".

Personally, I don't think it can be made much simpler, other than  
putting the VCARD information right in the HTML page, where it would  
be difficult to use computationally and very hard to filter for  
different audiences.

And yes, you can use more LID profiles if you were so inclined, in  
connection with the above, say: the LID FOAF profile, or the LID  
Format Negotiation Profile (so you can return VCard info using  
different formats such as html, xml, and application/x-vcard) But you  
don't have to, and that's the most important thing I want to convey.

Please ask questions ...


Cheers,



Johannes.



Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051029/2e5ebe8d/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst