W3C home > Mailing lists > Public > public-wot-wg@w3.org > October 2018

[wot-security] minutes - 8 October 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 17 Oct 2018 03:10:43 +0900
Message-ID: <CAJ8iq9V99cv2kW4YF+eF6oaE2_q5Qaq6_Ma0Q8EvnYaZHKgs0w@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:

also as text below.





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

                               - DRAFT -

                              WoT Security

08 Oct 2018


          Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
          Michael_Koster, Tomoaki_Mizushima





     * [2]Topics
         1. [3]agenda
         2. [4]review of previous minutes
         3. [5]minutes from Sep 10
         4. [6]Publication status
         5. [7]Object security
         6. [8]Security consideration sections
         7. [9]Elena's update
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

   <scribe> scribenick: kaz


   McCool: object security?
   ... security scheme to handle

   Koster: need to handle key materials
   ... tell the system to have key materials
   ... there are many ways to handle object security
   ... going to handle some mechanism like handshaking

   McCool: ok
   ... (shares the screen)

   Koster: would get better understanding
   ... e.g., pub/sub for security
   ... maybe close to the end of the year

   McCool: (updates the agenda wiki)
   ... Object security: COSE and OSCORE
   ... Security consideration sections: Thing Description
   (McCool), Scripting API (Elena)

   Koster: Secure multicast

   McCool: status of W3C Note publication
   ... also previous minutes review

review of previous minutes


     [12] https://www.w3.org/2018/10/01-wot-sec-minutes.html


     [13] https://www.w3.org/2018/09/10-wot-sec-minutes.html

   McCool: (starting with Oct-1)
   ... basically looked at issue 118

   [14]issue 118

     [14] https://github.com/w3c/wot-security/issues/118

   McCool: this is where object security came up

   Koster: JavaScript Object for JOSE as well

   McCool: (adds JOSE to today's agenda)
   ... ok
   ... let's go through the minutes from Oct 1
   ... let's add a note here
   ... object security
   ... use the title of issue 118

   Kaz: ok

   Signing and encrypting body of actual responses of interaction
   pattern endpoints


   McCool: and then
   ... update from online plugfest
   ... TPAC schedule
   ... publication plan
   ... security consideration for TD
   ... any other corrections?


   McCool: ok let's accept the minutes except adding the title of
   issue 118

minutes from Sep 10

   McCool: prior to plugfest
   ... adding Kaz to the editors list
   ... wondering if it's ok
   ... I'm OK with it
   ... any thought?
   ... let's talk about this offline
   ... PR207
   ... online plugfest
   ... best practices document
   ... btw, any update from Ryo?

   Kaz: not yet

   McCool: ok
   ... now the publication is in process
   ... would accept the minutes
   ... any objections?


   McCool: accepted

Publication status

   Kaz: have been working on TD

   McCool: can we publish the note by TPAC?

   Kaz: maybe next week
   ... anyway, I'll start the initial check so that I can get back
   to you

   McCool: ok

Object security

   ... need to look into them
   ... we should address the standards
   ... how the payload is encoded
   ... that is a media issue
   ... should specify media-type for them
   ... regular media-type and another one for encryption
   ... do we combine or separate the security scheme

   Koster: the way it works
   ... JS and CBOR or JSON and CBOR, etc.
   ... similar work done for HTTP
   ... various ways
   ... thing to look at is what header option would remain
   ... regular CoAP processor and payload separately
   ... options for protected or unprotected
   ... (refers to rfc8152)
   ... unicast or not
   ... having media-type for encoding
   ... how to specify media-type and sub media-type

   McCool: could be sub type
   ... looking at here for CoAP
   ... COSE encoding
   ... these parameters and algorithm used
   ... section 3.1
   ... table 2
   ... need to read through this draft

   Koster: don't really know either
   ... between schema and media-type handling

   McCool: kind of secure encoding
   ... you normally combine the other things
   ... 5.4 how to encrypt and decrypt for AE algorithm
   ... Koster, are you volunteering to read through RFC8152?

   Koster: yeah


     [15] https://tools.ietf.org/html/rfc8152

   McCool: do we have to modify TD at all?

   Elena: we've indicated security metadata
   ... but not specified it in detail
   ... need to go into the detail
   ... some payload may available even without sign
   ... not going to be very different
   ... need new token

   McCool: maybe a bit different level of metadata
   ... simply say we need COSE
   ... third level indicating the parameter
   ... intermediate level to mention COSE and JOSE
   ... COSE with possible algorithm

   Koster: would agree with Elena
   ... need to see the other systems using similar pattern
   ... we don't have to provide tags
   ... can go into the draft and see what is needed
   ... we may need to invent our own protocol

   McCool: need common use cases
   ... for multicasting

   Koster: URI and scheme
   ... IP address to be defined for multicast purposes
   ... maybe like observing, but not sure

   McCool: observing or eventing

   Koster: it's listening anyway

   McCool: we could look into multicast first
   ... and think about security for that later

Security consideration sections


     [16] https://github.com/mmccool/wot-thing-description/blob/security-considerations/index.html.template.html

   McCool: I have something and Elena also has something
   ... changed the paragraph here
   ... "In many locales, ..."
   ... TD can contain personally identifiable information
   ... normative assertion here
   ... A thing description associated with a personal device
   SHOULD be treated as if it contained personally identifiable

   Koster: interesting thing
   ... move the point on consent
   ... we're looking at interoperability
   ... getting beyond that is interesting

   McCool: there is a question about when to prepare it

   Koster: interesting but out of our scope, isn't it?

   McCool: information needed to be accessed
   ... main point here is what should be normative assertion
   ... (mentions some example)
   ... basically we're recommending same category coming from

   Koster: makes a lot of sense

   McCool: only edited the last paragraph here
   ... informative part and normative part
   ... seems to be OK to merge this proposal?
   ... need to regenerate the HTML for TD draft

Elena's update

   Elena: (shows scriptin API draft on her PC)
   ... 9. Security and Privacy
   ... specific recommendations related to WoT runtime

   McCool: 3 categories?
   ... big paragraph could be split into 3 pieces
   ... sometimes you don't really need isolation
   ... trouble is that normative assertion needs statement
   ... particular cases to be described
   ... you should expand the statement

   Elena: ok

   Kaz: regarding the first bullet. right?

   McCool: yes
   ... normative assertion needs to be clear

   Kaz: maybe safer to use section title with a link to the
   fragment instead of section number

   Elena: ok
   ... the next one
   ... (second bullet)
   ... Therefore the WoT Runtime SHOULD avoid exposing the native
   device interfaces to the script developers.

   McCool: orchestrating with the other devices?
   ... the first sentence may be a bit misleading
   ... need right logics
   ... may want to say
   ... have to expose the endpoint
   ... maybe instead
   ... avoid directly exposing
   ... maybe we could add some clarification here
   ... only required functionalities here

   Elena: ok
   ... next bullet
   ... Therefore, if WoT Runtime supports post-manufacturing
   provisioning or update of WoT scripts, WoT runtime or any
   related data, such operations SHOULD be done in a secure

   McCool: we'd mention best practices?
   ... "in a secure fashion" is important
   ... we need to include a section on security update

   Elena: ok
   ... next one
   ... Therefore the WoT runtime SHOULD securely store the
   provisioned security credentials, guaranteeing their integrity
   and confidentiality.

   Koster: what do you want to test for within an implementation?

   McCool: the issue is trust of scripts
   ... dangerous to use untrusted scripts
   ... this is intentional feature design
   ... we should emphasize it

   Kaz: which part to be modified?

   Elena: additional sentence
   ... should not expose an API directly access security
   credentials for WoT scripts

   Kaz: will you create a PR for these changes?

   Elena: will do

   McCool: there is functionality on Thing Directory
   ... probably we should add an extra point here
   ... script should not assume ID immutable
   ... ID may change via transition

   Elena: functionality to be preserved?

   McCool: yes
   ... ID can change
   ... we should go ahead and generate a PR
   ... should provide a proposal to the Scripting guys and get

   Elena: what about testing?

   McCool: why don't we have an empty place holder section at the

   Elena: ok

   McCool: Elena will create a PR to be reviewed
   ... and I'll update my PR as well


Summary of Action Items

   See [17]the Action wiki.

     [17] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Actions

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [18]scribe.perl version 1.154 ([19]CVS log)
    $Date: 2018/10/10 07:08:00 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 October 2018 18:11:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:51 UTC