W3C home > Mailing lists > Public > public-wot-wg@w3.org > August 2017

[wot-security] minutes - 11 August 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 11 Aug 2017 22:20:44 +0900
Message-ID: <CAJ8iq9WjAVkM1Xd5btkTFnA1yyyfb20dV+ZkPLCvCKpZqxFYhg@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
  https://www.w3.org/2017/08/11-wot-sec-minutes.html

also as text below.

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                           WoT IG - Security

11 Aug 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/08/11-wot-sec-irc

Attendees

   Present
          Kaz_Ashimura, Elena_Reshetova, Michael_Koster,
          Michael_McCool, Soumya_Kanti_Datta, Tomoaki_Mizushima,
          Uday_Davuluru

   Regrets
   Chair
          McCool

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]new slot for the call
         2. [5]agenda
         3. [6]TD Review
         4. [7]Threat model questionnaire
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

new slot for the call

   elena: not available this time on Friday

   mccool: let's create a doodle

   kaz: will do

agenda

   elena: answers of the questionnaire?
   ... we can walk through the results

   mccool: ok

   kaz: btw, Sebastian mentioned he wanted one more week before
   the review for TD doc
   ... he repeated that view today during the TD call today

   mccool: updates the agenda wiki

TD Review

   mccool: created a branch for TD
   ... can generate a pullrequest
   ... the issue is there is some portion about security within
   the current TD doc
   ... but not ready for review yet
   ... but we can review the current version briefly

   [10]TD draft

     [10] https://w3c.github.io/wot-architecture/

   mccool: there is a security section but very brief

   elena: some more description in the Current Practices document

   mccool: right
   ... what to for then?
   ... the question is what is the minimal thing we need to do?
   ... also not sure about the all the security options

   elena: what is important is backtracking the model
   ... security requirements for TD
   ... concrete measure
   ... options for security
   ... optional vs mandatory
   ... privacy, security
   ... why/when to use

   mccool: what situation requires you to use
   ... how to organize this task?
   ... what kind of structure?

   elena: explain to people why security is needed for TD

   mccool: thread model document
   ... need different level of publication
   ... we could create a wiki page

   kaz: wiki, md or whatever

   mccool: standard document
   ... 4. vocabulary definition
   ... TD model has security portion
   ... but quite empty
   ... also the vocabulary sections are automatically generated
   based on some ontology
   ... so we should not edit the section 4 directly
   ... there is another security section "4.2.8 Security"
   ... also "5.3 Security"
   ... this is for serialization, e.g., JSON-LD
   ... and section "6. Security" is empty
   ... TD TF wanted us for review
   ... let's think about outline

   kaz: several viewpoints, e.g., author, developer, user?

   mccool: issue with the structure
   ... and security mechanism

   [11]McCool's branch

     [11] https://github.com/mmccool/wot-thing-description

   mccool: talked with several people
   ... protocols to map to
   ... CoAP, MQTT, HTTP/HTTPS
   ... Amazon started security on WebSocket
   ... (updates the Security section on his branch)
   ... the threat model has two assets: TD itself and the
   resources that can be accessed via the TD
   ... risks: adversaries and prioritized threats
   ... General: that we "do no harm": security of described
   protocols should be maintained. Don't introduce new security
   mechanisms, but do prederve functionality of existing
   mechanisms
   ... Exposing: when exposing a TD, especially via the Scripting
   API, itshould be possible to use best practices for security
   ... Consuming: a consumed TD should accurately reflect the
   actual security status of a target device
   ... Protocols: we will prioritize the following protocols:
   HTTP(S), CoAP(S)
   ... Recommended Practices
   ... secure delivery and storage of TD
   ... implement an access control mechnism for the TD
   ... use of secure transports
   ... use CoAPS and HTTPS rather tna CoAP and HTTP whenever
   possible
   ... maintaining privacy
   ... avoid exposing personally indentifiable information in a TD
   ... avoid exposing an immutable hardware identifier
   ... APIs should only provide the functionality necessary, and
   no more
   ... devices should be strongly encapsulated
   ... consider different levels of access for different users
   ... (will create a branch on McCool's branch)

   elena: can add some more edit as well

   mccool: we should concentrate on the security section

   <McCool> [12]https://github.com/mmccool/wot-thing-description

     [12] https://github.com/mmccool/wot-thing-description

Threat model questionnaire

   mccool: quickly review the results
   ... anything missing, Koster?

   koster: no specific suggestions at the moment

   kaz: can we see the results at some URL?

   elena: can create a snapshot and let you all know
   ... (goes through the results)
   ... [What are the typical high-level WoT use cases/scenarios
   when privacy might be at risk?

   mccool: separate sections for security and privacy?
   ... would be better to have two separate sections

   elena: [What identifieres (device, thing, user, etc.) do the
   WoT define in the TD or other places?

   mccool: potentially use some ID
   ... identifiers pointing software objects
   ... destroy things we created
   ... disconnected with the hardware itself
   ... stable identifiers are used during the lifecycle
   ... after that, the identifiers go away
   ... name field and id field
   ... URL field
   ... we can change them
   ... but vendor information, etc., should be protected
   ... sensitive information

   elena: vendor id itself is not about the hardware?

   mccool: which device it is
   ... you can talk with the driver
   ... recommend we should not include vendor ID if sensitive
   ... industry environment would make sense
   ... let's add some recommendations to the security section
   ... semantic information on the device
   ... what's the least?

   elena: ok
   ... and we asked about the purpose
   ... [What is their purpose (why can they not be omitted)?

   mccool: the last person mentions that without id it's
   impossible to communicate
   ... Elena, please create a PDF version of the results and share
   it with the group

   elena: ok

   mccool: we'll do a doodle poll for the upcoming calls

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version
    1.152 ([14]CVS log)
    $Date: 2017/08/11 13:16:38 $

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 11 August 2017 13:21:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 11 August 2017 13:21:51 UTC