[wot-security] minutes - 15 February 2021 (was Re: [wot-security] minutes - 22 February 2021)

Sorry apparetnly I sent the previous message with a wrong subject...

The minutes from the WoT Security call on 15 February 2021 are available at:
  https://www.w3.org/2021/02/15-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

15 February 2021

   [2]Agenda. [3]IRC log.

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

Attendees

   Present
          Cristiano_Aguzzi, Kaz_Ashimura, Michael_McCool,
          Oliver_Pfaff, Philipp-Alexander_Blum, Tomoaki_Mizushima

   Regrets
          -

   Chair
          McCool

   Scribe
          cris_

Contents

    1. [4]previous minutes
    2. [5]issues
    3. [6]Geolocation

Meeting minutes

  previous minutes

   <kaz> [7]Feb-1

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

   McCool: we discussed management API on scripting api. We need
   some text to describe what is out of the scope in scripting api
   … I also opened an issue in discovery. we'll look at it later
   … finally APA
   … any objections for accepting the minutes?
   … ok we'll publish these
   … any updates?
   … none

  issues

   McCool: I'll go through open issues in the security repo

   McCool: Lagally want a writeup about canonicalization of TDs.
   It is related to #166

   Cristiano: I opened some issues about security and management
   apis on scripting api, we could check them out

   McCool: yeah true, meanwhile I notice some problems with the
   published minutes. Links have a trailing column which cause an
   error

   Kaz: fixing

   McCool: OK we'll check them later.

   topic issue 166

   Kaz: btw links fixed

   <kaz> [8]wot-security issue 166 - Add integrity protection
   (proof section) to TDs

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

   McCool: we discussed about minimum requirement for constraint
   devices. We focus about the minimum memory requirement to
   handle a TD. We nailed down the discussion to the size of the
   TD.
   … we concluded to have a min size of 64Kb

   McCool: the problem is signing needs canonicalization but smal
   devices might not be able to perform the process.

   Cristiano: canonicalization could happen at development time.

   McCool: we could even make canonicalization part of the sign
   process but it will burden a constraint device.

   philipp: 64kb might not be enough.

   McCool: we found libraries capable to handle our requirements
   in 64Kb

   <McCool> [9]WoT Reference Platform

      [9] https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/reference/hw.md

   McCool: we could move this question to the profile call

   McCool: the trouble with small devices is that we might not
   have a communication hardware stack. however we were able to
   implement wot in small devices like esp32

   Philipp: I currently working with Nordic NRF-52832 that has 32
   Kb RAM and I have able to expose a TD. However, consuming a TD
   is surely too much.

   Cristiano: why consuming a TD is too much? can you read it in
   streaming mode?

   Philipp: I need to parse JSON which kinda heavy.
   … plus I don't see the use case for this
   … btw the Nordic has also hardware acceleration
   … for signing and maybe SSL

   Cristiano: I agree that the use case is a little bit off.
   … using a JSON streaming parser you might be able to consume a
   TD

   <citrullin> Agree, that sounds more reasonable.

   McCool: Interesting, about validation process I'm noting down
   that before signing a TD should be valid

   McCool: I think there's some use cases for consuming TDs in
   sensors. I'm noting down a peer-to-peer pairing example in
   issue #166

   Cristiano: btw canonicalization could help streaming parser to
   optimize searching of particular conditions

   McCool: true, noting that down
   … also having standard semantic types could be useful.
   … related to the peer-to-peer example we could even think about
   filter parameters in the direct discovery process.
   … in short if you know exactly what you're looking for you
   could extract it without having the whole TD in memory
   … does this description convince you, Philipp?

   Philipp: Probably I need to read more about business
   environments but yes
   … streaming makes for sure sense
   … a lot things to think about

   McCool: we still have a lot of todos here. One is to survey
   hardware accelerators. TDs should be compatible whit such a
   hardware
   … Philipp could you please do this? at least for you device?

   Philipp: ok

   McCool: chain of proof is flexible about the algorithm used. So
   we just need to choose one according to the survey

  Geolocation

   <McCool> [10]https://github.com/w3c/wot-discovery/pull/114

     [10] https://github.com/w3c/wot-discovery/pull/114

   McCool: working on #114
   … there's a section about privacy. I have to be careful when
   sharing locations. It can be even inferred by a registration in
   a particular TD
   … also history about a location could be used to infer velocity
   and learn about the fact the user was on a vehicle or not.

   <kaz> [adjourned]


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

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

Received on Monday, 1 March 2021 06:26:56 UTC