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

Since the goal of the RESTful design is to have web content access the
resource wherever it is, be it a local resource or one on the Web, the
WG should not be standardizing any specific URLs. Instead, the WG
should be standardizing the API that Web content uses to ask the
user-agent for the URL for the kind of resource it wants to use.

Perhaps something like:

<input type="url" class="org.w3c.Contacts">

When the user-agent sees this tag, it asks the user if it should
form-fill a URL for the OS's contact list, or lets the user select
from among all the contact lists the user has, including ones at
various online services.

Upon receiving the URL, the web content uses XHR to fetch contact information.

--Tyler

On Wed, Jan 13, 2010 at 11:57 AM, Doug Turner <w3c@dougt.org> wrote:
> I do not think we should use http://localhost/ as it removes the ability for third parties to easily expose "device services" into the browser.
>
> Doug
>
>
> On Jan 13, 2010, at 11:51 AM, Frederick Hirsch wrote:
>
>> To be clear I understand,  you are saying that the URI resolution would indicate a local access, directly invoking an API without network access in this case. However this would need to be done without inventing new URIs to avoid web arch issues, but an example could be use of localhost?
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>>
>>
>> On Jan 13, 2010, at 2:45 PM, ext Doug Turner wrote:
>>
>>>
>>> I do not think that the remote server would have to make a HTTP connection to some api server on the device by itself.  Instead, similar to the use of device Javascript APIs, the server would send down some javascript that would have a XHR to a URI that could be resolved locally.
>>>
>>> For example,
>>>
>>> navigator.geolocation.getCurrentPosition(successCallback,
>>>                                        errorCallback);
>>>
>>> function successCallback(position) {
>>> }
>>>
>>> function errorCallback(error) {
>>> }
>>>
>>>
>>>
>>> could become (strawman; lots of spec'ing this out needed):
>>>
>>>
>>> var httpRequest = new XMLHttpRequest();
>>> httpRequest.open('GET', 'geolocation://', true);
>>>
>>> httpRequest.onreadystatechange = function(){
>>> if (httpRequest.readyState == 4) {
>>>   // everything is good
>>> } else {
>>>   // still not ready
>>> }
>>> };
>>>
>>>
>>> Doug
>>>
>>>
>>> On Jan 13, 2010, at 11:31 AM, John Kemp wrote:
>>>
>>>> Hi Frederick,
>>>>
>>>> On Jan 13, 2010, at 2:05 PM, Frederick Hirsch wrote:
>>>>
>>>>> Mark, my concern was that these (e.g. OAuth others noted) all seem to imply network connectivity, yet there might be a requirement to have contact book access (to give an example) without network access.
>>>>
>>>> If you imagine that you have a local Web server running, and providing the contacts API, then if a remote site were to access that service (from off-device), it might send an HTTP request to do. This would be a standard Web scenario, and the remote requester would have to know the DNS name or IP address of the device if it wished to make an HTTP request.
>>>>
>>>> However, imagine if that same Web server, running on the device, is accessed from some other piece of software (like a browser ;), running on the same device. It might still be secured by OAuth, CORS, UMP or something else. The method of access, however, will not be over a network as such - it will be a "localhost" connection essentially (either to a local Web server, or a cached copy of a document acquired from somewhere else). I believe that is the case you are thinking of?
>>>>
>>>> The difference in the use of device Javascript APIs is that the requester in these cases is the one who has written some Javascript using the Device API specifications. That requester won't need to know the IP address of the device in order to use that device's services, because the device requested a page that contains the Javascript calls, and makes a response containing the API calls (which are essentially then a request whose results don't have to leave the device).
>>>>
>>>> In all of these cases, though, I am not sure that any extra network connection is needed in order to use OAuth tokens, or any of the other mechanisms suggested to secure the APIs. The requester should be authorized to access the API of course. In the "offline" case, if you were to use OAuth tokens, then the device would ask the user whether the cached page could access her contacts, and give the cached/localhost page an OAuth token to use in accessing that API.
>>>>
>>>> Regards,
>>>>
>>>> - johnk
>>>>
>>>>>
>>>>> regards, Frederick
>>>>>
>>>>> Frederick Hirsch
>>>>> Nokia
>>>>>
>>>>>
>>>>>
>>>>> On Jan 13, 2010, at 1:23 PM, ext Mark S. Miller wrote:
>>>>>
>>>>>> Still catching up. Answering out of order.
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 13, 2010 at 7:26 AM, Frederick Hirsch <Frederick.Hirsch@nokia.com> wrote:
>>>>>> use of OAuth.
>>>>>>
>>>>>>
>>>>>> That was just an example of one approach to the inter-site authorization problem. Others are CORS and UMP. As I said in the initial proposal, I don't think this WG should try to pick a winner in this debate. They should just position device APIs so that they can leverage whatever the winner is, by recasting devices as RESTful GET/POST apis. By so doing, we reduce the security issues to a previously unsolved problem ;).
>>>>>>
>>>>>>
>>>>>>
>>>>>> regards, Frederick
>>>>>>
>>>>>> Frederick Hirsch
>>>>>> Nokia
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 13, 2010, at 9:55 AM, ext Robin Berjon wrote:
>>>>>>
>>>>>> On Jan 13, 2010, at 15:50 , Frederick Hirsch wrote:
>>>>>> 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.
>>>>>>
>>>>>> That's entirely orthogonal. Either the web server is local, or (perhaps more likely) it is emulated by the user agent. You never go to the network, whether connected or not.
>>>>>>
>>>>>> I thought the proposal was to go to the network for authorization, in which case it is not orthogonal.
>>>>>>
>>>>>> I don't read that in the original proposal, can you clarify which part you're thinking of?
>>>>>>
>>>>>> --
>>>>>> Robin Berjon
>>>>>> robineko — hired gun, higher standards
>>>>>> http://robineko.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> --MarkM
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 14 January 2010 00:03:28 UTC