Hmmm....yes, the race condition you outlined is a possibility in this arrangement.<br><br>To alleviate this, perhaps the nonce and OpenId URL should not be part of the RP endpoint URL at all, but instead should be part of an html form submission. That way, when the desktop client "logs into" an RP, the desktop client will provide the nonce, as well as the openid that was originally associated with the nonce.
<br><br>In this setup:<br><br>1.) The nonce should be large, and hard to guess. <br>2.) If an attacker did happen to guess a proper nonce, then he would have no idea what openId URL to associate it with (assuming the previous step of the protocol were done via SSL)
<br><br>Seems to me that guessing an RP endpoint, a nonce, and a corresponding openid would be about as easy as guessing somebody's username and password. <br><br>This is a concern, though, so I'd like to hear more thoughts on it.
<br><br>david<br><br><div><span class="gmail_quote">On 5/5/07, <b class="gmail_sendername">Brendan Taylor</b> <<a href="mailto:whateley@gmail.com">whateley@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, May 05, 2007 at 11:22:26AM -0600, David Fuelling wrote:<br>> 9. Desktop client polls the URL *<br>> <a href="http://servercomponent.com/client-complete/">http://servercomponent.com/client-complete/</a><nonce>
<br>> every 15 seconds until that page contains certain information (maybe<br>> hidden html fields? Maybe an atom feed?) to let the desktop client know<br>> that the auth was succesful or not. *Of course, the server component
<br>> (on <a href="http://servercomponent.com">servercomponent.com</a>) knows about the sucess or failure since it is<br>> a normal RP and has done normal OpenID auth in step 5. The desktop client,<br>> in response to a succesful poll can also try to close the browser window,
<br>> or<br>> give the user a friendly status message.<br><br>I like this idea*, it's much more firewall- and user-friendly then the<br>others proposed so far. I see a problem, though:<br><br>If an eavesdropper gets the original nonce URL, he can poll the
<br>client-complete URL more often than the actual client, find out the<br>authorization was successful before it and make his own request.<br><br>Now that I think of it, all the methods that have been proposed have<br>this race condition.
<br><br>* although I still don't like using a redirect in the server's initial<br>response. The information passed in the redirect belongs in a<br>WWW-Authenticate header.<br>--<br><<a href="http://necronomicorp.com/bct">
http://necronomicorp.com/bct</a>><br><br>_______________________________________________<br>general mailing list<br><a href="mailto:general@openid.net">general@openid.net</a><br><a href="http://openid.net/mailman/listinfo/general">
http://openid.net/mailman/listinfo/general</a><br><br><br></blockquote></div><br>