W3C home > Mailing lists > Public > public-web-and-tv@w3.org > July 2011

Re: [all] [HNTF] Opera's device discovery proposal?

From: Matt Hammond <matt.hammond@rd.bbc.co.uk>
Date: Fri, 15 Jul 2011 08:11:39 +0100
To: "TV and WEB" <public-web-and-tv@w3.org>, "Kazuyuki Ashimura" <ashimura@w3.org>
Message-ID: <op.vynflp0lmko9fo@r44116>
Many thanks for pointing this out Kazuyuki, it looks very interesting.

regards


Matt

On Fri, 15 Jul 2011 06:55:16 +0100, Kazuyuki Ashimura <ashimura@w3.org>  
wrote:

> Hi group, esp. the HNTF,
>
> I've found an interesting proposal by Rich Tibbett from Opera on local
> device discovery that was sent to the Device APIs public mailing list
> [a and below].
>
> Here he points out several issues with the existing approaches, e.g.,
> CORS [b, c], and proposes a new idea named "Local Network Service
> Messaging" [d].  Also he mentions our Use Case discussion within the
> HNTF in his message below.
>
> So I was wondering if you all were aware of this proposal, and would
> ask you for opinion about this.
>
> Please note that Rich's disclaimer saying:
>> Disclaimer: This API proposal does not represent the consensus of any
>> standards group and should not be referenced as anything other than an
>> unofficial draft which is a work in progress.
>
> [a]  
> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html
> [b] http://www.w3.org/TR/cors/
> [c] http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
> [d] http://people.opera.com/richt/release/specs/discovery/Overview.html
>
> Thanks,
>
> Kazuyuki
>
>
> [ Rich Tibbett from Opera <richt@opera.com> ]
>> PROBLEM:
>>
>> A number of devices connected within a local network today advertise
>> service API endpoints to the network, the primary purpose of which is to
>> allow other devices within the same local network to connect, control
>> and interact with those services through the provided interfaces.
>>
>> It is possible today to build native applications that can both discover
>> and communicate with such local-networked services. There is currently
>> no standard or, indeed, any particularly easy way to discover or
>> interact with local devices and services from a web application without
>> significant technical hackery on the part of the user (see 'current
>> practice' below).
>>
>> We need a way for a user agent, acting as a broker between a user and a
>> web application to discover services via common discovery protocols
>> (i.e. SSDP and DNS-SD) within the local network, allow web applications
>> to request a particular service type (or class of service) that it
>> wishes to interact with and then for a user to authorize that
>> connectivity based on services found in their local network matching the
>> requested service type. The solution should then enable communication to
>> occur between the authorized web application and the local-networked
>> service, bypassing or overriding the same-origin policy rule if
>> necessary to allow for safe and secure cross-domain communication.
>>
>>
>> CURRENT PRACTICE:
>>
>> Assuming the user is able to obtain a local-networked service's host and
>> port information, which in itself is a hard task for both technical and
>> non-technical users alike, the user must then provide that host and port
>> information to the web application by entering such information in e.g.
>> a web form and submitting said form. Having got this far the web
>> application, despite having all the information required to communicate
>> with a local-networked device/service, is then likely to encounter
>> another issue, namely the same-origin policy rule which prevents a web
>> application from communicating with a networked device that does not
>> share the same host and port origin combination as itself.
>>
>> As a solution to this, CORS has been developed to enable cross-origin
>> messaging from web applications. Within the home network, if the target
>> networked device happened to provide the HTTP header
>> [Access-Control-Allow-Origin: *] then there is little problem with the
>> browser now being able to communicate with the provided host and port.
>>
>> However, the majority of local-networked services do not implement CORS
>> and because [Access-Control-Allow-Origin: *] is generally a bad idea to
>> enable within a local network, it is not really the ideal future-facing
>> solution within local networks to ensure access is granted only to web
>> applications that a user has explicitly authorized access to.
>>
>> In the vast majority of use cases (from e.g. [1]) communication from a
>> web application to a local-networked service is blocked or inherently
>> insecure today due to one or more of the issues above being present in
>> modern web browsers.
>>
>> The current practice therefore does not fulfill the requirements of the
>> initial problem and so we began to consider alternative approaches.
>>
>>
>> PROPOSED SOLUTION:
>>
>> To counter the issues identified in the current practice above we
>> developed a low-level API, produced incrementally over the course of the
>> last few months, that allows a web application to request a particular
>> service type (or class of service type) and for the user to then be able
>> to authorize and connect a discovered matching service to the requesting
>> web application. This enables a user-authorized web application to
>> control, interact and synchronize content (and otherwise generally
>> communicate) with home-networked services, negating the operational
>> issues present in browsers today.
>>
>> The proposed solution is available, in its full form, here:
>>
>> http://people.opera.com/richt/release/specs/discovery/Overview.html
>>
>> A note on CORS: this API is intended to work with or without CORS
>> support enabled in local-networked services. That is to say, CORS in
>> combination with e.g. HTTP authentication schemes, assuming such a model
>> is deployed widely in the future, may provide a good user authorization
>> model for this API (perhaps even to the point of negating the need for
>> any specialized Service Discovery user interfaces at all). As it stands,
>> the proposed solution is intended to work with existing services
>> deployed within local networks without shoe-horning all communications
>> in to a future-only CORS model.
>>
>> Opera plan to produce an experimental implementation of this API in the
>> coming weeks and I plan to keep this group updated on its progress.
>>
>> In the mean time, you can provide any feedback on this proposal at
>> public-device-apis@w3.org. I hope we will also see other API proposals
>> submitted to this group in the coming months.
>>
>> Disclaimer: This API proposal does not represent the consensus of any
>> standards group and should not be referenced as anything other than an
>> unofficial draft which is a work in progress.
>>
>> Best regards,
>>
>> Rich Tibbett
>>
>>
>> [1]
>> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions#Use_Cases
>
>


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/
Received on Friday, 15 July 2011 07:12:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:03 UTC