[proposal] Local-Networked Service [Discovery and] Messaging API

Re-sending to Web Apps for wider review. Originally posted to the Device 
APIs mailing list: 
http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html

***

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 Thursday, 14 July 2011 06:55:21 UTC