[wot-security] minutes - 23 April 2018

available at:
  https://www.w3.org/2018/04/23-wot-sec-minutes.html

also as text below.

Thanks,

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                              WoT Security

23 Apr 2018

   [2]Agenda

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

Attendees

   Present
          Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
          Michael_Koster, Barry_Leiba, Michael_Lagally

   Regrets
          Kazuaki_Nimura

   Chair
          McCool

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]prev minutes
         2. [5]PR 89
         3. [6]PR 88
         4. [7]next
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   [10]scripting issue 111

     [10] https://github.com/w3c/wot-scripting-api/issues/111

   [11]prev minutes

     [11] https://www.w3.org/2018/04/16-wot-sec-minutes.html

prev minutes

   McCool: should add action items
   ... issue 69 for elena and issue 68 as well
   ... issue 70 for mccool
   ... terminology for elena/koster
   ... old action for mccool to talk about testing validation also
   ... other than those actions, would accept the minutes

   (no objections)

PR 89

   [12]pullrequest 89

     [12] https://github.com/w3c/wot-security/pull/89

   Elena: better to see the rendered version?

   [13]Rawgit version

     [13] https://rawgit.com/ereshetova/wot-security/8cda09d2367e657ecf0f4b3993b1396592dd78e7/index.html

   Elena: section 6.3
   ... wanted to updated based on the discussion during f2f
   ... didn't remove the figures
   ... added a new section here
   ... proxy case
   ... we can discuss the terminology
   ... describing the scenario with client via local/remote
   gateways
   ... currently using "remote proxy servient" and "local proxy
   servient" as the terms

   McCool: interesting
   ... non-WoT connection?
   ... reverse proxy and forward proxy
   ... very similar to AWS with device shadows
   ... slightly different
   ... forwarding messages not creating shadow
   ... similar but different
   ... would call this "split proxy"

   Kaz: sounds reasonable but we should ask Fujitsu/Panasonic for
   opinions

   McCool: right
   ... note that quite similar to AWS's shadow proxy
   ... similar pattern
   ... the difference is that the state is maintained by the local
   proxy

   Elena: should we remove "servient" from "remote/local proxy
   servents"?

   McCool: either of them could be a servient or a client
   ... different from HTTP proxy
   ... which is one-directional
   ... this is not wrong
   ... need to clarify entire patterns
   ... tunnel pattern, HTTP proxy pattern, etc.

   Elena: the diagrams look pretty much similar

   McCool: shadow pattern
   ... Koster, do you agree?

   Koster: not sure if that requires local/remote proxies

   McCool: the local proxy here is optional

   Kaz: would agree
   ... the pair of "remote proxy" and "local proxy" is a mechanism
   for tunneling/firewalling

   McCool: we have this pair to hide the information
   ... pretty hard to handle NAT traversal itself

   Elena: only difference would tunneling is...

   McCool: tunneling doesn't know anything about WoT

   Elena: direct communication

   McCool: correct
   ... so local devices are unaware of the Internet side
   ... but it works fine
   ... if you intercept all the possible interaction using proxy
   ... there are pros/cons with proxy approach and tunnel approach
   ... we should create another PR for tunneling

   Elena: yes

   McCool: highly recommended not to use powerpoint for the
   diagram
   ... SVG tool would be better
   ... could reopen issues/pullrequests for the WoT Architecture
   as well

   Elena: and then 6.4 Single-Tenant
   ... interaction ladder diagram and corresponding TD
   ... do we have definition?
   ... how the syntax looks like?

   McCool: what you have is consistent with my syntax
   ... main outcome so far
   ... this is kind of lazy authentication
   ... there is an issue with Scripting API's exposing
   ... reasonable to have something for security configuration
   ... maybe assignment to a number of scripts
   ... have to look into the details of the script

   Elena: you don't know the detail
   ... what syntax is right
   ... what kind of keywords to have

   McCool: this (TD vs sequence) itself is not incorrect

   Elena: would see actual syntax

   McCool: have to review the syntax
   ... your security potion is consistent with my proposal
   ... I'll do one more review

   Elena: would be great if you could a figure for tunneling

   McCool: ok
   ... let's move one

PR 88

   [14]pullrequest 88

     [14] https://github.com/w3c/wot-security/pull/88

   McCool: security metadata
   ... previous proposal presented to the TD TF last Friday
   ... read through authentication schemes

   [15]rendered version

     [15] https://github.com/mmccool/wot-security/blob/c4167cea9a5d21f14e96be7da6a2877ac34ce079/wot-security-metadata.md

   McCool: goes through the TD Example
   ... this example has many definitions
   ... did some substitution
   ... had security for map
   ... changed to this
   ... no security definition
   ... just have [[ security: "basicConfig",]]
   ... equivalent with what we currently have
   ... that is my modified proposal
   ... you can have name definition, etc.
   ... pretty big changes from syntax viewpoint
   ... the other thing
   ... added digest
   ... under "Detailed Specifications of Configurations"
   ... "Digest Authentication" added
   ... under Algorithm
   ... MD5 hashing is not good but used for digest
   ... Obsolete and insecure ciphersuites are be supported for
   compatibility with older services but SHOULD be flagged with
   warnings by a validation system.
   ... also the case
   ... a couple of things about validation
   ... added "digest" to "Protocol-Specific Notes" as well
   ... also updated the References
   ... e.g.,
   [16]https://www.iana.org/assignments/http-authschemes/http-auth
   schemes.xhtml
   ... questions?
   ... alternate syntax?
   ... need further explanation?
   ... can merge this PR so that people can see it

     [16] https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

   Elena: this one should be merged
   ... hard to track the changes...

   McCool: time to merge this
   ... don't be impacted by the change with JSON-LD 1.1
   ... you could leave out the global defaults
   ... a couple of features with pre-processing
   ... but can leave them out
   ... Koster, attended the TD call on Friday?

   Koster: yes

   [17]TD minutes - April 20

     [17] https://www.w3.org/2018/04/20-wot-td-minutes.html

   Koster: security notation separate from JSON-LD
   ... not built-in
   ... but would see examples

   McCool: shows "SecurityDefinitions"


     "securityDefinitions": {
       "basicConfig": {
         "scheme": "basic"
       },
       "ocfConfig": {
         "scheme": "ocf"
       },
       "apikeyConfig": {
         "scheme": "apikey",
         "in": "header"
       }
     },
   ]]

   McCool: these modeling to be substituted in
   ... if we don't mention security at all, security would appear
   by default
   ... or empty array
   ... 2 level of substitution
   ... macro level
   ... or single substitution
   ... let me clean up the proposal and check in
   ... maybe could do some prototyping
   ... the other question
   ... need to write done some requirement
   ... to make the definition not redundant
   ... having a global default would be nice
   ... the only question might be whether it would be complicated
   or not

   Koster: interrupt interaction
   ... API keys as part of the form

   McCool: another good question
   ... what is the purpose of the metadata
   ... how that would help the user
   ... in the case of an IoT device, there might not be a user
   ... you have to provide information beforehand
   ... the other general question
   ... issue tracker
   ... what is the purpose of metadata
   ... instance vs type information
   ... security information is provided as instance information
   ... kind of redundant
   ... what we hav here is
   ... what would be protocol-independent information?
   ... particularly, TD guys would nail done the security
   definition
   ... in particular, for digest
   ... there is encoding for digesting
   ... boils down to what kind of metadata is needed
   ... might forgot something but should be able to get 90% of
   what to do
   ... need to think about all the different parameters and what
   is needed
   ... this would be a good start
   ... so OK with merging this PR for security metadata proposal.
   right?

   (no objections)

next

   McCool: we should be able to close some of the existing issues

   [18]security issues

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

   [adjourned]

Summary of Action Items

   ACTION: [ONGOING] elena to work on issue 68 (Thing Provider
   Data Specification) and issue 69 (Passive Observers Risk)
   ACTION: [ONGOING] mccool to work on issue 70 (Require Not
   Exposing Immutable Hardware Identifiers?)
   ACTION: [ONGOING] elena/koster to work on terminology
   ACTION: [ONGOING] mccool to talk with security guys about
   testing/validation timeline

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [19]scribe.perl version
    1.152 ([20]CVS log)
    $Date: 2018/04/30 14:24:19 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 30 April 2018 14:29:45 UTC