Agenda

McCool: updates the agenda

agenda

prev minutes

prev minutes

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

pr 107

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

changes

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> https://github.com/w3c/wot-security/blob/master/presentations/W3C%20WoT%20Security%20Definitions%20Proposal.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]