[wot-security] minutes - 23 July 2018

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

also as text below.

Thanks,

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                              WoT Security

23 Jul 2018

   [2]Agenda

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

Attendees

   Present
          Kaz_Ashimura, Elena_Reshetova, Michael_McCool,
          Tomoaki_Mizushima, Kazuaki_Nimura

   Regrets

   Chair
          McCool

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]Agenda
         2. [5]prev minutes
         3. [6]plugfest/f2f recap
         4. [7]PR 107
         5. [8]Security Definitions
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

Agenda

   McCool: updates the agenda

   [11]agenda

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

prev minutes

   [12]prev minutes

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

   McCool: (goes through the minutes from Jun 25th)
   ... plugfest prep and bunch of issues
   ... pr 104 merged
   ... good idea to visit the issues again
   ... ongoing actions
   ... we can update the action on testing
   ... to be changed to mccool to write test spec for security
   ... the action item for not June 25 but today's minutes

   <McCool> first action to be updated to "mccool to write
   security testing specification as part of overall test plan
   document"

   McCool: any other changes?

   (none)

   McCool: the minutes from June 25 meeting accepted

plugfest/f2f recap

   McCool: given the participation today, let's skip this
   ... discussion for next week
   ... everybody here attended or called in

PR 107

   [13]pr 107

     [13] https://github.com/w3c/wot-security/pull/107

   Elena: (shares her screen)
   ... many structural changes

   [14]changes

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

   Elena: would like to go over the document
   ... [2. Lifecycle of a WoT device]

   McCool: let's discuss lifecycle during the main call
   ... it's related to TD discusison

   Elena: ok
   ... (goes through section 3)
   ... system owner
   ... propose to drop this notion (=editor's note)
   ... about "Consider adding System Owner"
   ... we have 3 main stakeholders

   McCool: any of the stakeholders could be a maintainer
   ... may be one of the existing stakeholders or possibly an
   employed one
   ... we have actors and roles
   ... the confusion is some of the actors can take additional
   roles
   ... we should add a note that maintainer role could be added to
   the existing actors
   ... the comment in the editor's note kind of make sense
   ... may or may not apply
   ... it may be system owner but may not be
   ... the only case it matters would be hiring a third party
   ... you can reuse the current text

   Elena: ok
   ... editors note on Links

   McCool: relationship may reveal privacy information

   Elena: at some point we had discussion about links
   ... but we don't have any more

   McCool: we need to have more discussion under privacy

   Elena: ok
   ... [3.2.6 Threats]
   ... editor's note: protocol bindings as system provider data

   McCool: what are our categories of data?

   Elena: system provider and system user
   ... the table includes WoT Protocol Binding Threat

   McCool: data providers and OEMs
   ... protocol binding to be under system provider data
   ... what's the definition of "System Provider Data"?
   ... inclusive of OEM data?

   Elena: building on top of hardware
   ... an OEM might be a system provider as well

   McCool: protocol bindings can be owned by anybody
   ... multiple vendors could contribute to one single system

   Elena: [3.3 Security Objectives]
   ... took mitigation out
   ... 3 different scenarios here
   ... [3.4 Determining a suitable security architecture]

   McCool: ok
   ... mitigation should belong to somewhere, though

   Elena: [4. Privacy considerations]
   ... privacy is not touched
   ... [6. Recommended Security Practices and Mitigations]
   ... rewrote the section
   ... secure practices for designing a TD
   ... security level, security storage
   ... people can read after
   ... practices for security
   ... best practices for end-to-end security
   ... how to design
   ... still many placeholders
   ... privacy or security threats?
   ... those were what I did

   McCool: ok
   ... would like to go through later
   ... do some update and send to the group list to ask for review
   ... next round for recommendations

   Nimura: fig 11
   ... still included?

   Elena: (shows fig 11)

   Nimura: separate security metadata
   ... want to change some
   ... it has "Generic Servient Security metadata"
   ... but it's not separately defined

   Elena: not a separate description

   Nimura: kind of confusing

   Elena: how to rename?

   McCool: "provision security data"

   Elena: ok

   McCool: any more questions/comments?

   (none)

   McCool: will review the document next time in detail
   ... meanwhile, you can add changes, Elena

   Elena: ok

Security Definitions

   <McCool>
   [15]https://github.com/w3c/wot-security/blob/master/presentatio
   ns/W3C%20WoT%20Security%20Definitions%20Proposal.pdf

     [15] https://github.com/w3c/wot-security/blob/master/presentations/W3C
WoT Security Definitions Proposal.pdf

   McCool: did present to the TD TF last Friday
   ... main concern is feasibility for implementations
   ... need to talk with Victor, etc.
   ... to check implementability
   ... [Outline]
   ... review of current TD security metadata status
   ... security definition proposal
   ... discussion
   ... [Issues Identified]
   ... redundancy
   ... overrides are not always appropriate
   ... mandatory security configuration desirable
   ... [Proposal: Security Definitions]
   ... new map object at the top level (SecurityDefinitions)
   ... map between strings and security configuration objects
   ... named object
   ... strings could be used in place of security configuration
   objects in security definitions
   ... [Example 1]
   ... (shows an example)
   ... semantically equivalent
   ... [Example 2]
   ... if you don't have the last line
   ... "security": ["proxydigest", "bearer"],
   ... it wouldn't work
   ... [Example 3]
   ... easily implementable
   ... but possible problem
   ... name conflict
   ... should be unique
   ... e.g., "basic"
   ... also
   ... would like to know what security form would be applied
   ... [Empty and Mandatory...]
   ... seems to be OK
   ... having "no security" by default seems to set a bad
   precedent
   ... mandatory security
   ... would be good
   ... concern is how we can validate the case of no security
   ... having hidden default
   ... undefined security would cause an error?
   ... would like to add a scheme "none" to indicate no security
   ... and make "security" tag mandatory
   ... that is the current proposal and need more work

   [adjourned]

Summary of Action Items

   [DONE] ACTION: mccool to write security testing specification
   as part of overall test plan document
   [ONGOING] ACTION: mccool to talk with IIC Security TF and W3C
   Web Security IG about testing/validation timeline (first item
   tbd; second item done)
   [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 look into URI templates (RFC6570)
   for issue 98
   [NEW] ACTION: mcCool to write PR on TD spec for security
   definition

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [16]scribe.perl version
    1.152 ([17]CVS log)
    $Date: 2018/07/31 05:49:42 $

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

Received on Tuesday, 31 July 2018 06:05:28 UTC