Super all-comprehensive specs/overview page (fwd)

[Brad Fitzpatrick]

On Mon, 27 Jun 2005, Paul Crowley wrote:

> Martin Atkins wrote:
> > Regarding the identity delegation stuff, it says that in order to
> > declare delegation you must include the following:
> > <link rel="openid.server"
> >       href="http://www.livejournal.com/openid/server.bml">
> > <link rel="openid.delegate"
> >       href="http://bob.livejournal.com/">
>
> Eek.  This wasn't what I had intended - in fact, I considered proposing
> this as a change, but decided not to.  I had imagined that any given
> page would have at most one of these declarations, and that you'd follow
> the delegation chain until you got to a server declaration.
>
>
> The advantage of doing it this way is that the consumer makes fewer GET
> requests.

That's a big advantage!

> The disadvantage is that you have to be very careful - you're
> making an OpenID request for "http://bob.livejournal.com/" on
> "http://www.livejournal.com/openid/server.bml", but you mustn't assume
> that the latter is actually the idserver for the former, only that this
> pair is the (delegate, idserver) pair for "http://bob.com/".
>
> Otherwise you leave yourself open to a sort of cache poisoning attack
> like DNS.  Given how hard it is to specify DNS so as to avoid cache
> poisoning attacks, I'm really nervous of doing things this way; I'll be
> amazed if we never see an implementation that gets this one wrong...

I don't see how it's any more or less work in either of the two cases from
a consumer point of view.  (and it's absolutely the same (none) amount of
work for a server....)

In both cases the consumer needs to keep track of the starting point
(bob.com) in its return_to URL (or somewhere else) because the server will
only ever assert the final URL.

Sorry -- explain to me the problem you see?  (or not, if you feel it's not
a big deal...?)

- Brad