See also: IRC log
elena: not available this time on Friday
mccool: let's create a doodle
kaz: will do
elena: answers of the
questionnaire?
... we can walk through the results
mccool: ok
kaz: btw, Sebastian mentioned he
wanted one more week before the review for TD doc
... he repeated that view today during the TD call today
mccool: updates the agenda wiki
mccool: created a branch for TD
... can generate a pullrequest
... the issue is there is some portion about security within
the current TD doc
... but not ready for review yet
... but we can review the current version briefly
mccool: there is a security section but very brief
elena: some more description in the Current Practices document
mccool: right
... what to for then?
... the question is what is the minimal thing we need to
do?
... also not sure about the all the security options
elena: what is important is
backtracking the model
... security requirements for TD
... concrete measure
... options for security
... optional vs mandatory
... privacy, security
... why/when to use
mccool: what situation requires you
to use
... how to organize this task?
... what kind of structure?
elena: explain to people why security is needed for TD
mccool: thread model document
... need different level of publication
... we could create a wiki page
kaz: wiki, md or whatever
mccool: standard document
... 4. vocabulary definition
... TD model has security portion
... but quite empty
... also the vocabulary sections are automatically generated
based on some ontology
... so we should not edit the section 4 directly
... there is another security section "4.2.8 Security"
... also "5.3 Security"
... this is for serialization, e.g., JSON-LD
... and section "6. Security" is empty
... TD TF wanted us for review
... let's think about outline
kaz: several viewpoints, e.g., author, developer, user?
mccool: issue with the
structure
... and security mechanism
mccool: talked with several
people
... protocols to map to
... CoAP, MQTT, HTTP/HTTPS
... Amazon started security on WebSocket
... (updates the Security section on his branch)
... the threat model has two assets: TD itself and the
resources that can be accessed via the TD
... risks: adversaries and prioritized threats
... General: that we "do no
harm": security of described protocols should be maintained.
Don't introduce new security mechanisms, but do prederve
functionality of existing mechanisms
... Exposing: when exposing a TD, especially via the Scripting
API, itshould be possible to use best practices for
security
... Consuming: a consumed TD should accurately reflect the
actual security status of a target device
... Protocols: we will prioritize the following protocols:
HTTP(S), CoAP(S)
... Recommended Practices
... secure delivery and storage of TD
... implement an access control mechnism for the TD
... use of secure transports
... use CoAPS and HTTPS rather tna CoAP and HTTP whenever
possible
... maintaining privacy
... avoid exposing personally indentifiable information in a
TD
... avoid exposing an immutable hardware identifier
... APIs should only provide the functionality necessary, and
no more
... devices should be strongly encapsulated
... consider different levels of access for different
users
... (will create a branch on McCool's branch)
elena: can add some more edit as well
mccool: we should concentrate on the security section
<McCool> https://github.com/mmccool/wot-thing-description
mccool: quickly review the
results
... anything missing, Koster?
koster: no specific suggestions at the moment
kaz: can we see the results at some URL?
elena: can create a snapshot and let
you all know
... (goes through the results)
... [What are the typical high-level WoT use cases/scenarios
when privacy might be at risk?
mccool: separate sections for
security and privacy?
... would be better to have two separate sections
elena: [What identifieres (device, thing, user, etc.) do the WoT define in the TD or other places?
mccool: potentially use some ID
... identifiers pointing software objects
... destroy things we created
... disconnected with the hardware itself
... stable identifiers are used during the lifecycle
... after that, the identifiers go away
... name field and id field
... URL field
... we can change them
... but vendor information, etc., should be protected
... sensitive information
elena: vendor id itself is not about the hardware?
mccool: which device it is
... you can talk with the driver
... recommend we should not include vendor ID if
sensitive
... industry environment would make sense
... let's add some recommendations to the security
section
... semantic information on the device
... what's the least?
elena: ok
... and we asked about the purpose
... [What is their purpose (why can they not be omitted)?
mccool: the last person mentions that
without id it's impossible to communicate
... Elena, please create a PDF version of the results and share
it with the group
elena: ok
mccool: we'll do a doodle poll for the upcoming calls
[ adjourned ]