[wot-security] minutes - 29 November 2021

available at:
  https://www.w3.org/2021/11/29-wot-sec-minutes.html

also as text below.

Thanks a lot for taking the minutes, Cristiano!

Kazuyuki

---
   [1]W3C

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

                              WoT Security

29 November 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#29_November_2021
      [3] https://www.w3.org/2021/11/29-wot-sec-irc

Attendees

   Present
          Cristiano_Aguzzi, Jiye_Park, Kaz_Ashimura,
          Michael_McCool, Philipp_Blum, Tomoaki_Mizushima

   Regrets
          -

   Chair
          McCool

   Scribe
          cris_

Contents

    1. [4]minutes
    2. [5]TD issues
         1. [6]Canonicalization
         2. [7]issue 998
         3. [8]issue 953
         4. [9]issue 949
         5. [10]issue 948
         6. [11]security guidelines issue 5

Meeting minutes

  minutes

   <kaz> [12]Nov-22

     [12] https://www.w3.org/2021/11/22-wot-sec-minutes.html

   McCool: we discuss local transport and onboarding
   … we are heading to a conclusion
   … we are working with on-going specs like TLS and DTLS 1.3
   … I was thinking that sec guidelines should be just meant for
   green field devices
   … but it might be relevant also for brownfield devices that has
   security configuration parameters
   … minutes looks good?
   … ok approved

  TD issues

   <kaz> [13]wot-thing-description issues marked as "V1.1" and
   assigned to McCool

     [13] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:V1.1+assignee:mmccool

   McCool: we should scan WoT Thing Description repo for security
   issues
   … I did this myself but I found that some of them were miss
   labeled (they were assigned to me but they weren't labelled as
   security)

    Canonicalization

   McCool: in the current list of issues there's a set of issues
   related to canonicalization
   … my advice is to move them to WoT 2.0
   … it adds an extra burden to producers
   … they are usually small devices, it might more sense to move
   the processing to more capable devices (i.e. consumers)
   … I created a PR for removing canonicalization in the TD
   … we have to wait for a consensus before talking about it

    issue 998

   <kaz> [14]wot-thing-description issue 998 - [security] API key
   and PSK security schemes are not referenced or explained

     [14] https://github.com/w3c/wot-thing-description/issues/998

   McCool: it should be already solved
   … I found a PR that addressed the points
   … please take a look if the new text satisfy the issue

    issue 953

   <kaz> [15]wot-thing-description issue 953 - For OAuth2 device
   flow, should we define a "device authorization" element?

     [15] https://github.com/w3c/wot-thing-description/issues/953

   McCool: we discussed a lot about the term to use for the
   authorization endpoint for oAuth 2.0 device flow
   … I think we settle the discussion about adding a ediotor's
   note
   … adding device_athorization might make the text more complex

   McCool: I would remove the editor's note

   Cristiano: I agree the text it is pretty clear

   Cristiano: it might worth to refactor the OAuth2SecurityScheme
   in subclasses

   McCool: true, but at the current state of the specification
   process we are just doing fix ups no major changes. I'd stick
   with the decision above

   <cris> +1

    issue 949

   <kaz> [16]wot-thing-description issue 949 - We need extension
   ontology to include implicit and password flows in OAuth2

     [16] https://github.com/w3c/wot-thing-description/issues/949

   McCool: we took out implicit and password flow because they are
   now deprecated. To use them now you have to use an extension
   vocabulary
   … however, in 1.0 we *defined* those terms and removing them
   causes backwards incompatibility.

   Cristiano: we are moving definitions out side our vocabulary,
   is this actually causing backwards compatibility problems?

   McCool: consumers can understand both 1.0 and td 1.1 using the
   context URL. Therefore they will not have a problem
   … for the spec I propose using a fixed URL extension

   McCool: do you think that we need an ontology file for those
   not standard flows?

   Cristiano: not strong opinion
   … not sure if the implicit flow is used in IoT context

   philipp: true, maybe none of the flows is really supported
   nowadays

   McCool: ok, my understanding is that an extension ontology is a
   nice-to-have but not essential.
   … if we provide the ontology we need two implementations
   … not sure if it is well spent time

    issue 948

   <kaz> [17]wot-thing-description issue 948 - We need an OAuth2
   example for TD 1.1

     [17] https://github.com/w3c/wot-thing-description/issues/948

   McCool: we have one example already

   Cristiano: I added examples for other flows, but not sure if we
   were asking to have more examples about code flow

   McCool: I think that we just need examples for client flow
   … code flow is not really useful
   … my proposal is to change code to client
   … and remove authorization endpoint
   … we may add other flows but as optional (e.g. always together
   client flow)

    security guidelines issue 5

   <kaz> [18]wot-security-best-practices issue 5- Recommended
   OAuth2 flows

     [18] https://github.com/w3c/wot-security-best-practices/issues/5

   McCool: reading cristiano's comment I agree, a solution might
   be to recommend to use two schemes.
   … it is complicated therefore it might be good to put a good
   example

   McCool: aob?
   … ok meet closed

   <kaz> [adjourned]


    Minutes manually created (not a transcript), formatted by
    [19]scribe.perl version 159 (Fri Nov 5 17:37:14 2021 UTC).

     [19] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 10 January 2022 08:57:05 UTC