Gabe, <br><br>With regard to your "OpenId for Desktops" [1] proposal, why not eliminate the localhost:9876 mechansim entirely. Instead, the desktop client could (once it has initiated an authentication process) simply poll a URL on the RP to see if the authentication succeeded.
<br><br> That way, you don't have to worry about localhost clients (and concerns about port conflicts, NAT, etc), and we don't have to have a "click this" button, nor do we need the user to do anything special (like copy/paste this nonce into a new window).
<br><br>So, the process would go something like this (mainly only step 1 and 7-10 are different from your blog post):<br><ol><li>To initiate login, desktop client first does a
request to a server component (an RP) to associate the desktop client's http
session to the RP server component with an openid, and a nonce:<br><br>GET on <strong><a href="http://servercomponent.com/client-auth?openid=me.openid.com&nonce=">http://servercomponent.com/client-auth?openid=me.openid.com&nonce=
</a><nonce><br><br></strong></li><li>RP server component returns:<br><br><strong>302 relocated<br>Location: <a href="http://servercomponent.com/client-login/">http://servercomponent.com/client-login/</a><nonce>
</strong><br><br>In
generating this 302 response, the RP associates the nonce with
desktop client's HTTP session, and the openid requested by the desktop
client.</li><li>The desktop client gets the 302 and does NOT follow the redirect
itself. Instead, it makes the local web browser (e.g. python's
webbrowser.open) go to<br><strong><a href="http://servercomponent.com/client-login/">http://servercomponent.com/client-login/</a><nonce></strong><br><br><em>Note:
the desktop client and its HTTP session are now associated (by the
RP server component) with the user's web browser session via the nonce.<br><br></em></li><li>The RP server component looks up openid by nonce and does openid
discovery, returns a redirect to OP to the browser, with return_to set
to:<br><br><strong><a href="http://servercomponent.com/client-complete/">http://servercomponent.com/client-complete/</a><nonce><br><br></strong></li><li>OpenID auth happens as normal (user browser goes off to OP to authenticate)
<br></li><li>The user browser eventually returns to<br><br><strong><a href="http://servercomponent.com/client-complete/">http://servercomponent.com/client-complete/</a><nonce></strong></li><li><strong><span style="font-weight: normal;">
User sees a message from the RP that he can now close his browser<span style="font-weight: bold;"><span style="font-weight: bold;">.</span></span></span></strong></li><li><span style="font-weight: normal;"><span style="font-weight: bold;">
User closes his browser (or perhaps the client app closes it, via step 9).<br></span></span></li><li>Desktop client polls the URL <strong><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 hidden html fields? Maybe an atom feed?) to let the desktop client know that the auth was succesful or not. </strong>Of course, the
server component (on <a href="http://servercomponent.com">servercomponent.com</a>) knows about the sucess or
failure since it is a normal RP and has done normal OpenID
auth in step 5. The desktop client, in response to a succesful poll can
also try to close the browser window, or give the user a friendly status
message.</li><li>Client app now has access to the RP server component.<br></li></ol><br>[1] <a href="http://blog.wachob.com/2007/03/openid_for_desk.html">http://blog.wachob.com/2007/03/openid_for_desk.html</a><br><br><div>
<span class="gmail_quote">On 4/29/07, <b class="gmail_sendername">Gabe Wachob</b> <<a href="mailto:gabe.wachob@amsoft.net">gabe.wachob@amsoft.net</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;">
I'm not sure if what I discussed earlier on this list and on my blog matches<br>your requirements, but you might find it of interest:<br><br><a href="http://blog.wachob.com/2007/03/openid_for_desk.html">http://blog.wachob.com/2007/03/openid_for_desk.html
</a><br><br> -Gabe<br><br>> -----Original Message-----<br>> From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net
</a>] On<br>> Behalf Of Brendan Taylor<br>> Sent: Sunday, April 29, 2007 5:16 PM<br>> To: <a href="mailto:general@openid.net">general@openid.net</a><br>> Subject: [OpenID] Using OpenID outside of the browser<br>
><br>> I've written a web-based Atom Publishing Protocol client[1] that uses<br>> OpenID for identifying users. It seems to me that since I have a user's<br>> OpenID anyways, it makes sense to include it when publishing an entry;
<br>> the problem is that while the client knows the user controls that URL,<br>> there is no way (that I know of) for the client to prove that to another<br>> server.<br>><br>> A more general case: I would like to let people comment on my blog using
<br>> the Atom Publishing Protocol. I would also like to use and verify their<br>> OpenIDs for identification. But most APP clients aren't going to be part<br>> of a browser, and so the login-redirect-set cookie dance seems out of
<br>> place.<br>><br>> What's the best way to marry OpenID and non-browser clients?<br>><br>> 1: <<a href="http://necronomicorp.com/pushpin">http://necronomicorp.com/pushpin</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></blockquote></div><br>