<scribe> scribe: zkis
<kaz> Feb-3 minutes
Previous minutes accepted.
<dape> 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
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
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
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.