Approaches to Achieving HTTPS in Local Network

Draft Community Group Report,

This version:
https://httpslocal.github.io/proposals/
Issue Tracking:
GitHub
Editor:
Contributors on GitHub

Abstract

This document describes technical approaches for browsers to communicate with HTTPS servers in local network. All of the approaches in this document are not feasible on existing web standards for the browser and/or related communication protocols and systems. Therefore, this document describes not only the explanation of each approach itself but also related requirements for the browser, and required standardization activities on the communication protocols and systems.

Status of this document

This specification was published by the HTTPS in Local Network Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

By tradition, diverse kinds of connected devices have HTTP server functionality to provide their users with web-based UIs. Since such kind of devices in local network cannot easily get valid server certificates, most of the devices have to use non-secure HTTP.

On the other hand, recently, using HTTPS is getting popular rapidly on the internet due to various efforts to make the internet secure, such as [LETS-ENCRYPT]. Following the trend, browsers' security policies have been enhanced gradually to deprecate insecure HTTP. For example, new features on browsers are supposed to be restricted only to [SECURE-CONTEXTS].

As the result, browsers came to show negative security indicators when the devices are accessed by their users. Browsers also prevent web applications in secure contexts from accessing and collaborating with the devices. In addition, the devices cannot use powerful features ([SECURE-CONTEXTS]) on their web-based UIs. The local devices have been marginalized in the current secure web.

In this document, we propose comprehensive technical approaches to address the problem on using HTTPS in local network. All of the approaches in this document are not feasible on existing web standards for the browser and/or related communication protocols and systems. Therefore, this document describes not only the explanation of each approach itself but also related requirements for the browser, and required standardization activities on the communication protocols and systems.

The purpose of this document is to initiate discussions and receive feedbacks from the W3C members especially from the browser vendors and web developers. Authors of this document are aware that the proposed approaches might not be based on the current design and security policies of the browser implementations but certainly hope that the community will update these policies to cater the need for new emerging markets, such as Internet of Things (IoT).

2. Terminology

In this document, we refer to HTTPS as a scheme of communication allowed by the UA which uses TLS as a method for ensuring confidentiality of its content and identification/authentication of the counterpart of the communication. This means, the scope of the term HTTPS in this document is not limited to the https:// scheme but also includes WebSocket over TLS (wss://) and other schemes that operate in a similar way. Whenever there is a need to disambiguate so that the term specifies the https:// scheme only, the document will indicate so.

In addtion, this document uses the following terms as defined here:

A local network is a network defined in §3.2 Target Local Networks

A UA (User Agent) is a browser on a user’s PC, smartphone, tablet and so on, which is connected to a local network.

A device is in the same local network as the UA, capable of HTTPS server.

A web service is a service hosted on the internet and whose frontend is loaded on the UA, which accesses to the device with HTTPS on the local network.

A Web PKI certificate is a TLS server certificate that can chain up to a root CA (Certificate Authority) trusted by the UA (preinstalled on the UA).

A non-Web PKI certificate is a TLS server certificate that cannot chain up to a root CA, or a self-signed certificate.

A public CA is a CA responsible for issuing the Web PKI certificates.

A private CA is a CA responsible for issuing the non-Web PKI certificates.

3. Scope

The approaches proposed in §5 Technical Approaches are based on the use cases and the requirements defined in [HTTPSLOCAL-USECASES].

3.1. Target Devices

To focus on the problem on using HTTPS in local network, approaches for publicly accessbile devices are out of scope. Actually, it is easy for such kind of devices to get Web PKI certificates so there are few technical challenges on browser implementations and related standardization activities. Therefore, this document does not contain the approaches for the publicly accessible devices as §5 Technical Approaches but as §4 Existing Solutions.

3.2. Target Local Networks

Based on [HTTPSLOCAL-USECASES], we regard following types of network as local network:

In aspect of IP address spaces, local networks in this document can be defined as the networks that use following address spaces or prefixes:

3.3. Target Access Patterns

In general, we can categorize the use cases listed in [HTTPSLOCAL-USECASES] into two device access patterns principle for local HTTPS. They are as follows:

All approaches proposed in this document are based on either one or both of the access patterns.

4. Existing Solutions

Before providing the list of the technical approaches, we’d like to walk through existing solutions.

4.1. Web PKI based Solutions

When a device is publicly accessible, the device can get a Web PKI certificate from a public CA and use it on HTTPS communications with UAs. However, in this case, the device's domain name must be globally unique (e.g., device-id.device-vendor.com) because public CA cannot issue certificates for local domains such as .local([RFC6762]) or .home.arpa ([RFC8375]) as described in [CABFORUM-GUIDANCE-DEPRECATED-INTERNAL-NAMES].

Example current industry best practices of this solution are Mozilla’s [WEBTHINGS-GATEWAY] and [PLEX].

While these solutions are deployed and fits well in some use cases, they cannot work in scenarios where domains are for example, device.local or device.home.arpa. Moreover, the access to local devices in the first place is an important issue (we understand that this issue can be mitigated by preconfiguring the gateway router/proxy but these settings are difficult to be made available in scenarios such as home networks). The other issue is resolving the domain name when there is no internet access. Finally, the number of required public CAs is significantly larger than other use cases due to the vast nature of IoT devices.

4.2. Non-Web PKI based Solutions

Installing non-Web PKI certificates (e.g., self-signed certificates) into a UA as a trusted one manually is a widely used solution. Manually installing non-Web PKI certificates (e.g., self-signed certificates) onto a UA as a trusted certificate is a widely used solution. However, manual operation can make it prone to user error.

5. Technical Approaches

In this section, we describe technical approaches for using HTTPS in local network except for using normal Web PKI certificates, and complicated (and maybe dangerous) manual operations referred in §4 Existing Solutions.

Each approach defined in the following sections is categorized based on the first class requirement, [REQ-1]: Guarantee of Device Trustworthiness.

5.1. Web PKI based Approaches

5.1.1. APPROACH-1: Using technically Constrained Certificates

This section’s description is written for Web PKI certificates with Server-auth Extended Key Usage.

Public CAs need to verify the DNS name of a certificate at the time of issuance of Web PKI certificates with Server-auth Extended Key Usage, following CA/BForum Baseline Requirement [CAB-BR]. However, a public CA cannot verify a local network’s local IP address. So public CAs cannot generally issue certificates for devices, barring an exception, which is technically constrained certificates.

Technically constrained intermediate CA

The term "technically constrained intermediate CA" in CABForum’s baseline Requirement might be confusing. There is a term "technically constrained" in the [CAB-BR], and "name constraint" is one of requirements for Certificates with "EKU = server-auth" to be "technically constrained" If EE (End Entity) certificates will be technically constrained, issuing public CA do not need to verify the DNS name at the time of issuance, and that public CA can publish certificates for devices.

Name constraints seem to working well in many browsers now [BETTER-TLS]. The mechanism of name constraint is well explained by Netflix [BETTER-TLS], so we briefly explain how it works in the next paragraph.

How technically constrained intermediate CA issues Web PKI certificates

We assume that the device vendor has to have control over ".camera.example.com," for example.

A public CA validates the device vendor’s control over .camera.example.com, and issues a name-constraint intermediate CA cert. That intermediate CA is technically constrained, and only able to issue valid certificates with .camera.example.com . Since the vendor is controlling .camera.example.com and .camera.example.com has been validated, validation of "device1.camera.example.com" can be skipped at that time, and that public CA would able to issue an EE certificate for device1.camera.example.com. After transporting that certificate to a device somehow, that device can use a Web PKI certificate.

Possible use case

Here, we assume the DNS server of ".camera.example.com" has a record of device and its local IP(e.g 192.168.2.100) with some mechanism (1). So, that DNS server can reply with local IP address. The browser can then get the IP address of device (right hand side solid triangle lines).

Then browser can have TLS connection with the device, which has a local ipaddress. The device vendor needs to maintain the security of the ".camera.example.com" network.

5.1.1.1. Dependency on other SDOs
This solution will require work with device venders as follows:

5.2. Non-Web PKI based Approaches

In this section, we describe three technical approaches for communications between a UA and a local server that has private domain names.

NOTE: For the following discussions, we use device.local as an example of a domain name of a device. Of course, other local domain names (e.g., device.home.arpa) are applicable name which can be resolved but the name resolution methods should not be restricted only to mDNS ([RFC6762]).

5.2.1. APPROACH-2: Using Shared Secret

This approach is based on the user grant and the use of shared password in which PAKE (e.g., [SPAKE2], dragonfly [RFC7664], J-PAKE [RFC8236]) is used for the establishment of a TLS session between the UA and the device.

NOTE: It is worthwhile to mention that J-PAKE has already been implemented in [MBED-TLS] and the use of [SPAKE2] has been discussed in [W3C-SECOND-SCREEN-WG].

5.2.1.1. Device Access Flow

This approach can be realized on both of the access patterns mentioned in §3.3 Target Access Patterns.

Normal Access Pattern

  1. When a user inputs a device URL (https://device.local) to the address bar of the UA directly, the UA allows the access only if the user grants the access through the UI shown in the figure below.

  2. The UI will be displayed when the device URL has local domain name and the underlying TLS handshake detects the device supports a PAKE-based cipher suite (e.g., [SPAKE2], [RFC8492], [EC-JPAKE], [PAKE-WITH-TLS1.3]).

  3. To make sure that the device.local displayed on the pop-up window is really the same as the domain name of the device which the user intends to grant the access to, user inserts either a PIN or password through the pop-up window.

  4. When the PIN or password is correct, the TLS handshake will be completed successfully and the user can get a web UI of the device without any negative security indicators.

The above flow can be achieved by extending the UI with adding the cipher suites in the browser. This will enable binding the displayed domain name to the physical device.

Cross-Origin Access Pattern

  1. When a web service (e.g., https://device-user.example.com) accesses the device via the UA. The UA allows the access only if the user grants the access through the UI shown in the figure below.

  2. The UI will be displayed when the underlying [FETCH] API is called for the access to the device that has a private domain name and successfully performs a TLS handshake using a PAKE-based cipher suite.

  3. Subsequent flow is the same as the normal access pattern described above.

As with the normal access pattern flow mentioned above, this flow can be achieved by extending the UI with adding the PAKE-based cipher suites in the browser.

This approach might have to have a way to mitigate the PIN or password entry for subsequent TLS sessions, or the user has to input it every time the user uses the device.

To skip user consent, a specific method on how to bind the ununique private domain name (device.local) to the TLS session established by using PAKE needs to be defined to distinguish devices which have the same names as mentioned in [HTTPS-FOR-LOCAL-DOMAINS].

As for this PAKE-based approach, for example, using device ‘private domain name + fingerprint in self-signed certificate’ as the TLS server identifier (which is defined in [EC-JPAKE] can be considered as one of the candidate approaches. The use of self-signed certificate after the first PAKE based TLS session needs to be defined as well.

To skip user consent on the normal access pattern, the browser has to manage the addtional element (e.g., fingerprint in the self-signed certificate) in context with the origin of the device internally.

On the other hand, as for the cross-origin access pattern, [FETCH]] API might have to have a way to return the fingerprint in the self-signed certficate provided by the device as the result of the TLS handshake with the PAKE-based cipher suite, and also have a way to use the fingerprint as demonstrated below.

The following code is an example of [FETCH] API extension to support this approach.
fetch("https://device.local/stuff", {
  // The following extension might be available only to private domain names.
  tlsExtension: {
    // type of the TLS extension.
    type: "pake",
    // base64-encoded SPKI of the certificate or its fingerprint.
    //     this is an optional argument for subsequent TLS sessions
    //     to identify the local server and to omit user approval.
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});
5.2.1.3. Browser Requirements

The requirements for browsers can be summarized as follows:

5.2.1.4. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

5.2.2. APPROACH-3: Using Application Layer Access Token

In §5.2.1 APPROACH-2: Using Shared Secret, there is no trust anchor that can guarantee the authenticity of devices and it is difficult for users to find whether the device is a legitimate one. From the standpoint of web services, it is often argued whether a server authentication should be delegated to a user’s judgement.

This approach resolves the problem by introducing an [IETF-ACE-WG] and [IETF-OAUTH-WG] based AS (Authorization Server) as an authority of the device into the local HTTPS system as shown below.

The ACE components have the following relationships:

Under the above relationships, the client (web service) can get an access token to access the device based on user’s approval. At this time, the client can also get the RS information that includes an URI and an RPK(Raw Public Key)([RFC7250]) or self-signed certificate of the device (step (B) as shown in above figure). Since the existing browsers do not permit the access to the device with the access token (step (C) in above figure), browser API and related UI need to be extended to enable the client to access the device only when the client provides the UA with the RS information (a self-signed certificate or RPK) as a trusted one.

5.2.2.1. Cross-Origin Access Pattern

The RS information can be sent to the UA as an extended parameter of [FETCH] API as follows:

The following code is an example of [FETCH] API extension to support this approach.
// When RS Information includes a RPK, 
fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    type: "rpk",
    // a base64-encoded raw public key or its fingerprint.
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

// When RS Informatin includes a self-signed certificate, 
fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    //     'pkix' might be a default value that can be omitted.
    type: "pkix",
    // a base64-encoded SPKI of the certificate or its fingerprint
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

When the [FETCH] API above is called, the UA shows a following pop-up window.

As the result, HTTPS accesses from the web service to the device are achieved by the UA based on the trust relationship between the client and the AS (and the device) and with user’s explicit approval.

In addition, when the trust relationship between AS and the devices is built on attestation keys in TPM (Trusted Platform Module) on the devices, the authenticity of the devices can be enhanced. The use of the attestation keys is applicable to §5.2.3 APPROACH-4: Using Device Authority-Issued Certificate as well.

5.2.2.2. Browser Requirements

The requirements for browsers can be summarized as follows:

5.2.2.3. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

5.2.3. APPROACH-4: Using Device Authority-Issued Certificate

In this approach, the web service trusts a vendor (device authority) issued private certificate and asks the UA to pin the certificate as a trusted one (only in the web service’s secure context) based on user grant. The trust can be built as an extension to §5.2.2 APPROACH-3: Using Application Layer Access Token in which AS has a private CA role and the web service trusts a private CA issued certificate based either on a pre-registered relationship with the CA and AS or by some other means.

This approach can be realized by extending the browser API and related UI in a similar way as shown in §5.2.2 APPROACH-3: Using Application Layer Access Token. Specifically, by extending the [FETCH] API as described below, it enables web services to provide the browsers with private CA certificates or private CA issued certificates as trusted ones.

The following code is an example of [FETCH] API extension to support this approach.
fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    //     'pkix' might be a default value that can be omitted.
    type: "pkix",
    // base64-encoded SPKI of the vendor CA cert or its fingerprint 
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

Similar to earlier approaches, the UA shows a following pop-up window when the [FETCH] API above is called.

For this approach, we argue that the framework on which a device vendor validates domain names of the devices and guarantees the authenticity of them would be useful even if the names are local names. A domain-validated certificate can be issued by using the OOB (Out-of-Band) challenge as defined in the earlier draft of ACME([ACME-DRAFT-8]). This was also discussed in [TPAC-2017-breakout-session].

The challenge, which is the access to ‘https://device.local/.well-known/acme-challenge/{token}’, is executed by the ACME server’s frontend loaded on a browser that can communicate with the device in a local network. Although the challenge through the UA has some advantages (e.g., it can be based on a user grant, there is no need to change the firewall settings), it requires a [FETCH] API extension for §5.2.1 APPROACH-2: Using Shared Secret that enables the access to the device based on self-signed certificates or RPKs.

It is important to note that there are other industry efforts on similar concepts as vendor-issued certificate (hereafter, private CA issued certificate). For example, [IEEE802.1AR] defines IDevID and LDevID that are device identifiers issued by the device manufacturers, and it seems that [PKI-CERTIFICATE-IDENTIFIER-FORMAT-FOR-DEVICES] tries to make the device identifiers be available on the Web PKI. In addition, [IETF-ANIMA-WG] has discussed the way to issue an LDevID autonomously based on an IDevID. Therefore, we propose that the vendor-issued certificate should be regarded as an accepted mechanism that should be leveraged by the W3C community.

5.2.3.1. Browser Requirements

The requirements for browsers can be summarized as follows:

5.2.3.2. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

5.3. Pros and Cons of the Approaches

NOTE: Write a table that shows relations between the requirements (REQ-x) and the approaches (APPROACH-x).

5.3.1. APPROACH-1

5.3.2. APPROACH-2

5.3.3. APPROACH-3

5.3.4. APPROACH-4

6. Conclusion

In this document, we introduced technical approaches to enable local HTTPS communications from browsers to devices that is not publicly accessible. However, these approaches would require browser extensions and other protocol standardization as identified. The motivation came from the industry need of providing HTTPS access to IoT devices, majority of which will not have a global domain name so that the domain name can be verified and a certificate can be issued.

We hope that this document will spur the discussions within the W3C community so that a solution can be developed and standardized.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[ACME-DRAFT-8]
Automatic Certificate Management Environment (ACME). URL: https://tools.ietf.org/html/draft-ietf-acme-acme-8
[BETTER-TLS]
BetterTLS A Name Constraints test suite for HTTPS clients, created by Netflix. URL: https://medium.com/netflix-techblog/bettertls-c9915cd255c0
[CAB-BR]
CA/BForum Baseline Requirement. URL: https://cabforum.org/baseline-requirements-documents/
[CABFORUM-GUIDANCE-DEPRECATED-INTERNAL-NAMES]
Internal Server Names and IP Address Requirements for SSL. June 2012. URL: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
[CORS-AND-RFC1918]
CORS and RFC1918. URL: https://wicg.github.io/cors-rfc1918/
[EC-JPAKE]
R. Cragie; F. Hao. Elliptic Curve J-PAKE Cipher Suites. URL: https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01
[FETCH]
Anne van Kesteren. Fetch Standard. URL: https://fetch.spec.whatwg.org/
[HTTPS-FOR-LOCAL-DOMAINS]
HTTPS for Local Domains. URL: https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit?usp=shari
[HTTPSLOCAL-USECASES]
Use Cases and Requirements on HTTPS-enabled Local Network Servers. September 2019. URL: https://httpslocal.github.io/usecases/
[IEEE802.1AR]
802.1AR: Secure Device Identity. URL: https://1.ieee802.org/security/802-1ar/
[IETF-ACE-WG]
Authentication and Authorization for Constrained Environments (ace). URL: https://datatracker.ietf.org/wg/ace/about/
[IETF-ANIMA-WG]
Autonomic Networking Integrated Model and Approach (anima). URL: https://datatracker.ietf.org/wg/anima/about/
[IETF-OAUTH-WG]
Web Authorization Protocol (oauth). URL: https://datatracker.ietf.org/wg/oauth/about/
[LETS-ENCRYPT]
Let's Encrypt - Free SSL/TLS Certificates. URL: https://letsencrypt.org/
[MBED-TLS]
Mbed TLS. URL: https://www.mbed.com/en/technologies/security/mbed-tls/
[PAKE-WITH-TLS1.3]
R. Barnes; O. Friel. Usage of PAKE with TLS 1.3. URL: https://tools.ietf.org/html/draft-barnes-tls-pake-04
[PKI-CERTIFICATE-IDENTIFIER-FORMAT-FOR-DEVICES]
PKI Certificate Identifier Format for Devices. URL: https://tools.ietf.org/id/draft-friel-pki-for-devices-00.html
[PLEX]
How PLEX is doing HTTPS for all its users. URL: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
[REQ-1]
REQ-1: Guarantee of Device Trustworthiness. September 2019. URL: https://httpslocal.github.io/usecases/#req-1
[RFC1122]
R. Braden, Ed.. Requirements for Internet Hosts - Communication Layers. October 1989. Internet Standard. URL: https://tools.ietf.org/html/rfc1122
[RFC1918]
Y. Rekhter; et al. Address Allocation for Private Internets. February 1996. Best Current Practice. URL: https://tools.ietf.org/html/rfc1918
[RFC3927]
S. Cheshire; B. Aboba; E. Guttman. Dynamic Configuration of IPv4 Link-Local Addresses. May 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3927
[RFC4191]
R. Draves; D. Thaler. Default Router Preferences and More-Specific Routes. November 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4191
[RFC4193]
R. Hinden; B. Haberman. Unique Local IPv6 Unicast Addresses. October 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4193
[RFC6762]
S. Cheshire; M. Krochmal. Multicast DNS. February 2013. Proposed Standard. URL: https://tools.ietf.org/html/rfc6762
[RFC7250]
P. Wouters, Ed.; et al. Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7250
[RFC7664]
D. Harkins, Ed.. Dragonfly Key Exchange. November 2015. Informational. URL: https://tools.ietf.org/html/rfc7664
[RFC8236]
F. Hao, Ed.. J-PAKE: Password-Authenticated Key Exchange by Juggling. September 2017. Informational. URL: https://tools.ietf.org/html/rfc8236
[RFC8375]
P. Pfister; T. Lemon. Special-Use Domain 'home.arpa.'. May 2018. Proposed Standard. URL: https://tools.ietf.org/html/rfc8375
[RFC8492]
D. Harkins, Ed.. Secure Password Ciphersuites for Transport Layer Security (TLS). February 2019. Informational. URL: https://tools.ietf.org/html/rfc8492
[SECURE-CONTEXTS]
Mike West. Secure Contexts. 15 September 2016. CR. URL: https://www.w3.org/TR/secure-contexts/
[SPAKE2]
W. Ladd; B. Kaduk. SPAKE2, a PAKE. URL: https://tools.ietf.org/html/draft-irtf-cfrg-spake2-08
[TPAC-2017-breakout-session]
How can we provide the devices with valid certificates?. URL: https://www.w3.org/wiki/File:TPAC2017_httpslocal-2.pdf
[UC-1]
UC-1: Photo sharing between online services and home NAS devices. September 2019. URL: https://httpslocal.github.io/usecases/#uc-1
[UC-2]
UC-2: Video streaming with cache storage in local network. September 2019. URL: https://httpslocal.github.io/usecases/#uc-2
[UC-3]
UC-3: Web-based UI for home appliances (input/output constrained devices). September 2019. URL: https://httpslocal.github.io/usecases/#uc-3
[UC-4]
UC-4: Embedded system monitoring and controlling for display-capable devices. September 2019. URL: https://httpslocal.github.io/usecases/#uc-4
[UC-5]
UC-5: Data analysis from analytical and measuring instruments in local network. September 2019. URL: https://httpslocal.github.io/usecases/#uc-5
[UC-6]
UC-6: Secure offline communication for home automation. September 2019. URL: https://httpslocal.github.io/usecases/#uc-6
[UC-7]
UC-7: Companion Device for Broadcast Interactive Service. September 2019. URL: https://httpslocal.github.io/usecases/#uc-7
[UC-8]
UC-8: Presenting with Projector at office. September 2019. URL: https://httpslocal.github.io/usecases/#uc-8
[W3C-SECOND-SCREEN-WG]
W3C Second Screen WG. URL: https://www.w3.org/2014/secondscreen/
[WEBTHINGS-GATEWAY]
WebThings Gateway. URL: https://iot.mozilla.org/gateway/