WoT Scripting API

security discussions

<dape> https://github.com/w3c/wot-scripting-api/issues/315

Daniel: this is tracking the meeting and we discuss individual issues

Issue 299

<dape> Issue 299 - Chose a particular security schema for an ExposedThing

Cristiano: could the script know what security schemes are known to the runtime

ExposedThing implementation is not well understood yet and not standardized

Cristiano: we can choose the security scheme but we could not know which ones are supported

Daniel: for context, we have separated ConsumedThing and ExposedThing
… from ConsumedThing the client can choose
… for ExposedThing it is more complex
… but later on we need to define the security schemes
… question is how to choose, how to figure out which ones are supported

Elena: we had this discussion earlier
… we probably need a minimal requirement to fulfill
… like with SDP protocol
… the script internal logic should decide whether what is returned can be used
… the weak schemas will exist no matter which approach we take
… (except no security)
… we could provide the minimal set
… otherwise fail

McCool: say there are 3 levels of config:
… one is picking a predefined security def
… 2nd level is the content of a security object
… below that there is the level where we configure certificates etc
… we need to think about the use cases
… for instance not in the browser, but in Node.js

McCool: about negotiation
… what we really want to know is what security objects are there
… based on which we can define security definitions
… then the script could pick one(s)
… so the script needs to access the security object's content
… that information is not sensitive
… for instance OAuth scheme etc
… another factor is the protocol;
… we should not use basic HTTP, so the script needs to know what the protocols are

Cristiano: good formulation of the problem
… so we need a method to list the available SecurityScheme object

<kaz> Editor's draft - 8.32 ExposedThing Examples

Cristiano: how do we define minimal sets?

Elena: was not a proposal, just an example for an approach

Elena: there is a negotiation between the script and the runtime

Cristiano: that justifies even more that API
… we need a programmatic approach

Daniel: right now node-wot is no-security

Oliver: where is the a list of possible security schema definitions defined?

Oliver: look at OPC profile document
… the vendor can declare capabilities

Elena: don't we have this in WoT?

McCool: we are getting confused by the "Scheme"
… and the object
… or security definition
… so there should be a management API that configures the runtime
… security definitions could be applied on whole TD or only some Forms
… we won't want developers use no-security

McCool: the cleanest way to do it is to have a catalog of the security definitions

currently we don't have any API for this, so we are discussing a new system API as a helper

Daniel: currently doesn't help if the TD template contains definitions
… can the consumer pass down security credentials? NO
… so there should be prior configuration

McCool: the secrets are associated to the security definitions; scripts can only select ones

McCool: we don't have a way to say that a security definition only applies to a certain protocol
… some schemes might not work for some protocols
… first we need to pick the scheme and protocol
… so we need an external management API that can be used to configure these in advance

Cristiano: the implementation of the security schemes is inside the bindings library
… so node-wot knows about them
… but the TD doesn't know about it

McCool: even if we say in the TD which protocol it applies to, the implementation could override

Daniel: is there some suggestion to put a label on security objects that could be used for filtering?

McCool: they are meant to be orthogonal
… some protocols have password schemes
… the impl can say it supports only certain protocols
… don't think we should put than in the TD spec
… but implementations can be more specific

Daniel: trying to rephrase; we could query the available security schemes in the runtime

McCool: right
… query, apply, management

Cristiano: +1
… wondering if we could include the query in the core API, as it's related to ExposedThing

Cristiano: can I profile/fingerprint a user based on this?

McCool: this is an issue in the browser, but here we talk about servers
… it is possible to fingerprint the environment based on listing capabilities
… but to have access to the API, I have to be already provisioned
… so the risk is not substantial

McCool: whether it matter it depends on the use case

Daniel: what if this API is not there?

McCool: let's suppose we just need to pick the security scheme name, even then we need the list, and even a standardized name list
… we could use a context that give access to at least the scheme names

Elena: I'd support this
… in scheme negotiation if we want to make a choice, we need just the descriptive names
… and that minimizes fingerprinting as well

right now we need to put security definitions to an init dictionary
… CA would prefer programmatic API instead
… so we need a new API for that querying, and then also the management API

McCool: listing and choosing the sec defs should be added to the API
… and a management API should set it up

Cristiano: I didn't like the declarative security definitions
… when we call the expose() method, we'll get back an error
… then we need to start again by creating a new template: it's a trial and error method

McCool: the problem is with the secrets
… MMC: each definition needs to be provisioned externally

Cristiano: node-wot starts to implement sandboxing, and we will need these APIs

McCool: maybe out of scope for the current API, but we need to start working on the management API

<kaz> Issue 298 - Requirements for Managment APIs

Cristiano: this would also allow portability of the server applications

Kaz: we need more details about the implementation, service ports etc

McCool: we could include those in the management API

Kaz: also we don't have impl for DID for Scripting, but wanted to raise the possibility to use it as well (for v2 specs)

McCool: we will discuss it more deeply
… a bit too early at the moment

Oliver: we should differentiate between instance specific information and generic information that could apply to multiple instances

Oliver: we need a well understood catalog of security scheme names
… without any instance specific information
… based on these 2 assumptions we could solve it

Cristiano: we have a sort of catalog
… in the Thing Description's information model definition
… so we are not too far

Thing Description Editor's draft - 5.3.3 Security Vocabulary Definitions

Oliver: what is the difference between security scheme vocabulary and name?

McCool: the set of labels are clear

the TD spec is missing on how to generate a TD, we'd need that as well

McCool: we could have multiple levels of scripting
… setup would be done by different roles
… programming by another role

McCool: when generating a TD from a script we have 2 stages, one is configuration and the other is selecting

we need full code examples to figure out what/how to standardize

Cristiano: I can provide that

<dape> https://github.com/w3c/wot-scripting-api/issues/299

McCool: we could comment in the issue

McCool: we need to list/update the management API requirements

McCool: let's figure out a minimal API fulfilling those

Cristiano: yes, we need subsets

adjourned