Define UA/runtime for WoT

[zolkis]

A User Agent in a browser is a runtime that acts on behalf the user and is part of the security model that is based on user approval.

It is difficult to define a user for WoT.

Should we use a specific term for WoT Runtime, or WoT UA or something else?

Temporary formulation:

A WoT runtime or simply Runtime is defined as a software stack that manages the lifecycle of WoT application scripts. In the case of ECMAScript and TypeScript scripts, it consists of an ECMAScript interpreter, script lifecycle management, and an operating system API that provides access to local and remote resources. A WoT Runtime can be modeled as a virtual machine in the sense that it should be completely isolated from other execution environments on memory address space, storage address space (file system), network namespace, etc. A runtime may be for instance a Node.js environment, an embedded runtime based on a small JavaScript engine, or provided by a browser.

[knimura]

As you described, assuming a WoT Runtime is modeled as a VM. It can say that WoT Runtime has three types: WoT Client / WoT Server or WoT Servient on VM. Then each of WoT Runtime can be realized by Node.js. Especially regarding WoT Client, it can be realized by a browser (UA) extension as well. Since it just a choice of the mean of WoT Runtime, I think the term of “WoT UA” does not need to define.

[zolkis]

I agree. Let's use the full term WoT Runtime in the spec until a better term is advised.

[h0ru5]

As mentioned in the call on 06-03-2017 we should clarify also the relation of scripts, runtimes and things

[zolkis]

IMHO we have 2 options for Runtime vs Thing vs Scripts modeling.

1. A Thing is associated with its own runtime and interacts with other Things only via the WoT interfaces. Local physical interfaces are encapsulated by bindings. Bindings/implementations may take advantage of local optimizations, but Thing addressing and interfaces don't change based on locality. A script run on a Thing can access other Things based on this standard interface. Script collation/combination is possible following distributed programming paradigms.

2. More similar model to OCF. We introduce the notion of a WoT Runtime (equivalent to OCF Device) that run scripts that expose/have access to all local Things using a "local" interface that is different from the "generic" one used for accessing remote Things in general. In OCF, a resource has a single URL for addressing, which is composed of a scheme, a device ID (or IP address) and a resource path. So Thing identification would not be opaque string, but a structure that can be serialized to a URL and vice versa, can be obtained from a URL. In the runtime, the resource path is enough to identify the Thing, outside the device id is also needed. Scripts can operate with values independent of network address space, that is, device id + resource path that are mapped e.g. to IP address and port. URL scheme selects the protocol. A script can operate with multiple local Things using a simpler interface and would use remote scripts the same way as 1.

Both models would be capable of serving Thing and script aggregation/combination use cases, but IMHO 1. is more adherent to the mission of WoT, i.e. to be an abstraction layer above IoT that connects Things not only via protocols, but to the Web. So rather than replicating or redefining the existing complex IoT models, we'd need a simple and nevertheless powerful concept.

IMHO we should strive to a representation that makes runtime configurations irrelevant for or orthogonal to Thing interactions. Moreover, we should be able to move/migrate Things around runtimes without strong ties. Therefore IMHO we should try using 1. with opaque URL addressing.

[zolkis]

We also need to figure out how do we plan to manage scripts: provisioning, configuration, running, etc. This should be a separate deliverable than the Scripting API, but they are connected.

I imagine the primary role of a script is to define, expose, represent and encapsulate a Thing with all related HW and SW (that can also contain other scripts).

The Script Management Interface (SMI here) allows updating a Thing defined on a HW platform without re-flashing the device - so it's a kind of package manager, possibly connected to TD repository or even a Things Store.

HW platforms can define Things without SMI support if they want to control the exposed Things' lifecycle. Most small embedded devices will fall here and we hope WoT can be fit to be supported there by manufacturers.

HW platforms that expose a package manager interface, can be updated to support either Wot SMI or "Things as native packages".

These are just preliminary thoughts. Please share your views. @knimura @draggett @h0ru5 @mkovatsc @mmccool @mjkoster

[knimura]

Scripting API deals thing lifecycle as defined in the WG charter. So SMI should be part of it.

[zolkis]

Scripting API deals thing lifecycle as defined in the WG charter. So SMI should be part of it.

Based on the Current Practices, a Thing has WoT interfaces facing the external world, and the Scripting API is an internal API between a script and the model/bindings.

The SMI would be an external facing API for managing scripts, so IMHO clearly different from the Scripting API. I don't know if it's good to include it into the WoT interface, or it'd better be a separate interface at similar level as the WoT interface, but either way it's not there now and we need to add it - if we need it.

[draggett]

Provisioning in the broader sense is a key requirement, and for me includes the ability to update apps running on a Web of things application platform. This is broader than just script files and extends to all of the resources needed by an app.

We also need to consider the resources that make up the application platform itself. These include the drivers for the supported IoT technologies as well as security related resources.

Secondary storage will in many cases be on Flash memory, so I would expect this to involve updating Flash memory.

[zolkis]

Yes, there is provisioning that is connected to the underlying platform, for instance OCF provisioning with the resources needed (security keys, certificates, doxm resources etc). AFAIK OCF allows application specific provisioning data as well (from their point of view WoT is an application), but this might change. This part belongs to the WoT bindings since it's platform dependent. This kind of provisioning is out of scope for scripting.

What I am asking is that do we need or want a mechanism to deploy WoT scripts to WoT runtimes without re-flashing (where the underlying platform supports that). This would be similar to how web pages can fetch scripts. That interface is what I referred to as SMI (script management interface).

Since the main thing SMI would do is to allow fetching remote Things, @knimura is right that we might say we solve this using the Scripting API, but I would add only if the TD can contain scripts as well and we allow execution of those scripts -- to which security people would likely say no-no. So on a second thought, SMI may not be a good idea, it's too generic, therefore potentially dangerous.

One way out would be to allow TD's to contain recipe/rule/scene/scenario definitions that are composed of operations predefined and standardized in the WG and can be security-hardened. This way when we retrieve a remote Thing (as ConsumeThing), its TD would contain these scenario definitions that the importing script could use in order to combine Things functionality. Now for that we could have support in the Scripting API - if we vote for this model.

[knimura]

I'd like to clarify what kind of script would be dealed in the SMI and what the recipe/rule/scene/scenario definitions look like . Could you explain based on the voting scenario in the rationale.md (1-3-2. Example: Voting) if possible?

[zolkis]

In rationale.md you mention that a script has to get to the application layer of a Thing. I am talking about all these scripts and how exactly do they get to the Thing.

If the answer is by flashing only, then IMHO WoT is just like one of the IoT islands it tries to abstract (which also try to abstract other islands).

What I'd like to get is WoT provisioning based on native application concept, and then WoT applications deployed and run through a WoT interface.

TD is one step towards that direction but IMHO not enough. Currently with OCF you can develop a script by reading documentation/RAML then deploy it. This can happen even via a browser, even to microcontrollers. Even though the data model is static, the scripts can be upgraded easily without re-flashing, which is IMHO more generic than just adapting to data model changes with static scripts. (Discoverable and downloadable TD are more generic then these doc/RAML and allow more generic code that makes data model updates transparent. However, scripts would be still static wrt business logic.)

We could also say there are different levels of WoT configurability, on some devices WoT support will be flashed, on other you could create dynamic Things based on other Things. This could be dictated by the support level of the native platform.

In any case, if we support dynamic WoT at all, we will need to define the script (or recipe) management/lifecycle - which we currently lack.

[knimura]

It would be part of Scripting API if the script is related to an API and the hook. I agree this is not there yet but it would be optional function since flashing also can be the solution. In the voting example, three scripts in WoT Servient would be part of the new life cycle because the scripts deal hooks. However voting script for WoT Client would be out of scope because it just tries to use the API.

[h0ru5]

there are much topics in a single issue, but I'll try to comment:

• SMI: i like the idea to have a standardized interface to deploy/start/stop/restart/delete a script - so far we have modeled that as a "thing"-interface itself (i.e. actions and properties) in our implementations - a thing representing the runtime.
• runtime / thing / script: in my current thoughts, the runtime hosts one ore several things and runs scripts. these scripts interact with the runtime and can expose things, modify local and remote things and react on events in local things.

[h0ru5]

maybe to add: the SMI would indeed need two interfaces, one which is the interface I use in my script to react to lifecycle events ("you are being stopped") and one which is exposed so that others can interact with it. I'd opt to name it "WoT Runtime Interface"

[zolkis]

a thing representing the runtime

That can certainly be an option, but it's an implementation detail. We need to standardize that Thing then (possibly among others). To check this, we need to collect the use cases of such a RTI Thing and check if it's indeed the best to represent it by a Thing, or should it better be a simple built-in API object.

the runtime hosts one ore several things and runs scripts. these scripts interact with the runtime and can expose things, modify local and remote things and react on events in local things.

This is important, thanks. Then we'll need to update the API. Would these Things each have their mainloop (standalone processes) and network interfaces, or could Things in a runtime share these? If the latter, then we are close to the OCF model of having device (=runtime), resources (things) and eventually platform (= hardware board). We need to clarify this model for WoT.

[knimura]

Having SMI in a runtime as "WoT Runtime Interface" would be good. It is still unclear which actor can deploy/start/stop/restart/delete a script.

[knimura]

"things" and "scripts" might need some sort of separation in a runtime from the security point of view.

[zolkis]

The question we need to answer: what is the entity that can be dynamically deployed: script or can it be even a Thing? Under what constraints? Do we define sandboxing, or limited operation context for scripts, or deployable Things?

[h0ru5]

Conclusions from Meeting on 27-03-2017:

• Things are runtime resources
• Scripts can interact with and create things at runtime
• We need a kind of interface to the runtime, exposing it as scripting API enables also providing a well-known thing
• scripts can only interact via things
• question to clarify: do we have a single-process runtime (compare browser tab)
• there are low-level operations that are seen as part of the runtime and out of scope for the application scripting (e.g. updating resource directory or refreshing OAuth tokens)

Lets gather some design examples for the scripting API of the runtime interface to deploy/start/stop/restart/delete a script

[zolkis]

Another input: https://www.w3.org/2017/03/wot-information-model.pdf. Some relevant assertions:

1. Every thing is an instance of the class “Thing".
2. Things may identify the IoT platform they are hosted by, along with ancillary metadata.

Continuing based on the above:

3. An IoT platform can host one or more WoT Runtimes (WR).
4. A WoT Runtime can host one or more Things
5. WR provides the Wot Scripting API object and the execution context for Scripts.
6. A Script can interact with Things (provided in the WR or remote Things) and can use the WoT API object exposed by the WR.
7. Thing actions may be defined as scripts.
8. A WR runs one main script.
9. Things and Scripts can be deployed to a WoT Runtime statically (e.g. by flashing a device) or dynamically. The WoT API object exposes an API for dynamic deployment (that fails if insufficient privileges).
10. ExposedThing and DynamicThing could be expressed as a Thing with a given policy.
11. A WR is identified by a URL (following the same conventions as Thing identification) and MAY be implemented as a special Thing that supports the following events: onscriptchanged, onstarted, onstopped, [and optionally, onthingadded, onthingdeleted, onthingchanged] etc. (supposed to be standardized).

The WR provides the API object that implements functionality like:

• Script management
  • deploy "main" script to a remote WR
  • start and stop main script in remote/local WR
• Thing API (CRUDN)
  • create (register) local/remote Thing based on existing TD supported by the WR
  • retrieve current state of local/remote Thing (streams should be also supported)
  • update local/remote Thing state (properties)
  • delete local/remote Thing
  • (server only) notify remote listeners about local, observed change.
• Thing Description API
  • update local/remote Thing Description: add/remove properties, actions, events, semantic data, policies, etc. Note: this is limited and best-effort, since changing a TD might pull changes in bindings as well, which usually means re-flashing the device. In fact, the following could be done without re-flashing:
  • add/remove/update an action (script)
  • add a property whose value can be calculated based on existing functionality or by action scripts
  • remove a property
  • add/remove an event (might fail, depending on the case).

This is far from complete, just thinking about how to handle scripts and execution contexts in a WR. To me it seems that having a main script per WR and the possibility to provide a script for an action would be flexible enough, while keeping assumptions relatively simple.

@draggett : your feedback would be much appreciated.

[h0ru5]

I am not very sure I got the reasoning behind the "main" script.

Asking:

• are there several scripts besides the main in a single WR?
• what is the difference if a main script just adds handlers?
• can a WR be started "blank" and then be populated by one or several scripts?
• What happens if the "main" script is finished?

In comparison: a Webpage does not have a main. There are several scripts but the general lifetime an main loop is not one of the scripts.

[zolkis]

Yes, we could run multiple scripts in a WR that define Things and handlers, but we can run only one mainloop in a WR. We need a mainloop integration mechanism and one "main" script. One mainloop integration mechanism is to define actions and events on a Thing. It is transparent to clients whether Things are run in separate or shared WR.

However, we may also have a use case for replacing a running main script (with all Things within) with a complete new "main" script in a given WR.

We might also decide this is not possible, since what I called "main script" is basically the WR implementation and all a client can access is Things.

These are just ideas: we still need to decide on the runtime structure.

[zolkis]

One question is whether do we want to go into the full glory of browsing context equivalent in WoT runtimes, and what would it contain. Usually a browsing context consists of a Document, a session [history], a Window, a renderer and an event loop.

In WoT case (mostly headless), a WR would mean basically a mainloop (event loop) and the analogous entity to a Document. Basically I called the analogous of that Document (DOM) the "main script".

[zolkis]

See also https://html.spec.whatwg.org/multipage/browsers.html#script-settings-for-browsing-contexts https://tc39.github.io/ecma262/#sec-execution-contexts

[h0ru5]

My point/assumption would be: have one execution context and event loop per WR, which can host several things and run multiple scripts sharing the same object model (the things) and event loop. scripts basically modify the object model (Things Object Model - TOM?) and attach event listeners

[zolkis]

With the remark that a given HW may run multiple (isolated) WR's that may access the same sensors/actuators.

[h0ru5]

With the remark that a given HW may run multiple (isolated) WR's that may access the same sensors/actuators.

agreed. however, would you consider the resource sharing principles be part of standardization? IMO we should explicitly state there can be several runtimes on the same host but not pin down how this is realized.

[knimura]

Simple (a main loop) model would be used in a device and complex (isolated) model most likely used in cloud/edge. Also the rationale for the runtime design may come from security consideration.

I agree, clarification of the scope of the standardization would be necessary.

[zolkis]

would you consider the resource sharing principles be part of standardization? IMO we should explicitly state there can be several runtimes on the same host but not pin down how this is realized.

I agree it would be out of scope for standardization (and compliance/test suite). However, the security document will likely contain recommendations on this (from threat management point of view).

[zolkis]

Simple (a main loop) model would be used in a device and complex (isolated) model most likely used in cloud/edge.

I agree most devices will have one WR, and manufacturer or solution vendor owned/certified.

However, there will be WoT bridges (servients) that may need to be able to run multiple WR's.

I'd consider cloud security out of scope (if falls within the security ownership of the manufacturer/solution maker), but IMHO WoT should make a threat model/checklists/recommendations on WR security (including integrity and data protection issues). This is under work now.

[zolkis]

Filed an issue about this on WoT WG Architecture & Security https://github.com/w3c/wotwg/issues/3

[zolkis]

After discussion in various issues referenced above, it is now clear what is the scope of the WoT Runtime. Closing for now, reopen if needed.