Super all-comprehensive specs/overview page (fwd)
brad at danga.com
Mon Jun 27 08:31:00 PDT 2005
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
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...?)
More information about the yadis