Requirements for Managment APIs

[relu91]

As disccussed in today's security call with @mmccool. We need to identify a set of requirements for APIs that handles runtime configuration and security initialization (i.e., fill secrets). Prescribing those requirements can help to make assumptions in the description of the Scripting API. For example in the newly added ExposedThingInit algorithm we could refer to the presence of a set of securityDefinitions configured with such API.

I think this addition could help also implementers to know how to handle out-of-band security data and protocol binding configurations.

Related work (kindof): https://github.com/w3c/wot-scripting-api/tree/master/applications/script-manager

Related:
#289 (comment)

[relu91]

In the last call, we decided that it is best to start from use cases and think more about practical problems. In this comment, I'll try to report our needs for APIs that configure security parameters.

In practice, the use case is pretty simple, in our applications the set of the web things is never static. We can't know at the dev time or at deployment time which thing will be consumed by a particular script. The reason is pretty simple: discovery. So script A uses a particular discovery method to find and consume X WebThings. To keep things simple let's assume that at least we know that in our deployment ALL WebThings uses a user and password security scheme. However, each one of them may use different pairs of user&password, some of them it maybe even unknown (it needs to be provided at runtime).

With the current API, we don't have any means to provide user&password at runtime. Notice that we are talking about ConsumedThings so even in light of the recent development we are in the lowest privilege regime (so we can't access system resources). Therefore, I agree that we should allow scripts to arbitrarily manipulate security information passing to the underlying runtime. However, we CAN improve the situation providing API enppoints to request security configuration to the runtime.

I see this pretty similar to what a browser does when you are trying to connect to an HTTP resource protected with user&password. The platform prompts the user a form to fill in the required information. In our context, we can reproduce this behavior and let choose the implementation the preferred method to retrieve the security information it needs, (command line prompt, email, open a web page, etc.).

[zolkis]

One group of functions would be script management, tied to relevant permissions.

typedef ScriptHandle USVString;  // opaqie id, e.g. UUID, hash, ...

interface WoTScriptManager {
  Promise<ScriptHandle> install(USVString script, optional unsigned long bootSequence); 
  Promise<undefined> run(ScriptHandle handle);
  Promise<undefined> stop(ScriptHandle handle); 
  Promise<undefined> uninstall(ScriptHandle handle);  // stop, unmark for boot, delete
};

The attached permissions could be permissions.script.{install, run}.

When bootSequence is provided to install(), the script should be marked to run at startup with specified priority (lower number = higher priority).

We could have a use case for suspend() as well, not really needed for now.

[danielpeintner]

With the current API, we don't have any means to provide user&password at runtime. Notice that we are talking about ConsumedThings so even in light of the recent development we are in the lowest privilege regime (so we can't access system resources).

@relu91 do you use addCredentials() from node-wot to add those credentials at runtime?

Having said that, from the security point of view this is not secure.
We need a well defined and secure way to add credentials... for server and client side...

[egekorkan]

Related issue in node-wot by the way: eclipse-thingweb/node-wot#301

[mmccool]

Thoughts:

• Use of MUDS to control network accesses from devices
• Managing key material using existing standards for secure storage: Vaults, TPMs, etc.
• Putting management API in a separate repo might be a good idea; current "scripting API" can be focused on "isolated" and "controlled" code.