Maximizing cacheing of server secrets

Paul Crowley paul at
Sun Jun 5 08:53:20 PDT 2005

This is just a little extra for my list of odds and ends.

We want to be able to use the same cached server secret to authenticate 
more than one user on that server.  However, the URLs for those users 
are different, so how are we to know that we can re-use these server 

Consider the "Randy attack":

To understand the attack, remember that LiveJournal neither knows nor 
cares who really controls  Any LiveJournal user can tell 
LJ that they control, and LJ will not try and find out if 
they're telling the truth.  So if the owner of is to say 
which user is allowed to assert identity with that domain, they must say 
it in the URL that references as the identity server. 
Something like:

<link rel="openid.server" 
href="" />

Meanwhile, I'll put something like this on the index page of

<link rel="openid.server" 
href="" />

Now, if has successfully authenticated Brad, it will have an 
authentication key from LJ, which they'll associate with the URL

So when I go to log into the same site, it won't reuse that secret, 
it'll fetch another one.

The most straightforward and secure solution I see is to separate out 
the function of delegating identification from performing it.  Brad and 
I put URLs more like this on our web pages:

<link rel="openid.delegate" 
href="" />

and that page contains

<link rel="openid.server" 
href="" />

So when I claim to be, will follow the 
delegation and ask if I'm really - a question that 
LiveJournal is in a position to answer authoritatively.  LiveJournal 
will simply refuse to assert any URLs about which it cannot speak 
authoritatively.  And the openid.server URL will be the same for me as 
for Brad, so it can stay in the cache.

If I don't want to give away what LJ user I am to, then as 
Brad suggests, I can delegate to a URL like

I can press a button and ask LJ for an anonymous ID and it'll give me 
one like the one above, up to some maximum.  All of these URLs lead to a 
very short page that just says

The advantage of this over the ljuser_sha1 scheme Brad outlined at one 
point is that even if I guess that brad is the true owner of (who'da thunk it?) I can't confirm my guess.  No changes to 
the OpenID protocol are needed for this; it's just a feature LJ can 
support if it so chooses.

A final quick point for consideration - should we provide a way for 
consumers to know, if the server wishes them to know, that and are one 
and the same?  This would be done with a third kind of link header, 
something like

<link rel="openid.canonical" 
href="" />
\/ o\ Paul Crowley, paul at

More information about the yadis mailing list