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

[wot-security] minutes - 23 March 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 01 Apr 2020 18:31:04 +0900
Message-ID: <87o8sbtuw7.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/03/23-wot-sec-minutes.html

also as text below.

Thanks a lot for taking the minutes, Elena!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                              WoT Security

23 Mar 2020

Attendees

   Present
          Kaz_Ashimura, David_Ezell, Elena_Reshetova,
          Michael_McCool, Oliver_Pfaff, Tomoaki_Mizushima,
          Zoltan_Kis

   Regrets

   Chair
          McCool

   Scribe
          elena

Contents

     * [2]Topics
         1. [3]Previous minutes
         2. [4]Virtual F2F minutes - security section
         3. [5]PING issue feedback
         4. [6]PRs
         5. [7]Issues
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: elena

Previous minutes

   agenda for today's call is at
   [10]https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf

     [10] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf

   first looking at the minutes from March 9
   [11]https://www.w3.org/2020/03/09-wot-sec-minutes.html

     [11] https://www.w3.org/2020/03/09-wot-sec-minutes.html

   <McCool> typo, rivisit -> revisit

   McCool, any comments/objections to accepting minutes?

   McCool: minutes accepted

   <kaz> (typo fixed)

Virtual F2F minutes - security section

   McCool: from virtual F2F each taskforce should check the
   respectable minutes

   <kaz> [12]security session

     [12] https://www.w3.org/2020/03/16-wot-minutes.html#item06

   McCool: we might need to create issue for MQTT brokers
   ... we didnt get to discuss the lifecycle during F2F
   ... should be discussed this week at architecture call

   typo IETF Aniva -> IETF Anima

   <kaz> (fixed)

   terminology from ISO --> terminology from IEEE

   <kaz> (fixed)

   MASA should be expanded to manufacturer authorized signing
   authority

   <kaz> (fixed)

   anser -> answer

   <kaz> (fixed)

   McCool: any other comments, objections to approving security
   section of F2F?
   ... no objections, approved with few fixes above

PING issue feedback

   McCool: no update on PING

PRs

   Looking at PR 828 from wot repository

   <kaz> [13]WoT repo PR 828

     [13] https://github.com/w3c/wot/pull/828

   McCool, this is an old PR which is probably outdated by now

   McCool: proposing to close and ask to resubmit with updates

   McCool writes a resolution on PR

   McCool: any objections to closing this PR?

   PR closed

   McCool: any PR from Oliver pending?

   Oliver: nothing ready right now

   McCool: reopening a PR since it belongs to wot repo and not
   security repo
   ... we have two PRs from Oliver, what order we should handle
   them?

   <kaz> [14]PR 159

     [14] https://github.com/w3c/wot-security/pull/159

   Oliver: PR 159 can be closed without merging
   ... text has been already moved to a different place

   McCool: next is PR 164

   <kaz> [15]PR 164

     [15] https://github.com/w3c/wot-security/pull/164

   McCool: I have suggested some changes to this PR, but they are
   not critical
   ... so we can merge it and cleanup can be done later
   ... how should we proceed with this?

   Oliver: I prefer to update this PR first

   McCool: we can then consider updated PR in next week's call

Issues

   McCool: let's recap new issues we have
   ... issue 160 has been discussed with Scripting taskforce

   <kaz> [16]Issue 160

     [16] https://github.com/w3c/wot-security/issues/160

   McCool is writing the summary from scripting call on issue

   McCool: in summary - we need to do PoC first and dont change
   scripting API right now. We might need changes to runtimes
   ... our S&P guidelines should provide some recommendations on
   implementing runtimes to mitigate these risks
   ... should we close or leave this issue open?
   ... discovery API does not need changes, so I am favoring
   closing this issue

   issue closed, please feel free to reopen if needed

   McCool: issues 161 and 166 are related
   ... looking into 161

   McCool is commenting on 161

   <kaz> [17]Issue 161

     [17] https://github.com/w3c/wot-security/issues/161

   McCool is proposing to have a mapping in TD for pubkey and
   didURL

   McCool: this requires integrity of TD
   ... we can define an optional proof section and specify that it
   is required if TD has "publickey"
   ... given our timeframe, I propose that it should be part of
   version 2 of TD spec
   ... update to TD should be mostly backwards compatible and it
   is not a correct place

   by that time hopefully JSON-LD gets a normative status and we
   can just use it

   McCool: any other comments on this?
   ... we need to understand needs and usecases for key management
   ... my action would be to create a new PR to TD spec to define
   this mapping and also separate PR to create a proof section in
   TD
   ... not sure how to make a PR to TD 2.0 (Next) while people
   still working on update to current TD version

   <kaz> [18]Issue 166

     [18] https://github.com/w3c/wot-security/issues/166

   McCool: any comments?

   Elena: this sounds reasonable, bigger work would be to define
   practices on key management, revocation, etc.

   McCool: we should review proposed JSON-LD spec

   to make sure it has what we need

   Next issue 152

   not a pressing issue

   McCool: next issue 165

   <kaz> [19]Issue 165

     [19] https://github.com/w3c/wot-security/issues/165

   McCool: Siemens is planning to update node-wot to support
   OAuth2.0
   ... but when introducing OAuth2.0 there will be flows that do
   not make sense for an IoT enviroment

   but maybe better to support all flows for consistency

   McCool is leaving comment on the issue

   McCool: I am hoping that by summer we have this as part of TD
   update release
   ... any comments on OAuth2.0?
   ... David do you have any thoughts on requirements that would
   be relevant here

   David: we consider OAuth2.0 as required due to its good
   security
   ... OAuth has good methods for key updates

   McCool: OAuth2.0 has good reputation, and even if it is not a
   perfect fit for IoT, it is well known scheme
   ... consumer does not have to support all the flows of OAuth
   ... if anyone has further comments, please let us know
   ... we are almost at the end, let's next week go through F2F
   minutes and check if we need to open new issues
   ... anything critical to create right now?
   ... lifecycle discussion should be moved to arhcitecture

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [20]scribe.perl version 1.154 ([21]CVS log)
    $Date: 2020/04/01 09:28:49 $

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [21] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 1 April 2020 09:31:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 April 2020 09:31:12 UTC