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

[wot-security] minutes - 4 June 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 12 Jun 2018 19:01:01 +0900
Message-ID: <CAJ8iq9Vf2H2nncBsDx14TzNqh+s4evV_WFV7L8a=G+ie90Lvcg@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.

Thanks a lot for taking these minutes, Michael Koster!




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

                               - DRAFT -

                              WoT Security

04 Jun 2018


          Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
          Kazuaki_Nimura, Michael_Koster, Tomoaki_Mizushima



          mjkoster, kaz


     * [2]Topics
         1. [3]Agenda review
         2. [4]Review previous minutes
         3. [5]Security metadata PR
         4. [6]Follow up on the issue of how security metadata is
            used in TD
         5. [7]PR #103
         6. [8]Security for the next plugfest
         7. [9]Actions
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

   <kaz> scribenick: mjkoster

Agenda review

   McCool: goes through the [12]agenda

     [12] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda

review previous minutes

   <kaz> [13]prev minutes

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

   <kaz> explanation on Linux Security Summit should be added
   (conflict with TPAC and Elena can't join TPAC)

   McCool: more explanation is needed in section discussion TPAC
   ... remove mention of OASIS

   <McCool> mccool: change "one way is Oasis" to "I just have to
   follow the internal Intel processes"

   McCool: minutes accepted except the above tweaks

Security metadata PR

   <kaz> [14]PR 144

     [14] https://github.com/w3c/wot-thing-description/pull/144


   McCool: comments about OCF security scheme
   ... removed OCF from the core vocabulary, but the security
   vocabulary needs to be more open ended
   ... can we use a custom extension on security vocabulary?

   Koster: this is what I meant by extension points needed for
   both security and forms

   McCool: need to explore how to include these as extensions to
   the core vocabulary
   ... review individual updates, http diff

   <kaz> [15]HTML diff

     [15] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html

   McCool: the main change is in the security section of the TD
   ... want to change from URI to URL

   <kaz> [16]5.4 Security Vocabulary Definition

     [16] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html#sec-security-vocabulary-definition

   McCool: removed ocf as a scheme
   ... oauth and bearer are separate schemes, oauth implies bearer
   pattern and doesn't need to include the term "bearer" with
   ... took out the security definitions section
   ... now the security in lower level constructs will over-ride
   the definitions in higher level constructs
   ... examples in the document of over-ride behavior
   ... same levels, different levels, multiple schemes examples
   ... multiple schemes at the same instance provide a choice of
   ... in other words the "or" pattern
   ... removes security definitions for links
   ... mechanism for adding a scheme from an external vocabulary
   ... one issue is that a lot of the terms are defined as strings
   but should be enumeration types
   ... more constraints would be good for validation
   ... how are the constraints applied from external namespaces?
   ... need a way to add values which makes the validation harder
   ... its a general problem
   ... has anyone else reviewed?

   Elena: have started reviewing

   McCool: is it ready to include in the editors draft?
   ... any objections to merging with the TD master branch

   Elena: what about the security and privacy consideration

   McCool: some fixed needed
   ... will do a few more changes and extend the example to show
   "or" pattern
   ... need to draft a section for the TD document, after the
   ... any other changes needed?
   ... OK, will make these changes and merge

Follow up on the issue of how security metadata is used in TD

   McCool: to know what the pre-requisites are for accessing a
   ... sometimes the metadata are exposed in the protocol
   ... exposing in TD enables developers to plan in advance
   ... however there is a tension between class and instance TDs
   ... security metadata makes more sense in a class TD, and ties
   into class templates

   <inserted> scribenick: kaz

   Koster: all of the information put into the TD could be sort of
   ... maybe annotations of different levels
   ... a class template might make sense
   ... also pre-qualified things
   ... another stage of filtering
   ... to choose appropriate security mechanism
   ... more granular hypermedia mechanism
   ... there are bunch of differences
   ... there might be a way of discovery dynamically

   McCool: many choices among access points

   <inserted> scribenick: mjkoster

   McCool: the optimization of having it all in one place may be
   ... being able to plan ahead

   <inserted> scribenick: kaz

   Koster: do we need a definition section?
   ... would see use cases
   ... going to build a client
   ... and consider how to use security
   ... not sure at the moment

   MkCool: typed in a bunch of stuff
   ... 3 levels of things relevant here
   ... what include in core vocabulary, etc.
   ... 3 protocols which matter: HTTP, CoAP and MQTT

   <inserted> scribenick: mjkoster

   McCool: protocols that matter are http, coap, and mqtt
   ... what are the choices in schemes for these different
   ... http has a lot of choices, but maybe CoAP and MQTT are more
   limited to a fixed set of schemes
   ... MQTT has basic
   ... CoAP has DTLS
   ... what about object security?
   ... so things that have choice should be included, things that
   are accepted standards should be included
   ... the schemes and options we have are probably good enough

PR #103

   McCool: please review for discussion at the next meeting

   <kaz> [17]PR 103

     [17] https://github.com/w3c/wot-security/pull/103

Security for the next plugfest

   <kaz> [18]McCool's slides

     [18] https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/Security-Bundang-PlugFest-Preparation.pptx

   McCool: would like to get to a set of concrete objectives
   ... get everyone to use security as a standard practice
   ... maybe starting with TLS
   ... online access to things will drive secure implementations
   ... focus on basic, digest, and bearer style auth
   ... protection of a thing directory API, using auth
   ... there is an npm option that was effective in resolving many
   of hte issues in node-wot by updating packages
   ... recommended practices, where should this go?


   McCool: finish PR and merge it
   ... tools to use
   ... other ongoing actions from the last minutes
   ... just the one new action on the PR integration
   ... meeting adjourned

Summary of Action Items

   [ONGOING] ACTION: mccool to talk with security guys about
   testing/validation timeline
   [ONGOING] ACTION: mccool to work on issue 70 (Require Not
   Exposing Immutable Hardware Identifiers?)
   [ONGOING] ACTION: mjkoster/elena to review examples in the
   security spec
   [ONGOING] ACTION: mccool to write a short proposal on what
   security tools to use for the next plugfest

   [NEW] ACTION: mccool to finish TD PR 144 (Security metadata)
   and merge it

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [19]scribe.perl version
    1.152 ([20]CVS log)
    $Date: 2018/06/12 09:55:56 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 12 June 2018 10:02:12 UTC

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