- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 18 Feb 2020 22:42:56 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/02/10-wot-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-Scripting
10 Feb 2020
Attendees
Present
Kaz_Ashimura, Ege_Korkan, Michael_McCool, Zoltan_Kis,
Daniel_Peintner, Tomoaki_Mizushima
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Previous minutes
2. [4]TD call discussion
3. [5]Issue 200: Error mapping
4. [6]Issue 202
5. [7]Issue 201
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: zkis
Previous minutes
<kaz> [10]Feb-3 minutes
[10] https://www.w3.org/2020/02/03-wot-minutes.html
Previous minutes accepted.
TD call discussion
<dape>
[11]https://github.com/w3c/wot-thing-description/issues/877
[11] https://github.com/w3c/wot-thing-description/issues/877
Daniel created an issue
Daniel: the consensus was that people did not like the idea
that the order of Forms would mean anything.
... clients should choose one Form. In the sense that there is
no MUST (to be respected) order.
McCool: that was the consensus but I not necessarily agree in
not having a mechanism
Zoltan: IIRC they were only against a MUST mechanism, not
against an optional hint that order matters
Daniel: selecting a Form with best security options is a
client's choice
McCool: we might want to have a rule to express preference for
given security options (counterargument)
Zoltan: currently we cannot infer the TD order of Forms means
anything.
McCool: if there is an order in the TD, Scripting should use
the same order when exposing Forms.
... also in the write path, when based on ExposedThing a TD is
generated, it should maintain the order of declaring the Forms
Daniel: in Scripting API we should use an array rather than a
map in Scripting
Ege: regarding ExposedThing, this cannot be satisfied when say
a database parses the TD and reexposes in a different
composition
McCool: we should consider including a MUST in the TD spec to
maintain order
Daniel: a proxy should also maintain order
Issue 200: Error mapping
[12]https://github.com/w3c/wot-scripting-api/issues/200
[12] https://github.com/w3c/wot-scripting-api/issues/200
Ege: there would be error codes defined by Scripting and then
they would be mapped to protocol errors
Daniel: like NotFoundError could be mapped to 404, right?
... there are not many of those
Ege: we could exposed Errors in ExposedThing which are not
mapped to protocol errors, but in consume part there should be
a mapping
Daniel: so do we specify error types and the codes would come
from protocols?
Ege: e.g. HTTP 404 would be translated to a Scripting error
Zoltan: that might cause privacy issues for exposing underlying
protocol messages
... fingerprinting being one threat and exposing
vulnerabilities another
Ege: see the danger but not convinced it applies
Zoltan: should we create a set of errors in Scripting and
bindings should use those?
McCool: the question is best practices for implementations
Daniel: this problem is already present now, we can pass any
text with the errors
... it's up to the runtime to ensure no data is exposed
... maybe just expose the error codes without the messages
Zoltan: should we make a normative statement about that?
Daniel: whether to expose messages it should be up to
implementations to decide
McCool: during the privacy review they would take an issue for
that
Zoltan: I agree it would be an issue
Daniel: yes, but how can we prove an implementation really does
that?
McCool: well, they would then be non-conformant implementations
Zoltan: we could start with a more constrained solution and see
if it is enough for developers to handle errors
McCool: we could also have API extensions that allow that, but
not provide that info in our API
Daniel: still, current implementation exposed text with the
errors
Zoltan: that is a problem for security
Daniel: I wonder how browser people specify
McCool: 2 issues here: a technical one and a policy one: we do
have a mechanism, but we can opt for not using it
Daniel: I'd say that we put a MUST statement for the spec
stating that text should not contain any privacy sensitive data
McCool: there are security and privacy concerns
... if different devices respond differently to errors, that
would allow fingerprinting
... this is favorizing a predefined set of errors that would be
the same in all devices
... even if the text is fine, small variations in wording could
be used for fingerprinting
... then, it should be obvious that stack traces etc are not
included
... for instance, WoT Scripting could be used from Fugu-like
environments, and what would be the set of errors then
Zoltan: what about security levels/configurations that would
give different levels of errors/debug info?
McCool: it should be the producer's choice whether to expose
that information
... then it could be a security scheme for developer mode etc
Daniel: this overcomplicates things
McCool: also depends where the error comes from, inside
Scripting or from the producer over the network?
Daniel: one could create another Thing with stronger security
scheme, not various levels of security
McCool: actually I like that, as a recommended practice
... on the consumer API, privacy and security is important and
should be enforced
Daniel: in general I wonder what should we do about privacy in
Scripting
McCool: look into the Privacy IG and the discussions with TD
and Architecture
... also look into Browser APIs
Zoltan: should we still try to define a mapping for HTTP errors
at least?
McCool: that might be fine
Zoltan: let's start with HTTP/WSS and CoAP and see where it
leads
McCool: and MQTT as well?
Ege: mapping can be done in the Binding Templates
... it's better to separate the concerns
McCool: ok, so a new protocol will have to go through that
... and find ways to map errors
Zoltan: let's create a table with 3 columns, protocol error
code, Scripting error code and whether the Scripting Error is
available in TypeScript
Daniel: Ege, could we start doing that?
Ege: yes, let's see what is mappable
Daniel: would be nice to see if MQTT is mappable
Ege: MQTT is problematic since in a topic there might be no
subscribers and you don't know if someone received the message
at all
Issue 202
[13]https://github.com/w3c/wot-scripting-api/issues/202
[13] https://github.com/w3c/wot-scripting-api/issues/202
Zoltan: I have the concern this is a big change and goes quite
far in the number of things that need specifying
... so far we relied on the TD spec on how to parse and
validate these options
Daniel: these options are also for selecting which binding/Form
to select
... not necessarily for defining the whole interaction
... we can use the Form index for instance, just as a hint
... this would tell the implementation which Form to pick
... so it's not about exposing the full InteractionOptions
complexity
Issue 201
[14]https://github.com/w3c/wot-scripting-api/issues/201
[14] https://github.com/w3c/wot-scripting-api/issues/201
related to the above
Daniel: currently we have 'any' and not sure if we should
change it to something else
AOB?
Adjourned.
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [15]scribe.perl version 1.154 ([16]CVS log)
$Date: 2020/02/18 13:41:19 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 18 February 2020 13:43:02 UTC