OpenID & LID

[Brad Fitzpatrick]

On Tue, 28 Jun 2005, Johannes Ernst wrote:

> Thanks Brad for the prompt response.
>
> Let me ask some questions about what you wrote however.
>
> > LID -- Assumes that identity URLs are dynamic documents that can
> > handle
> > fancy URL parameters. No true in real life, which is key for adoption.
>
> I think that's rather a blanket statement. 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).  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?

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.


> If so, I understand the design tradeoff you made. However, you
> introduced other complexities, such as additional servers, additional
> tags in HTML that users aren't used to, either, nor tools other than
> the ones under your control, additional requirements for parsing
> those tags, additional overhead for downloading home pages to get at
> the tags etc. etc. none of which one needs to do with LID.

Fair enough.  But I don't feel it's that complex.  I was able to get the
first version working in under a week, most of it in the first couple
days.  And then only ~month for community review/happiness.

> Also, adding LID support to a blog URL is not exactly hard: my own
> Blosxom blog required the addition of two lines of Perl to blosxom.cgi.

Again, Perl.  What about static blogs?

> I absolutely don't want this to turn into any sort of heated argument,
> but hope you'll agree with me that there is a tradeoff between the two
> alternative which you chose to make in one particular way for your own
> reasons.

I won't disagree about trade-offs.  In the end we both feel we chose the
best ones, so I'm happy leaving it at that.

> > Also combines too much functionality (authentication + profile
> > exchange) into one spec, which in turn increases the number of
> > dependencies required for a site to implement LID (XPath, etc.) I
> > believe profile exchange should be a separate component/step built on
> > top of authentication, not coupled with it.
>
> I apologize in advance for this, but this is a little funny: one of
> the major criticisms we got from the "digital identity establishment"
> on LID was a blanket statement that it was waaaayyy too simple and so
> could not possibly be useful (nobody has presented a case for what
> use cases we can't support with LID, as far as I know, so I take this
> with a grain of salt). And you are saying that it is too complex...
> hmm ...

Heh.

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

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

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.

- Brad