- 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>
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