<scribe> scribe: zkis

Previous minutes

<kaz> Feb-3 minutes

Previous minutes accepted.

TD call discussion

<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

Issue 200: Error mapping

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

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

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.