<scribe> scribe: zkis
Kaz: for today's meeting Cristiano is an invited guest
<kaz> https://www.w3.org/Consortium/Patent-Policy-20170801/
<kaz> https://www.w3.org/2003/12/22-pp-faq.html#non-participants
<zolkis> https://www.w3.org/2020/05/04-wot-minutes.html
Previous minutes approved.
Daniel: we need to discuss and plan
about the virtual F2F
... also about the plugfest
... maybe we can tackle the OAuth issue and some open
explorations
... created github label for issues marked with F2F
Zoltan: all F2F discussion topics
should appear as github issues
... we could also create a F2F label on node-wot as well
Cristiano: presents the issue
... the developer may want to control the flow for not needing
to redirect to an authorization page and then back
... as solutions, we might want to leave it entirely to the UA
showing any dialog needed in the flow, or provide an API
Zoltan: we have a MitM problem with
the second solution
... another option is to have a separate security setup, by
provisioning or separate API
... without the API implementation or the script having access
to the tokens/keys involved
... the servient stack needs to be security hardened
Daniel: agreed to first set up security
Cristiano: there might be multiple flows
<dape> DP: developer could launch security dummies first. So it is in the hand of the developer
Zoltan: we might want a separate API entry point for security setup (i.e. a separate require in node)
Cristiano: fine with that
Daniel: does it work with the API we have right now?
Cristiano: it does work, but we have 4 flows, of which 2 are implemented, so we need to check
Zoltan: the use case for OAuth was required by Singapore?
Daniel: yes, they need that
Zoltan: then let's ask them which flows are needed
Daniel: 2 flows are implemented, we are discussing the 3rd (the code flow) and the 4th is deprecated
Zoltan: let's discuss this in the
security call
... none of the options are ruled out, but would prefer to stay
consistent with browser APIs and solve security issues outside
the API if possible
Zoltan: presents the PR
... the API has not changed, only the algorithms
... is backwards compatible
Daniel: depending on protocol we might get different data
Cristiano: what about streaming data?
Zoltan: we could use Fetch Standard
(Response object), it'a available both in the browser and
Node
... we need to work more on that
... of course one could use Fetch at low level, but this API
tries to be a convenience API
Daniel: Siemens thinks this API is useful
Cristiano: agreed
Daniel: I plan to add the TypeScript
definitions for this PR
... so that we can explore with InteractionData
Zoltan: should we merge the PR for now?
Daniel: it's abckwards compatible,
just extends, so it's fine
... we can revert if needed
Zoltan: let's wait to see if there are any issues with the TypeScript definitions
Daniel: ok, let's keep it open for a few more days
Zoltan: optionally specify which lang
and encoding to request
... how does the TD handle this?
Daniel: yes we need to handle it at TD level
Cristiano: agreed
Zoltan: regardless how it is defined in TD we need to expose it in Scripting
Cristiano: encoding can be handled by the content type
Zoltan: we also need to look into the Encoding Standard and then come up with the best abstraction
https://encoding.spec.whatwg.org/
<dape> Zoltan: Please read algorithms in https://pr-preview.s3.amazonaws.com/zolkis/wot-scripting-api/pull/209.html#idl-index
Zoltan: CA please also review the PR
AOB?
[adjourned]