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

RE: Devices as Virtual Web Services

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Wed, 10 Feb 2010 08:18:56 -0800
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD10AA9BD0@BD01MSXMB015.US.Cingular.Net>
To: "Frederick Hirsch" <Frederick.Hirsch@nokia.com>, "ext Thomas Roessler" <tlr@w3.org>
Cc: "Robin Berjon" <robin@berjon.com>, <public-device-apis@w3.org>
Jumping into this thread, here are my thoughts reading it:

Re the discussion underway to rework some DAP APIs (at least) as
RESTful. Using a network resource abstraction for API's means that:
1) Every interface (including objects, methods, attributes, etc) are
accessed asynchronously
2) The WRE will need special design to shortcut local resources from
needing a hairpinned HTTP connection (performance killer otherwise)

Also re suggesting OAuth for policy validation:
1) It's not clear how OAuth would be used in for a device-local resource
use case. 
2) There is no explicit support in OAuth (current internet draft
http://tools.ietf.org/html/draft-hammer-oauth-10) for automated
authorization (there is support for automated repeat authorizations).
This prevents a trust-domain based approach toward an unobtrusive user
experience in which unprompted access to API's is available to trusted
applications. At the least there would need to be a revision of the
draft to indicate how a policy engine could act on behalf of the user.
In that case (at least when the policy engine is device-local, there is
no need for a "redirection-based user-agent process for end-users to
authorize client access to their resources" (per OAuth draft).

>From a more fundamental perspective, on how this proposal might affect
DAP and W3C overall: In principle I understand the objective of viewing
API's simply as ways to access resources, and abstracting the provider.
That's consistent with the concept of the web as a distributed resource
environment, with little or no presumption on local resources except
perhaps for some caching. That however involves a fundamentally
different set of goals and concerns than the work which motivated DAP's
formation, i.e. as represented in the Javascript API's for web clients
as developed for BONDI etc. Such a refocus would be closer in spirit to
the work underway in the Webapps group on "Web APIs". Even there though
(and in HTML5 itself), there are clearly some API's that are not
"RESTful". The decision thus over which API's should be RESTful is key
(if we aren't signaling a universal shift to a new API concept for web
clients, e.g. something realized in HTML6+), and that I think is
something that takes a much broader and longer view than accommodated in
the DAP charter.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Wednesday, February 10, 2010 5:34 AM
To: ext Thomas Roessler
Cc: Frederick Hirsch; Robin Berjon; public-device-apis@w3.org
Subject: Re: Devices as Virtual Web Services

Can you or someone else please take an action to provide a more  
detailed proposal of how OAuth might apply in this case?

regards, Frederick

Frederick Hirsch
Nokia



On Feb 10, 2010, at 7:51 AM, ext Thomas Roessler wrote:

> On 10 Feb 2010, at 13:48, Robin Berjon wrote:
>
>> On Feb 10, 2010, at 13:25 , Thomas Roessler wrote:
>>> It's also not clear that one couldn't fake a web server within  
>>> the browser (exposing the RESTFUL API to the JavaScript  
>>> environment) without ever implementing an HTTP server in the  
>>> process.
>>
>> Actually that can indeed be done by wrapping the XHR object (or  
>> more cleanly, by specialising it). My concern here is that you  
>> then sort of have to support all manners of HTTP semantics if you  
>> want to do it "right" (for rather pedantic values of right), but  
>> on the other hand you reach 80/20 very quickly.
>
> Well, you wouldn't need to represent HTTP semantics that are masked  
> away by XHR anyway, which probably takes away much of the 20% you  
> don't really want to do.
>
> The most interesting question is probably how to model  
> authorization for access to these resources if (a) they're actually  
> implemented through HTTP, and (b) there are several users at one IP  
> address or host name.
>
> I sense a use case for OAuth.
Received on Wednesday, 10 February 2010 16:19:38 GMT

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