Re: [widgets] OAuth and openID

  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