Progress and some thoughts

[meepbear *]

>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 
server's side.

>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 
potentially malicious.

>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 
>what's happening.
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 
indefinitely.

_________________________________________________________________
Free blogging with MSN Spaces  http://spaces.msn.com/?mkt=nl-be