new slot for the call

elena: not available this time on Friday

mccool: let's create a doodle

kaz: will do

agenda

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

TD Review

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

TD draft

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's branch

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

Threat model questionnaire

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 ]