W3C home > Mailing lists > Public > public-httpslocal@w3.org > June 2017

Re: [httpslocal/usecases] Add a draft proposal of requirements. (#5)

From: Tomoyuki Shimizu <notifications@github.com>
Date: Wed, 07 Jun 2017 00:23:19 -0700
To: httpslocal/usecases <usecases@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <httpslocal/usecases/pull/5/review/42208811@github.com>
tomoyukilabs requested changes on this pull request.

@dajiaji I've attached several comments inline. Please check these comments and revise your draft if needed.

> +
+- #T.B.D.
+    - Network environment: a local network and/or a global network
+    - Certificate issuer: public CA / corporate or organizational CA / private CA
+    - Privacy scope: public / per service or device manufacturer / private
+
+# Requirements for HTTPS/WSS in Local Network
+
+This section collects requirements derived from use cases listed above.
+
+## <a name="req-01"></a>REQ-01: Device Discovery
+
+- The UA (the web browser mentioned in the use cases above) shall be able to securely discover the presence of HTTPS/WSS server capable devices (hereinafter just called 'device') that are connected to the local network. 
+- A secure context loaded from the internet to the UA (hereinafter just called 'secure context') should also be able to discover target device capabilities that are actively (e.g., turned on) connected to the local network (e.g., device type, identity of a set of Web APIs, and so on).
+- A secure context shall be able to get access to the locally discovered device based on the user consent.
+- If there are multiple devices in local network, the UA shall be able to provide the user with a way to select one device at a time which she intends to use on the secure context.

Several questions:

- Should we limit network scope of devices to _the same_ local network?
- Should the UA provide a way to limit devices to ones which has capabilities requested by the users?
- Should the UA avoid exposing the device list to web apps?

> +
+- The UA (the web browser mentioned in the use cases above) shall be able to securely discover the presence of HTTPS/WSS server capable devices (hereinafter just called 'device') that are connected to the local network. 
+- A secure context loaded from the internet to the UA (hereinafter just called 'secure context') should also be able to discover target device capabilities that are actively (e.g., turned on) connected to the local network (e.g., device type, identity of a set of Web APIs, and so on).
+- A secure context shall be able to get access to the locally discovered device based on the user consent.
+- If there are multiple devices in local network, the UA shall be able to provide the user with a way to select one device at a time which she intends to use on the secure context.
+- etc. 
+	
+## <a name="req-02"></a>REQ-02: Mutual authentication between device and secure context
+
+- The secure context must have a way to verify whether the device to which it tries getting access is reliable or not.
+- The device should have a way to verify whether the origin of the secure context which tries getting access to the device is reliable or not.
+- etc. 
+
+## <a name="req-03"></a>REQ-03: Issuing TLS server certificate for device
+
+(Are there any solution to realize the use cases above without issuing a TLS server certificate to the device ?)

Please add "Note:" at the top of the sentence.

> +- A secure context loaded from the internet to the UA (hereinafter just called 'secure context') should also be able to discover target device capabilities that are actively (e.g., turned on) connected to the local network (e.g., device type, identity of a set of Web APIs, and so on).
+- A secure context shall be able to get access to the locally discovered device based on the user consent.
+- If there are multiple devices in local network, the UA shall be able to provide the user with a way to select one device at a time which she intends to use on the secure context.
+- etc. 
+	
+## <a name="req-02"></a>REQ-02: Mutual authentication between device and secure context
+
+- The secure context must have a way to verify whether the device to which it tries getting access is reliable or not.
+- The device should have a way to verify whether the origin of the secure context which tries getting access to the device is reliable or not.
+- etc. 
+
+## <a name="req-03"></a>REQ-03: Issuing TLS server certificate for device
+
+(Are there any solution to realize the use cases above without issuing a TLS server certificate to the device ?)
+
+- The device must have a way to get a server certificate which the UA can trust after connecting to the local network because an IP address and a domain name of a device in local network is changeable.

s/changeable/subject to change/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpslocal/usecases/pull/5#pullrequestreview-42208811
Received on Wednesday, 7 June 2017 07:24:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 June 2017 07:24:01 UTC