W3C home > Mailing lists > Public > public-wot-ig@w3.org > July 2020

[wot-security] minutes - 13 July 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 21 Jul 2020 17:48:20 +0900
Message-ID: <87lfjdgsob.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/07/13-wot-sec-minutes.html

also as text below.

Thanks a lot for taking the minutes, Oliver and Michael McCool!

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT Security

13 Jul 2020

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#13_July_2020

Attendees

   Present
          Kaz_Ashimura, Oliver_Pfaff, Michael_McCool,
          Elena_Reshetova, Farshid_Tavakolizadeh,
          Cristiano_Aguzzi, Tomoaki_Mizushima, David_Ezell

   Regrets

   Chair
          McCool

   Scribe
          Oliver, McCool

Contents

     * [3]Topics
         1. [4]Agenda
         2. [5]Prev minutes
         3. [6]Geolocation
         4. [7]OAuth2
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: Oliver

Agenda

   Meeting agenda proposed, discussed and agreed

Prev minutes

   <kaz> [10]July-6

     [10] https://www.w3.org/2020/07/06-wot-sec-minutes.html

   Minutes of the last WoT Security call on 2020-07-06 reviewed
   and accepted

Geolocation

   <kaz> [11]wot-usecases PR 27

     [11] https://github.com/w3c/wot-usecases/pull/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> [12]wot-architecture issue 527 - Requirements document
   for time stamps / time series

     [12] https://github.com/w3c/wot-architecture/issues/527

   <inserted> resources on mitigations for untrusted codes

   <McCool> [13]https://v8.dev/docs/untrusted-code-mitigations

     [13] https://v8.dev/docs/untrusted-code-mitigations

   <McCool>
   [14]https://www.chromium.org/Home/chromium-security/ssca

     [14] https://www.chromium.org/Home/chromium-security/ssca

   <McCool>
   [15]https://hackaday.com/2018/01/06/lowering-javascript-timer-r
   esolution-thwarts-meltdown-and-spectre/

     [15] https://hackaday.com/2018/01/06/lowering-javascript-timer-resolution-thwarts-meltdown-and-spectre/

   <inserted> [16]McCool's comment to Issue 527

     [16] https://github.com/w3c/wot-architecture/issues/527#issuecomment-657530023

OAuth2

   <McCool> [17]wot-usecases - New PR for OAuth2 flow

     [17] https://github.com/w3c/wot-usecases/pull/28

   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> [18]RFC8628

     [18] https://tools.ietf.org/html/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> [19]wot-thing-description - Issue 926

     [19] https://github.com/w3c/wot-thing-description/issues/926

   PR #28 for OAuth 2.0 UC shall be merged

   <kaz> [20]PR 28

     [20] https://github.com/w3c/wot-usecases/pull/28

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [21]scribe.perl version ([22]CVS log)
    $Date: 2020/07/14 08:30:26 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [22] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 21 July 2020 08:47:03 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 21 July 2020 08:47:03 UTC