Super all-comprehensive specs/overview page (fwd)
brad at danga.com
Mon Jun 27 09:31:39 PDT 2005
On Mon, 27 Jun 2005, Paul Crowley wrote:
> > Sorry -- explain to me the problem you see? (or not, if you feel it's not
> > a big deal...?)
> A careless consumer might cache the information that "the OpenID server
> for http://bob.livejournal.com/ is
> http://www.livejournal.com/openid/server.bml" after reading
> "http://bob.com/". That allows bob.com to poison the cache. To avoid
> these attacks, what the consumer has to record becomes more complex.
Ah. My implementation doesn't work like that, so I wasn't seeing it.
In the end I'm not so concerned, though: I imagine there will be about 5
or 6 OpenID implementations and they'll be heavily audited. I'd guess
that any popular site, popular enough to make it worth poisoning, would
run a respectable OpenID library, or at least have the resources to fix
their bugs once reported.
The alternative is to ditch openid.delegate altogether, which I'm still
fine with. The advantage was cache efficiency, but I could make LJ users
who want to use OpenID on external sites have a new <link rel='...'> that
isn't part of the spec and not munge up teh openid.server URL endpoint at
all. I just wouldn't let an LJ user declare an external site as theirs
unless LJ was able to crawl it (once) and find their LJ link rel tag.
More information about the yadis