The HTTPS in Local Network Community Group (CG) explores the manner of secure communication between browsers and server-capable devices in local network such as set-top boxes, network attached storages, etc. We propose that this Community Group clarify requirements for browsers and devices in issuing valid certificates and establishment of HTTPS and WebSocket connections over TLS and incubate relevant specifications of APIs and/or network protocols.
This work has four primary purposes:
Improve security and privacy of communication between browsers and server-capable devices.
Enable web applications in secure contexts to communicate with server-capable devices in local network via XMLHttpRequest, Fetch API, and WebSocket.
Enable service discovery mechanisms to advertise existence of TLS-enabled server-capable devices.
Encourage adoption and implementation of the specification by browser vendors and device manufacturers.
Given wider support and adequate stability, we plan to migrate the proposals
generated in this Community Group to an appropriate standards track, for
example the IETF Standards Track or a W3C Working Group, for further
contributions and formal standardization.
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
HTTPSLocal CG has started to draft a new Community Group Report “Use Cases and Requirements on HTTPS-enabled Local Network Servers”.
We are now collecting and discussing proposals on HTTPS-enabled local servers. In parallel, it would be important to revisit use cases and requirements so that we could produce specifications practically based on both local server proposals, use cases and requirements.
We believe that writing a new CG Report for use cases and requirements is helpful for us to establish a better specifications and the report will be a good milestone for the CG.
If you have any interest on the CG report or the CG’s work, please get involved on the GitHub repository.
To accelerate our discussion, we have started collecting concrete proposals based on use cases and requirements on HTTPS-enabled local network devices. Our main purpose is clarification and exploration at least, so any forms of proposal are welcome. Although a concrete proposal that specifies detailed algorithm and procedure would be highly appreciated, creating an issue for a minor suggestion or just giving comments is welcome as well.
We would like to make this work go forward, so we still need your kind participation and contribution.
At TPAC 2018, we are going to have our first F2F meeting on October 25 Thursday. In the meeting, we are planning to introduce the brief summary of our previous work, use cases and requirements, and have a short discussion on the next action to explore proposals.
As our first step, we would like to collect use cases where browsers communicate with server-capable devices within local network. This discussion is intended to clarify requirements on “local network”, security and privacy.
We have launched the HTTPS in Local Network Community Group. Our goal is to find out the manner of secure communication between browsers and server-capable devices in local network.
Background
Today, many developers and manufacturers of devices working in local network are being faced with security restrictions, as follows:
Mixed Content: When a web application is in Secure Contexts (e.g. cloud services), the web application cannot connect to local network device’s URL such as http:// and ws://.
Secure Contexts: When web apps is in local network device’s origin (not in Secure Contexts), powerful features like getUserMedia, WebBluetooth, etc. become unavailable.
Of course, these specifications are intended to mitigate risk of security and privacy and prevent browsers from feature abuse on the web. While these specifications mandate even server-capable devices to use HTTP and WebSocket communications over TLS to collaborate with web applications in Secure Contexts, server certificates cannot be issued to such a device due to lack of possible validation (e.g. domain validation (DV)).
Discussion in TPAC 2016 Breakout Session
In order to share the motivation mentioned above and explore further understanding, several sponsors proposed a session for discussion in W3C TPAC 2016 breakouts. As a result, approximately 50 participants joined the session, and succeed to acquire a lot of valuable comments.
We have just started exploring the manner of secure browser-to-device communication which mitigates restrictions without exposing browsers and devices to risk of security and privacy. We hope that developers and engineers in various technical areas would participate in our discussion.
The HTTPS in Local Network Community Group (CG) explores the manner of secure communication between browsers and server-capable devices in local network such as set-top boxes, network attached storages, etc. We propose that this Community Group clarify requirements for browsers and devices in issuing valid certificates and establishment of HTTPS and WebSocket connections over TLS and incubate relevant specifications of APIs and/or network protocols.
This work has four primary purposes:
Improve security and privacy of communication between browsers and server-capable devices.
Enable web applications in secure contexts to communicate with server-capable devices in local network via XMLHttpRequest, Fetch API, and WebSocket.
Enable service discovery mechanisms to advertise existence of TLS-enabled server-capable devices.
Encourage adoption and implementation of the specification by browser vendors and device manufacturers.
Given wider support and adequate stability, we plan to migrate the proposals
generated in this Community Group to an appropriate standards track, for
example the IETF Standards Track or a W3C Working Group, for further
contributions and formal standardization.
This is a community initiative. This group was originally proposed on 2017-02-03 by Tomoyuki Shimizu. The following people supported its creation: Tomoyuki Shimizu, Daisuke Ajitomi, Yoshiro Yoneya, Junichi Hashimoto, Tatsuya Igarashi. W3C’s hosting of this group does not imply endorsement of the activities.