<kaz> scribenick: zkis
McCool: sharing status about issues wrt changes to the Security Considerations
<kaz> prev minutes
McCool reviews action points from last meeting
McCool: propose to add details to
the actions raised by Barry
... proposed accepting the minutes.
<kaz> add the follwoing action items:
* action for barry to provide information on 2 new IETF WGs
* action for mccool to talk about testing validation timeline with security guys)
[except those 2 additional actions, the minutes have been accepted]/
Elena: add topologies present in the
plugfest
... each topology looks like application server and 2 proxies:
remote and local
... they are actually gateways
McCool: the diagram is
misleading
... some proxies were just tunnels
... some proxies were really proxies (e.g. Fujitsu)
... in this diagram they should be labeled differently
Elena: there is a terminology issue,
it still looks like a WoT gateway
... not a network proxy per se
McCool: a proxy is that forges a
request to the external network
... the tunnel will forward everything without understanding
it
... one difference is that proxies will have their own security
interfaces
... e.g. a remote proxy may expose HTTP, translating the
protocol
Zoltan: these could be also called gateways
Elena: confused about what nodes are WoT related
McCool: yes, more careful terminology is needed - we should check with each implementation
Kaz: explains proxy servient, device servient and application servient
Elena: showing a picture about her
understanding (from the security document) - speaking about WoT
client and Wot Server, WoT remote proxy and local proxy
... why do we need remote and local proxies
McCool: the connection between the remote and local proxies may be a 3rd protocol
Elena: that explains
McCool: logically there is one servient.
Elena: we assume the connection between remote and local proxies is secure
McCool: yes
Elena: why local proxy is not exposed (to be connected to directly)
McCool: local proxy may not be
exposed externally
... in practice a local proxy will call out to a cloud server
and create the channel
Elena: now understood, and will
redraw the picture
... another question. Do we ever have a scenario with client,
servient behind NAT proxy
... do we have generic proxies as well (e.g. HTTP proxy)
McCool: this picture look like STUN
Elena: what was meant was 2 boxes: a HTTP proxy and a WoT proxy
McCool: in theory an HTTP proxy will
work (if the underlying protocol is HTTP)
... but will not work if under there is CoAP
Elena: wondering what the proper description would be
McCool: we do have the scenario with
HTTP - proxy - CoAP in the plugfest
... ask Siemens for clarifications about this setup
... as a concept it works, but not aware about implementation
(so ask Siemens)
Elena: it would be nice to track the topologies used in plugfests
McCool: well, there is 1) simple tunneling, 2.) proxy for WoT, 3.) HTTP proxy (not specific to Things), 4.) gateway (protocol translation)
McCool: just define terminology and use it consistently
Elena: this would be beneficial not only in the Security document - there is so much overlap
McCool: define them in the Architecture document
Zoltan: just treat these as labels for roles implemented in the proxy
Elena: there is enough input now, but we should consolidate the use of the terms
McCool: create an issue at the
architecture repository
... also bring it up in the main call
<kaz> wot-architecture repo
McCool: should use distinct terms
for the 4 scenarios listed earlier
... for identifying security implications the definitions
should be very clear
Elena: it would be better to create the scenarios in the architecture and just add security considerations on the top
McCool: until the architecture doc is fixed, we should document the scenarios locally in security and refer to them
Elena: by next call will make a
PR
... but someone else should define the terms
McCool: who feels confident to pick the right terms. Michael Koster?
Koster: will help
ER will collaborate with MK on this
McCool: should kick off the discussion in the main call
<kaz> PlugFest Summary slides
Kaz: which diagrams should be used
for the security discussion, the one from the Burlingame
plugfest, or the current
... we should update the latest diagram on the top of the
Burlingame diagram
McCool: we should agree about the terms and update the diagrams
PR #88
<kaz> wot-security pullrequest 88
McCool: examples updated with the
new TD style
... since the TD spec is moving, they will still need to be
updated
McCool: can we use dashes in the property names in security metadata (JSON-LD 1.1)?
Koster: probably yes
McCool: using Bearer Tokens
now
... changed proxy to proxyUrl etc (similar changes)
... since OpenAPI does them this way
... another change was using "scope" again, added "pop", added
"pop+https", "pop+coap"
... should discuss in TD meeting to discuss the "method"
definition
... also, should discuss the final shape of "properties"
... also, during the F2F security roles were discuss - decided
it was too complex
... a possibility is to use named group configurations
... these should be transparent
... need to check with the TD TF if this is fine
... one problem is the definitions may depend on the
protocol
... may need to be specialized for HTTP or CoAP
... should separate security related definitions in a separate
file
... to be discussed with the TD TF
McCool: replied quickly to each
issue #72: fingerprinting risks
<kaz> issue 72
McCool: access rights for discovery
issue #71: Thing Directory privacy risks (handing over information to a service)
<kaz> issue 71
McCool: there can be a malicious
Thing Directory, or a sloppy one
... TD's should specify to scope of information for a Thing
Directory
... but in Scripting we could have that scope
Elena: we have not discussed Thing Directory yet
Zoltan: Thing Directory is currently an application
McCool: yes, it is currently out of scope, but still is a privacy risk
Zoltan: doesn't the responsibility fall to the solution provider that implements Thing Directory?
McCool: the Scripting API does have a way to expose and discover Things; should it include meta-information about the scope of the data?
Zoltan: Scripting cannot support it if TD does not support it
McCool: it pertains to how the TD's are _distributed_
<kaz> issue 70
McCool: Not sure we can require not
exposing immutable HW id's
... kind of out of scope
... we can strongly recommend it, but we can't require it
Elena: security is non-normative anyway
McCool: the TD TF should consider
this
... the question is who is going to validate it
<kaz> issue 69
Elena: can make a small change to address this
<kaz> issue 68
Elena: can clarify in the document
McCool: the main point is the provider data needs to be protected
Elena: clarify who is the owner (user or provider)
McCool: we stop here
... we will take care and handle these issues
... will assign the issues
<kaz> [adjourned]