W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2011

Local-Network Service Messaging API proposal

From: Rich Tibbett <richt@opera.com>
Date: Tue, 12 Jul 2011 19:11:02 +0200
Message-ID: <4E1C8026.4090704@opera.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
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 Tuesday, 12 July 2011 17:11:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:21 GMT