Clarify requirements

[tomoyukilabs]

As a next step, I would like to start analyzing requirements. While the following items could be examples, I would like to ask you to add or modify them. Since these would be dependent on use cases, these items should be clarified per each use case.

• 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
• ...etc.

@dajiaji Could you add an initial proposal, base on use cases indicated by you?

[dajiaji]

@dajiaji Could you add an initial proposal, base on use cases indicated by you?

Okay. I'll try to make a draft proposal until this weekend. Please wait for a while.

[tomoyukilabs]

Just ping @dajiaji

[dajiaji]

Just ping @dajiaji

... pong @tomoyukilabs time= 2 months

Very sorry for the late response. It's June already...
It's about time to resume the discussion.

As a starting point, I'd like to categorize requirements derived from use cases roughly as follows:

• Device Discovery
• (Mutual?) authentication between device and secure context
• Issuing TLS server certificate for device (Device authentication for UA)
• Cross-origin access from secure context to device
• Managing (reissuing and revoking) TLS server certificate for device

What do you think about it ? If you can agree with the outline, I'll upload a draft proposal for requirements (it'll include just a table of contents).

While the following items could be examples, I would like to ask you to add or modify them.

Thank you for providing the items. But it is a little bit difficult for me to extract requirements by categorizing the use cases based on the items.

• Network environment: a local network and/or a global network

I think all of the use cases basically have the same network environment (the secure context is loaded from the internet and the target device and the UA are connected to the local network).
It is true that local network of UC-04 is different from that of other use cases and is virtual loop-back network in the device but I think the difference doesn't have a significant impact for analyzing requirements.

• Certificate issuer: public CA / corporate or organizational CA / private CA

I think that it is too early to discuss the type of CA that depends on a solution for HTTPS/WSS in local network.

• Privacy scope: public / per service or device manufacturer / private

Sorry. I can't understand this item. Does the 'privacy' mean the disclosure scope of domain names ? If it is true, I think that it depends on a solution as is the case with the CA above.

[tomoyukilabs]

Many thanks, @dajiaji! Please submit your proposal draft as a PR, and then I'll review and approve it.

I think all of the use cases basically have the same network environment

Okay. Initially, we will only assume mixed environment of secure context and local network for now. We can add another environment at any time, of course.

I think that it is too early to discuss the type of CA that depends on a solution for HTTPS/WSS in local network.

Oops. I didn't take care about it so much. It was just an idea.

• Privacy scope: public / per service or device manufacturer / private

What I have meant by this sentence is just to clarify who would trust devices or users, for example:

• public scope: anyone can access the device
• service or device manufacturer's scope: only web apps in the manufacturer's origin or users authorized by the manufacturer can access it
• private scope: only an owner/administrator of the device can access it (I haven't consider mechanism of "origin" and/or authentication so well, though)

[dajiaji]

Thanks for your quick reply.

Please submit your proposal draft as a PR, and then I'll review and approve it.

I've submitted a draft as a PR. I'd appreciate it if you check and review it.

What I have meant by this sentence is just to clarify who would trust devices or users, for example:

Okay. I finally understood what you meant. Such privacy analysis is important to extract requirements from the use cases. I added a Use Case Analysis section to the draft so I'd appreciate it if you modify it.

[igarashi50]

I have some comments on the requirements on Device Discovery.

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.

The "securely discover" should be clarified. I think of it as follows.
(1) Authentication: UA should be able to discover only devices which are trusted by someone.
(2) Confidentiality: The data in discovery message should be only visible between the UA and the Device.
(3) Integrity: I think that the data in discovery message should not be modified by others.

I do not have any issues on (2) and (3), but (1). Is it done by public authorities, private authority, or a user? Does UA should be authenticated as well as devices?

• 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).

It is unclear to me if UA needs to know target device capabilities. If such information is just presented to a user, any arbitrary description about device may be sufficient.

• A secure context shall be able to get access to the locally discovered device based on the user consent.

I agree on this.

• 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.

I suggest to remove "if there are multiple devices in local network" or change to "when ...".

• The list of devices in local network must not be exposed directly to web applications. The UA must provide web applicatons with only information or interface related to the device selected by a user.

I suggest to rephrase as follows.
UA shall not expose any discovery information on devices to a web application without a user consent..

• etc.

[igarashi50]

I have a comment on REQ-2 authentication.

Assuming UA supports Mixed Content and CORS(w/ credientials), The following two requirements of REQ-02 can be supported if UA can authenticate device as secure content. I suggest the change as follows.

(Original)
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.
  (Change)
  REQ-02: Device Authentication
• The UA shall be able to authenticate the device as a secure content in order to support Mixed Content and CORS (/w credentials). .That is, the device shall be able to communicate https or wss as required by Secure Contents.

The outstanding open issue is what such local networked device can support https or wss. The derived requirement may be as follows, but it should be discussed in REQ-3.

• The UA shall establish https or ws connection with the device with self-certificate if a user grant it and UA shall authorize it as a secure contexts.

[tomoyukilabs]

@igarashi50 My comments are inline below.

The "securely discover" should be clarified. I think of it as follows.

I agree with this comment, but

(1) Authentication: UA should be able to discover only devices which are trusted by someone.
(2) Confidentiality: The data in discovery message should be only visible between the UA and the Device.
(3) Integrity: I think that the data in discovery message should not be modified by others.

I suppose that these properties could be applied to connection establishment rather than the device discovery phase, since neither mDNS nor SSDP provides them, for example. What we should explore here is how to mitigate privacy leakage and possibilities of device scanning as much as possible, right?

• 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).
  It is unclear to me if UA needs to know target device capabilities.

I agree with this. IMO, device capability discovery itself seems out of scope.

[tomoyukilabs]

@igarashi50 several comments below:

REQ-02: Device Authentication

I agree with this change. We can drop "secure context" here.

The UA shall be able to authenticate the device as a secure content in order to support Mixed Content and CORS (/w credentials). .That is, the device shall be able to communicate https or wss as required by Secure Contents.

it is quite obvious that the UA should be compliant with the specs of Secure Contexts, Mixed Content, and CORS. I suppose that to explore how to connect the UA to the device under this restriction, we are going to discuss its solution in REC-03.

What we should talk about in REQ-02 looks like how the UA could specify the target device correctly and prevent other devices from eavesdropping and impersonating the device. This requirement could be similar to privacy and security requirements of Open Screen Protocol.

Note that we should rather say, "restrict mixed content". (Please refer to Mixed Content spec)