W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [widgets] OAuth and openID

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Tue, 24 Feb 2009 11:56:27 +0000
Cc: Thomas Roessler <tlr@w3.org>, Jon Ferraiolo <jferrai@us.ibm.com>, marcosc@opera.com, Dan Brickley <danbri@danbri.org>, public-webapps@w3.org, public-webapps-request@w3.org
Message-Id: <A4BA33C0-6D81-41F6-829C-A352AFB3CC37@gmail.com>
To: Thomas Landspurg <thomas.landspurg@gmail.com>
Note the issue arises not because of anything wrong with oAuth itself,  
but because of the lack of standardisation for the authentication  
process (which oAuth is agnostic of); this is what currently prevents  
an oAuth helper application (i.e. a trusted app in the phone OS) from  
providing a consistent and appropriate experience for the user without  
any browser applications being needed for the process. (As it stands,  
such an app would need to be a reverse proxy doing a lot of screen  
scraping of variously formatted HTML login forms).

As it stands, there has been some UX work on oAuth for mobile and  
desktop:

http://wiki.oauth.net/Flickit-to-Flickr

http://wiki.oauth.net/iPhoto-to-Flickr

S

On 24 Feb 2009, at 09:53, Thomas Landspurg wrote:

>   But one of the major issue with oauth is the fact that is quite  
> impossible to use it outside the browser model. For mobile  
> application, or application without browser, the model is to use  
> your PC to log in, to get a token, and then to put this token in  
> your device. The OAuth rationale is that the user will trust more  
> the browser provider than the application provider.
>   The actual situation, is that it's then impossible to provide a  
> good user experience on constrained device, and I've seen  
> application embeeding some browser just to solve this OAuth issue.  
> It's even worst for non brower based device. As we are moving to the  
> internet of connected device, I personnaly thing that widget are a  
> good way to manage this iternet of connected device, but we still  
> have an issue with authentification which is not yet fully solved  
> with OAuth.
>
> On Mon, Feb 23, 2009 at 3:31 PM, Scott Wilson <scott.bradley.wilson@gmail.com 
> > wrote:
> I agree that postponing any detailed work may be the most pragmatic  
> answer, however oAuth is actually a very important technology for  
> Widgets.
>
> oAuth enables a user of an application such as a widget to link that  
> application to an external service, without the application storing,  
> or having access to, any user credentials.
>
> For example, using oAuth, a Photo Widget could get access to a  
> user's Flickr account, without the Photo Widget storing the username  
> and credentials of the user, just an authorization token that cannot  
> be reused for any other user or service. To set up the token, the  
> first time the Photo Widget is installed, the user is prompted to go  
> to Flickr, log in there, and agree to grant the widget access to the  
> service.
>
> Currently very many widgets store user's account details in widget  
> preferences as this is the only means of user access they have that  
> doesn't involve the user constantly re-entering account details to  
> get at basic functionality. In some environments this may not be a  
> significant risk, depending on how preferences are stored and  
> accessed; however in many cases the fact that a widget can  
> impersonate the user (logging on as the user, rather than with a  
> token) causes issues for trust and auditing.
>
> Because many widgets are small local applications offered for remote  
> services that use different user accounts, oAuth is a very important  
> and relevant technology. Which is why, for example, it has been a  
> major task in the oAuth and OpenSocial/Gadgets community to  
> integrate the technology.
>
> ((Note also that last I heard oAuth was going to IETF for  
> standardisation))
>
> S
>
>
>
> On 23 Feb 2009, at 11:02, Thomas Roessler wrote:
>
> On 23 Feb 2009, at 05:15, Jon Ferraiolo wrote:
>
> OAuth is a technology that authorizes someone to do something. For  
> example, an OAuth server might authorize you to cast a vote in an  
> election. Regarding authorization, in the most common case of W3C  
> Widgets, you would most likely use something like an OMTP/BONDI  
> policy file or some sort of platform-specific (maybe implicit)  
> policy to control authorization instead of OAuth. My thinking is  
> that you can ignore OAuth for now.
>
> I think you're conflating policy and protocol here -- OAuth is a way  
> to share an authorization token (and really not much more); it  
> doesn't tell you how to write your authorization policies.
>
> If I were on the committee, I would push to finish Widgets 1.0 as  
> quickly as possible, and then put OpenID and OAuth on the list for  
> things to consider for Widgets 1.1.
>
> +1
>
> OAuth seems most relevant to XMLHttpRequest level 2, and much less  
> relevant to the widget specs.
>
>
>
>
>
>
> -- 
> Get the ALL NEW Webwag Mobile - http://webwag.com/mobile
> Thomas Landspurg -  Webwag  CTO and Co-founder
> http://www.webwag.com Tel: +33 6 32 29 42 16




Received on Tuesday, 24 February 2009 11:57:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT