McCool: updates the agenda
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
McCool: given the participation
today, let's skip this
... discussion for next week
... everybody here attended or called in
Elena: (shares her screen)
... many structural 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
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]