<kaz> scribenick: Oliver
Meeting agenda proposed, discussed and agreed
<kaz> July-6
Minutes of the last WoT Security call on 2020-07-06 reviewed and accepted
<kaz> wot-usecases PR 27
Review and discussion of security&privacy section for the Geolocation use case (part of pullrequest #27)
Minor changes done for these sections: typo/wording
<inserted> kaz: comment on timing, probably media industry experts are interested in frame-based timing, so that kind of industry-specific timing should be also considered
<inserted> kaz: detailed requirements for that purpose should be discussed within the media use cases
<McCool> wot-architecture issue 527 - Requirements document for time stamps / time series
<inserted> resources on mitigations for untrusted codes
<McCool> https://v8.dev/docs/untrusted-code-mitigations
<McCool> https://www.chromium.org/Home/chromium-security/ssca
<McCool> https://hackaday.com/2018/01/06/lowering-javascript-timer-resolution-thwarts-meltdown-and-spectre/
<inserted> McCool's comment to Issue 527
<McCool> wot-usecases - New PR for OAuth2 flow
In OAuth, the concept of a "authorization grant" is fundamental: it is used to determine the behavior of the OAuth server. There are predefined authorization grants (for specific use cases). Further ones can be defined (if the existing ones don't match given needs)
OAuth "resource owner" is about who owns the resource (can make auth decisions) not about who possesses/serves the resource
RFC 8628 "OAuth 2.0 Device Authorization Grant" is user-oriented. Fitness for WoT still is tbd
<inserted> RFC8628
scribenick: McCool
McCool: two deprecated flows are implicit and password
... and the two client-oriented ones are password and client
...so the two recommended flows are code (resource-owner oriented) and client (client oriented)
... and then there is "device"
... which is a variant of the code flow
scribenick: Oliver
Apparent candidates for WoT: authorization grant, client grant, device grant (details/fitess tbd)
scribenick: McCool
McCool: so recommend that we include code, client, and device in the core vocab
... but provide password and implicit in an extension
... and also a recommendation that if they don't satisfy the spec exactly, they SHOULD define their own flow
scribenick: Oliver
Open issue: how to handle custom (not: IETF, not: W3C) grant types/flows in TD?
New issue create in TD repo (/wot-thing-description) in order to have OAuth client and device grant types/flows covered by TD
<kaz> wot-thing-description - Issue 926
PR #28 for OAuth 2.0 UC shall be merged
<kaz> PR 28
<kaz> [adjourned]