[OpenID] Using OpenID outside of the browser

Sat May 5 20:22:10 UTC 2007

The reason had to do with "closing the loop" and trust boundaries. 

But I have my hands with two kids at the moment, so the proper answer would
have to wait for a few days.

            -Gabe

  _____  

From: David Fuelling [mailto:sappenin at gmail.com] 
Sent: Saturday, May 05, 2007 10:22 AM
To: Gabe Wachob
Cc: general at openid.net
Subject: Re: [OpenID] Using OpenID outside of the browser

Gabe, 

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. 

 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). 

So, the process would go something like this (mainly only step 1 and 7-10
are different from your blog post):

1.	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:

GET on http://servercomponent.com/client-auth?openid=me.openid.com
<http://servercomponent.com/client-auth?openid=me.openid.com&nonce=> &nonce=
<nonce>
2.	RP server component returns:

302 relocated
Location: http://servercomponent.com/client-login/<nonce> 

In generating this 302 response, the RP associates the nonce with desktop
client's HTTP session, and the openid requested by the desktop client.
3.	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
http://servercomponent.com/client-login/<nonce>

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.
4.	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:

http://servercomponent.com/client-complete/<nonce>
5.	OpenID auth happens as normal (user browser goes off to OP to
authenticate) 
6.	The user browser eventually returns to

http://servercomponent.com/client-complete/<nonce>
7.	User sees a message from the RP that he can now close his browser.
8.	User closes his browser (or perhaps the client app closes it, via
step 9).
9.	Desktop client polls the URL
http://servercomponent.com/client-complete/ <nonce>
 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.  Of course, the server component (on
servercomponent.com) 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.
10.	Client app now has access to the RP server component.

[1] http://blog.wachob.com/2007/03/openid_for_desk.html

On 4/29/07, Gabe Wachob <gabe.wachob at amsoft.net> wrote:

I'm not sure if what I discussed earlier on this list and on my blog matches
your requirements, but you might find it of interest:

http://blog.wachob.com/2007/03/openid_for_desk.html 

        -Gabe

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net
<mailto:general-bounces at openid.net> ] On
> Behalf Of Brendan Taylor
> Sent: Sunday, April 29, 2007 5:16 PM
> To: general at openid.net
> Subject: [OpenID] Using OpenID outside of the browser
>
> I've written a web-based Atom Publishing Protocol client[1] that uses
> OpenID for identifying users. It seems to me that since I have a user's
> OpenID anyways, it makes sense to include it when publishing an entry; 
> the problem is that while the client knows the user controls that URL,
> there is no way (that I know of) for the client to prove that to another
> server.
>
> A more general case: I would like to let people comment on my blog using 
> the Atom Publishing Protocol. I would also like to use and verify their
> OpenIDs for identification. But most APP clients aren't going to be part
> of a browser, and so the login-redirect-set cookie dance seems out of 
> place.
>
> What's the best way to marry OpenID and non-browser clients?
>
> 1: <http://necronomicorp.com/pushpin>

_______________________________________________ 
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070505/47efaa4c/attachment-0002.htm>