W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: Simple LREST toying

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Fri, 12 Feb 2010 08:14:26 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, ext Robin Berjon <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <86C6D142-A3D2-4C9B-B7F9-49F239478997@nokia.com>
To: ext Anne van Kesteren <annevk@opera.com>
Anne.

So if the  photos (or contacts) are on the device, then access policy  
should be handled by the device, which results in needing the policy  
on the device, for the device APIs.

So to repeat what I think you are saying

1. allow uniform REST access to API, thus making it transparent  
whether it is local or remote (apart from URL being clear)

2. if the data is on the device itself, then policy and access control  
and privacy concerns must be met by the device, (and this WG was  
chartered to provide a standard for that I believe). If on a web  
server the device need not care, since authentication and  
authorization are the responsibility of the service on the site.

Am I understanding this correctly so far?

I believe there is remains a  usability argument re Javascript APIs vs  
calling REST,  however your point that the paradigm is a bigger issue  
probably holds.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 12, 2010, at 3:31 AM, ext Anne van Kesteren wrote:

> On Thu, 11 Feb 2010 19:40:49 +0100, Frederick Hirsch
> <frederick.hirsch@nokia.com> wrote:
>> First I'm trying to understand why standardized Javascript APIs  
>> wouldn't
>> be more usable.  For local device invocation, they could simply be
>> called by code, if implemented on the device. If supported in a REST
>> scenario, a simple wrapper could dispatch to them, much like the code
>> you created dispatches to invoke custom flickr code. This seems to  
>> make
>> local access much easier while not preventing the REST alternative.
>
> The thing is, that if REST becomes the more dominant scenario for this
> over time, which I think is the expectation, we have this redundant  
> API
> lying around.
>
>
>> Second, authorization can get hard without a policy mechanism. Say  
>> you
>> as the owner of pictures want to control access. Imagine you had 3
>> photos that only Max and I could look at, and 2 that only the WG  
>> could
>> view and the rest are world visible. It seems you would need to  
>> define a
>> policy to state that declaratively, then use authentication  
>> information
>> to authorize based on the policy. Does OAuth help in this case - I  
>> think
>> it is more focused on delegation of all activity of a specific user  
>> from
>> one server to another - a different problem.
>
> It seems like this ought to be managed by the photo application. And  
> based
> on the person accessing the data you either get a 401 or a 200.
>
>
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/
Received on Friday, 12 February 2010 13:15:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT