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

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

Received on Friday, 15 July 2011 05:54:43 UTC