OpenID & LID

[Ernst Johannes]

>> Might it be more accurate
>> to say that one of your goals was to let LiveJournal users use their
>> blog URLs as their identifiers without requiring changes to  
>> LiveJournal?
>
> No, because I didn't just design for LiveJournal.  I designed it so I
> could use bradfitz.com as my identity (which is a static HTML  
> file).  I
> designed it for all Movable Type websites out there (static HTML  
> files).
> I designed it for TypePad (also static HTML files).

I stand corrected, then, about the number of products you've been  
looking at.

>   Do I think that
> static publishing is kinda lame?  Yes, but it's a reality.  And  
> once we
> went down the road of using URLs instead of email-looking-things, I  
> wanted
> those URLs to be useful info.  And if you'd counter saying that  
> your LID
> URL should be useful, then I'd ask what to do about people who have a
> useful static page, and also want LID -- they'd need their blog/ 
> profile
> page (static) and then also a LID URL.  Which is the definitive URL?

Ah, but that's where Apache's "DirectoryIndex" directive comes very  
handy.

For example, the LID Perl scripts that we have on
     http://lid.netmesh.org/
can be installed as "index.cgi", in addition to a "index.html" from  
the static content that somebody might have there already. By saying
     DirectoryIndex index.cgi index.html
Apache will run the script first, if it is there (for the root URL  
that's the LID URL), and the script then simply pipes through the  
home page if no other request has been indicated through URL arguments.

See
     http://lid.netmesh.org/docs/netmesh-lid-perl-installation.html
look for "DirectoryIndex".

While there is some overhead going through Perl (or whatever  
scripting language), it's not very much: "if no arguments, pipe back  
file". And it is only that single URL of the many on a typical blog.

> If you would've made a <link rel..> to point to a LID endpoint, I'd
> probably really like LID.  I might even deal with the XPath  
> dependency.

The XPath dependency only exists if you want to do structured queries  
on structured information published by the user. It you only want to  
do "give me the whole VCard file" or stuff like that, there's no  
XPath dependency. Certainly not for SSO. Another example for why LID  
profiles may turn out to be a really good idea ...

<some conversation deleted that I think I addressed with the above>

>> But to address both "too light" and "too heavy" arguments, the LID
>> 2.0 protocol(s) have been broken into individual profiles that LID
>> URLs as well as LID Relying Parties may or may not support.
>> MinimumLID is defined in the wiki at:
>>      http://lid.netmesh.org/wiki/index.php/MinimumLID
>> and an ever-growing list of additional, optional profiles can be
>> found at
>>      http://lid.netmesh.org/wiki/index.php/LID_2.0_Profiles.
>>
>> One of the benefits of this approach is that people anywhere can
>> innovate around LID with new profiles for new applications without
>> any single person or organization or spec being the bottleneck.
>>
>
> I'm glad you're doing that.  I'll give it a look when I get some free
> time.

Would appreciate your input -- or whoever wants to comment.

>>> (yes, the LID people are now working on decoupling this, but it  
>>> wasn't
>>> done when I looked at it.) It's possible we might use LID as one of
>>> our recommended profile exchange mechanisms in the future, but the
>>> spec as a whole was too heavy.
>>>
>>
>> Glad to hear that. What could we do to help with that?
>>
>
> Just keep us in mind as you develop it.
>
> I'm gone for a week for my brother's wedding and some vacation.   
> While I'm
> gone I'll likely be doing some light reading and thinking, but not  
> so much
> writing/typing.  I'll also be thinking about private profile  
> exchange and
> how LID works in.  I remain convinced that most public profile  
> exchange
> just needs HTTP getting FOAF/Atom/RSS, but things like sharing email
> addresses people might restrict to trusted parties.

I think this issue is addressed very elegantly in LID. Because the  
client (who's doing the querying) can specify their own identity in a  
query, the server (who's thinking of responding with, say, a phone  
number or e-mail address) may return different information to  
different people. That way, for example, I can let my friends have my  
home phone number, and maybe my boss, without having to let everybody  
else have it.

I guess it's pretty obvious to everybody that if one has an open- 
ended list of vocabularies -- as we have in LID -- this approach  
could be extended to lots of other information, such as calendars  
("only show blocked time to people not in my company and never show  
therapy sessions to my employer"), OPML files, etc.

> Thanks for posting this, btw.  Hopefully we can work together... a  
> bunch
> of independent identity groups working together is better than 500  
> page
> specs by multinational corporations with licensing fees.

In my mind, both OpenID and LID use a REST-ful approach to digital  
identity, while virtually everything else there is bases theirs on  
SOAP/WS-* in one way or another. There's nothing wrong with WS-*, in  
particular in a corporate environment, but serious questions have  
been raised by many whether WS-* will ever be ubiquitous. I don't  
know the answer to that one, but I do know that REST-ful digital  
identity is something useful for many application areas ... attaching  
it to blogs is a great one.

Cheers,



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/20050628/e6320ede/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst