Re: [widgets] OAuth and openID

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