Scripting call, June 5 2017

Hello,

A short summary of today's call.
Going backwards (for dependencies reason).

Protocol bindings and runtime security considerations (sandboxing, etc)
have been shortly discussed.

As protocol bindings are implemented, the following need to be addressed:
- keep account of capabilities (sockets, ports, HW APIs etc) that are
strictly needed for the bindings, and keep the others isolated if possible
- when running in a sandbox, aim to implement an IPC variant of the
Scripting API that can be called from the runtime without having access to
the capabilities accessed by the bindings.

Nimura-san presented an updated version of the slides explaining
synchronization vs scripting. Comments:
- Management Thing is indeed exposed as a Thing
- it can be discovered and used from the Client API (ConsumedThing)
- it may be defined by a static (deployed together with the runtime) script
as an implementation means, but more typically it will probably be native
code part of the WoT Runtime implementation, with appropriate sandboxing
(e.g. access to a local script storage).

A new issue was filed, please contribute to the discussion:
https://github.com/w3c/wot-scripting-api/issues/28

Next:
- discussion is continued on runtime implementation, security, protocol
bindings
- common call with Security task force
- let's list ongoing protocol bindings implementations.

Best regards,
Zoltan