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

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

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 15 Jul 2011 14:55:16 +0900
Message-ID: <4E1FD644.8010506@w3.org>
To: TV and WEB <public-web-and-tv@w3.org>
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



[ Rich Tibbett from Opera <richt@opera.com> ]
> 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.
> 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.
> 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
Received on Friday, 15 July 2011 05:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:06 UTC