Re: Why aren't most devices virtual web services?

Is there a requirement to allow local access to contacts, for example,  
even when disconnected from the network? How would this work in this  
model, or is disconnected operation not a requirement? It seems a  
mobile device should still operate as much as possible when  
disconnected.

It seems we are also separating the requirements of authorization from  
privacy, though related, yes? It seems that Noah's comment of using  
extensibility point for privacy relates to this "virtual web service"  
idea that also uses an extension point for authorization (though I'd  
argue different extensibility points).

How would this all relate to the current BONDI and Nokia proposals and  
the work that has been done with those? It seems to progress this new  
idea  further we need a more concrete proposal, another more detailed  
submission. Is this something Google is prepared to submit, Mark,  or  
Robin are you offering to do that?

I think exploring a given use case using the current submissions as  
well as this virtual web service approach is warranted, walking  
through the scenarios and issues, especially since we'd like to  
identify issues related to requirements, security, usability, interop  
etc as early as possible.

What do WG members think?

By the way, I assume the phrase "web services" is not meant to infer  
WS* SOAP Web Services in this thread...

regards, Frederick

Frederick Hirsch
Nokia



On Jan 13, 2010, at 9:16 AM, ext Robin Berjon wrote:

> Hi Mark,
>
> On Jan 8, 2010, at 03:47 , Mark S. Miller wrote:
>> For most devices, why not treat each device as a virtual web  
>> service, exposing its API as a RESTful API in terms of GETs and  
>> POSTs. This would reduce the present security problems to a  
>> previously unsolved problem, of how one web site becomes authorized  
>> to use web services provided by another site.
>
> I like the idea and in fact I've previously worked with a system  
> that functioned very much in this way (albeit with the big  
> difference that no specific security was required in that context).  
> My primary concern however is that this could be one of those ideas  
> that, if pursued, could turn out to actually be more complex and  
> more riddled with corner cases than one might at first expect.
>
> In order to investigate whether this would be a good option or not,  
> how about we looked into exposing the Geolocation API in this  
> manner? I think that it has the right sort of problems without being  
> too complex: requests with parameters, notifications, privacy  
> requirements. If we agree that it's a good example, I'll be happy to  
> take a stab at this.
>
> One issue that spring to mind is the fact that XHR (and presumably  
> any newer derivates) supports synchronous access. If user consent is  
> obtained through an infobar (as in Geo) that means freezing until  
> the infobar is accepted or clicked — essentially turning it into a  
> modal infobar. I'd like folks to think about the potential security  
> implications here.
>
> Beyond that, a (secondary) worry is the maturity of paraphernalia  
> such as JSON Schema and JSONpath that we could want to use here. But  
> that's a bridge we can cross any number of ways.
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>

Received on Wednesday, 13 January 2010 14:37:01 UTC