W3C home > Mailing lists > Public > public-wot-wg@w3.org > February 2021

[wot-security] minutes - 1 February 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 15 Feb 2021 21:30:48 +0900
Message-ID: <87im6tfr7r.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
  https://www.w3.org/2021/02/01-wot-sec-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

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

                              WoT Security

01 February 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#1_February_2021
      [3] https://www.w3.org/2021/02/01-wot-sec-irc

Attendees

   Present
          Cristiano_Aguzzi, Kaz_Ashimura, Michael_McCool,
          Oliver_Pfaff, Tomoaki_Mizushima

   Regrets
          Elena_Reshetova

   Chair
          McCool

   Scribe
          kaz

Contents

    1. [4]Prev minutes
    2. [5]WIP: add URI template location for security scheme
       parameters #1032
    3. [6]Consider security issues in Discovery #196
    4. [7]AOB

Meeting minutes

  Prev minutes

   [8]Jan-25

      [8] https://www.w3.org/2021/01/25-wot-sec-minutes.html

   McCool: would be better to add titles for issues/PRs...

   McCool: (goes through the sections on apikeys from the editor's
   draft of the Thing Description spec)

  WIP: add URI template location for security scheme parameters #1032

   [9]PR 1032

      [9] https://github.com/w3c/wot-thing-description/pull/1032

   McCool: (explains the points)

   [10]McCool's comments

     [10] https://github.com/w3c/wot-thing-description/pull/1032#issuecomment-766835622

   

   "securityDefinitions": {

      "template": {

        "scheme": "uri",

        "uriVariables": {

          "ID" : { "type": "string", "@type": "SecurityID" },

          "KEY" : { "type": "string", "@type": "SecurityKey" }

        }

      }

   }

   ]]

   (example above)

   McCool: (adds some more comments in response to the comments
   from Cristiano and Ege)
   … (put a "uri_key" entry, a "uri_id" entry and a combo entry to
   a new example)

   McCool: (shoes the ED of the TD spec again)

   [11]Thing Description Editor's Draft - 5.3.3.6
   APIKeySecurityScheme

     [11] https://w3c.github.io/wot-thing-description/#apikeysecurityscheme

   [12]McCool's updated comments including the new example of the
   combo security

     [12] https://github.com/w3c/wot-thing-description/pull/1032#issuecomment-770853792

   McCool: go with the "name" option

  Consider security issues in Discovery #196

   [13]Issue 196

     [13] https://github.com/w3c/wot-security/issues/196

   [14]related PR - Update SPARQL DDoS ed note #107

     [14] https://github.com/w3c/wot-discovery/pull/107

   <kaz> s/relate PR/relate PR for wot-discovery/

   [15]Section 7. Security and Privacy Considerations

     [15] https://pr-preview.s3.amazonaws.com/w3c/wot-discovery/pull/107.html#security-considerations

   McCool: (shows the related PR 107 for WoT Discovery and its
   preview)
   … (and then goes back to the Issue 196 itself)
   … (adds comments)
   … location may be implicit
   … if a TD simply *appears* in a directory, then we know the
   Thing is in range (e.g. of WiFi) so it can register with the
   TDD
   … (adds some more comments)
   … in general, "disabling" geolocation for personal devices may
   be necessary, although it still is useful for institutional use
   cases
   … another option would be to use a "code generator" to generate
   IDs (perhaps in combination with encrypted TDs) that is
   synchronized between the device and another application
   available to the user
   … so, for example, a user could use an app on their laptop to
   generate the current ID and then do a discovery search to find
   the location of their car, which had registered an encrypted TD
   with tat (rotating) ID with a discovery service.

   Kaz: yeah, this discussion is very important for security
   purposes
   … note that we should be get ready for the privacy review at
   some point (within 6 months)

   McCool: yeah
   … we need to work on this
   … probably we need to allow "nosec" although it's probably a
   very bad idea except for development use cases.
   … we could perhaps add an assertion that [[if a TDD service is
   available to anyone other than the developer and supports
   registration of third-party TDs then it MUST NOT use the
   "nosec" scheme]]

  AOB

   McCool: aob?

   (none)

   [adjourned]


    Minutes manually created (not a transcript), formatted by
    [16]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [16] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 15 February 2021 12:35:52 UTC

This archive was generated by hypermail 2.4.0 : Monday, 15 February 2021 12:35:53 UTC