<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Some very general thoughts: Having the server establish temporary
session state based on a unique URL is interesting though I think it
does impose additional burdens on servers. It'd be nice if there were
options to use either a localhost: receiver or a server session. It'd
also be nice if the server session could use a server-generated URL to
allow it to do session load balancing (westcoast.example.com vs.
eastcoast.example.com). <br>
<br>
I'm also noticing that the establishment of a session is using a GET to
create a (temporary) server resource, which can be problematic since
it's modifying server state. Given that this is a desktop client with
no restrictions on HTTP verbs, PUT or POST might be more appropriate.
PUT is especially appealing since the client can simply PUT a new URL
with a unique nonce (and it's idempotent) and get back a 201 Created
code to indicate a new session has been established. Using a 302 to
mean "send this to a web browser, don't really follow this redirect"
might be a bit problematic too -- consider a service that wants to fail
over to a new location; 302 is no longer available for this purpose.
Perhaps a new unique header, or a link in a returned XML document,
might be more appropriate; for example, <link rel="login page"
type="text/html" href=<a class="moz-txt-link-rfc2396E" href="http://...">"http://..."</a>/>. <br>
<br>
If polling is desired, the use of an Atom Entry document might be a
good approach. You could PUT an initial state to a unique URL, getting
a modified version of the state in the 201 Created response, with a
login URL back to perform the login, then do a series of GETs until the
state changes to "authenticated" or something similar. The entry also
provides a fairly standard way to give feedback to the end user through
title, summary, and/or content HTML fields.<br>
<br>
(In the process of moving to a new house, I totally missed this thread
even though I've been thinking along similar lines [1]. Brendan
alerted me to the discussion.)<br>
<br>
-John<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440">http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440</a><br>
<br>
David Fuelling wrote:
<blockquote
cite="mid51dae84d0705051022m1bedf52cw694c759a84fe19f9@mail.gmail.com"
type="cite">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>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</body>
</html>