Re: Networked Service Discovery and Messaging - first draft published

Harald

I agree that we should have a security (and privacy)  considerations section, thanks for noting this important point.

We should add it to the next draft, as I think Robin has already made the transition request for publication.

Rich - are you able to propose such a section to the list?

Going forward I think our publication checklist should include having a security and privacy considerations section in each document, where appropriate.

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group




On Aug 3, 2012, at 12:38 PM, ext Harald Alvestrand wrote:

> Just because I can't find it in the draft:
> 
> What's the security considerations of this document, and where are they documented?
> In particular, are there any security implications of letting JavaScript applications run mDNS or uPNP queries on the browser's local network, and are there elements of the network topology information that should be considered sensitive?
> 
>                   Harald
> 
> On 08/03/2012 05:33 AM, Rich Tibbett wrote:
>> We've just published a first draft of the 'Networked Service Discovery and Messaging' specification to the W3 Mercurial repository. Firstly, thank you to everyone who has helped us get to this point - AKA, the starting line.
>> 
>> It is the result of collaboration between Opera Software, members of the CableLabs initiative and the W3C Web & TV Interest Group over the past year. At the current time of writing there are currently 3 implementations (and counting) based on early drafts of this proposal: a Webkit prototype implementation, an Opera prototype implementation and a Chrome Extension-based implementation.
>> 
>> The latest draft of this spec is available @
>> 
>> http://w3c-test.org/dap/discovery-api/
>> 
>> This API represents a minimal viable framework for discovering, requesting and creating connections with HTTP-based services running on local devices that are advertised in the user's current local network via one or more common discovery protocols (e.g. SSDP and mDNS/DNS-SD).
>> 
>> Once a user has authorized access to any specific service(s) then they are able to communicate with those services via a service's advertised control url endpoint (exposed at service.url). The spec describes how this URL is whitelisted in a 'reverse-CORS' way on user authorization to temporarily allow cross-origin communication to happen from the current web page to that service via existing web APIs such as XHR or Web Sockets.
>> 
>> A number of use cases have been documented in the specification. The use cases generally under consideration revolve around scenarios such as being able to interact and control a wide-range of devices in the home (TVs, Music Players, Home Automation Systems, etc), share media and other content between home devices and enable web application developers to implement second screen experiences for their users directly in web browsers via standard web technologies.
>> 
>> We would like to shortly make a start on producing a comprehensive conformance test suite to evaluate existing and future implementations against this specification. To this end we would like to issue a CfC to publish a First Public Working Draft of this specification. I believe this is what was agreed to at this groups most recent F2F meeting. The chairs will be issuing a CfC for this specification in the coming weeks.
>> 
>> It is now open season on discussion of this spec on this mailing list. We would really like input from both implementers and end-users alike at this point. I know a number of people had comments they wanted to share here and now would be a great time to do that.
>> 
>> Best regards,
>> 
> 
> 
>

Received on Friday, 3 August 2012 16:56:31 UTC