- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 24 May 2021 18:10:30 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/04/26-wot-script-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Scripting API
26 April 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#19_April_2021
[3] https://www.w3.org/2021/04/26-wot-script-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Elena_Reshetova,
Kaz_Ashimura, Michael_McCool, Oliver_Pfaff,
Philipp_Blum, Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel
Scribe
zkis
Contents
1. [4]security discussions
1. [5]Issue 299
Meeting minutes
security discussions
<dape> [6]https://github.com/w3c/wot-scripting-api/issues/315
[6] https://github.com/w3c/wot-scripting-api/issues/315
Daniel: this is tracking the meeting and we discuss individual
issues
Issue 299
<dape> [7]Issue 299 - Chose a particular security schema for an
ExposedThing
[7] https://github.com/w3c/wot-scripting-api/issues/299
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> [8]Editor's draft - 8.32 ExposedThing Examples
[8] https://w3c.github.io/wot-scripting-api/#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> [9]Issue 298 - Requirements for Managment APIs
[9] https://github.com/w3c/wot-scripting-api/issues/298
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
[10]Thing Description Editor's draft - 5.3.3 Security
Vocabulary Definitions
[10] https://w3c.github.io/wot-thing-description/#sec-security-vocabulary-definition
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> [11]https://github.com/w3c/wot-scripting-api/issues/299
[11] 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
Minutes manually created (not a transcript), formatted by
[12]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[12] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 24 May 2021 09:10:36 UTC