Progress and some thoughts
meepbear at hotmail.com
Tue Jun 21 15:40:43 PDT 2005
>I don't follow -- if my consumer gets the server's key from the UA, how do
>I know that a server was involved at all?
My problem is actually with the user being able to arbitrarily decide where
the consumer will connect to. Someone could put in a legitimate URL, but
they could also put in the URL of a server they control which does nothing
but accept incoming connections and then stalls, forcing the consumer to
wait until its timeout since it can't tell the difference between an attempt
to waste server resources or a slow connection, or it starts dumping huge
amounts of data in the hopes that the consumer's implementation doesn't
restrict the amount of data it's willing to get from an URL.
Or they could supply the URL of a totally unrelated site where the query
string is used to perform some action for the user with the consumer's IP or
exploits a vulnerability.
The only part where there is any guarantee that the other isn't malicious
seems to be after the user approves the consumer and then only on the openid
>The whole point of having the UA bring back a *signed* verification token
>is to verify that the token originated at the server. In order for the
>signature to mean anything, we have to be reasonably convinced that only
>the server and the consumer know the secret key.
Currently, yes :). If the UA knows the shared secret, it can spoof identify.
I meant about the original way the protocol seems to have worked though. It
doesn't matter if the UA has both the consumer and server public keys.
Without a private key it couldn't do anything.
But like you pointed out, one needs a guarantee about the other's key or the
UA could bypass the server completely but I don't see a way how either of
them knows connecting to the other isn't going to result in an action that's
>It may feel unnecessary in the "legitimate" case when you did supply a URL
>and click a button.
>On the other hand, the server doesn't know that you supplied a URL and
>clicked a button. Maybe you thought you clicked "About Us" on my website,
>but my website redirected you to livejournal without your asking, in an
>attempt to figure out who you were. So, if you show up at the server with a
>request to give your identity to a server you've never approved before, the
>only safe thing for the server to do is to stop and make sure you know
But the consumer can only know your URL after you've already supplied it at
least once. A rogue site could attempt to ID me without my knowledge, but
that would do no good since livejournal can't ID me without the URL to my
blog even if I am logged in to it.
If I already identified once then the site wouldn't bother contacting the
openid server again since it has what it wants already. As far as I
understand it the expiration on successful ID is only if the consumer plays
nice, but there's no consequence if it decides to hold on to it
Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
More information about the yadis