Define TD/API Security requirements for 2018 spring plugfest.

[mmccool]

Define security requirements for next plugfest. See
w3c/wot-scripting-api#82 (comment)
were some security issues have recently been brought up.

[mmccool]

Perhaps there are two issues:

1. Specifying "security" section of an exposed TD. The requirements for the scripting API will be given entirely by the requirements for the TD spec. Right now the TD spec has an "open" format for the security metadata so probably the API should just allow similar arbitrary data in the API.
2. A possibly related issue is now "provisioned security data" (keys, etc.) are provided to a particular instance of a WoT object, eg. for a service.

[mmccool]

RESOLUTION: As discussed in the Scripting API meeting on Dec 18, security data, like protocol bindings, need to be provided when the Thing is provisioned, eg when the Thing runtime is set up. The scripting API only deals with actions taken from "inside" a Thing, and so this setup is out of scope. However, for practical reasons, we do need to have an implementation that allows this information to be specified. Therefore, the node-wot API should be extended to support the definition of security metadata during setup, and this part of the API should be documented, but it should be made clear that this part of the node-wot API is non-normative.

However: this only works for thing-wide security data. Security data specific to a property, action, or event can't be specified during setup time since these are not known then. Likewise, security metadata has to be the same for all Exposed Things created by a given Runtime instance. We should discuss whether or not this is a problem.

[ereshetova]

Some implications and questions:

• I guess this would also imply that updates to the security metadata is also out-of-scope for WoT?

• within same WoT runtime it won't be possible to have scripts/things with different level of trust. They all would be equal and access the same set of security metadata, regardless if they really need it or not.
  For example, if we have one script/thing that exposes some video camera controls & footage and another one controlling lights, they can both get access to both light info and camera footage in case one of them gets compromised. This is generically against the principle of least privilege. One alternative that can be proposed for such cases, I guess is to create different runtimes for different set of related scripts/things, but this would produce overhead.

• if we do still consider servient multi-tenancy (https://rawgit.com/w3c/wot-security/master/index.html#wot-servient-multi-tenant), then what about APIs for thing manager to manage different runtimes & tenants It would either need access to this different sets of security metadata or APIs to classify the newly coming script into correct runtime based on tenant that provisioned it? It would certainly imply different security metadata not just initially provisioned, but also updated in runtime.

[zolkis]

Such an API should be on a different root object than the WoT object. Perhaps WoTProvisioning?

[mmccool]

Over now.