- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 25 Apr 2018 18:22:12 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
https://www.w3.org/2018/04/16-wot-sec-minutes.html
also as text below.
Thanks a lot for taking these minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Security
16 Apr 2018
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
Michael_Koster, Michael_Lagally, Zoltan_Kis,
Kazuaki_Nimura, Tomoaki_Mizushima
Regrets
Chair
McCool
Scribe
zkis
Contents
* [3]Topics
1. [4]last meeting's minutes
2. [5]ER's question about Section 6 of Security and
Privacy doc
3. [6]security metadata proposal
4. [7]issues raised by Jason Novak
o [8]issue #72
o [9]issue #71
o [10]issue #70
o [11]issue #69
o [12]issue #68
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: zkis
McCool: sharing status about issues wrt changes to the Security
Considerations
last meeting's minutes
<kaz> [15]prev minutes
[15] https://www.w3.org/2018/04/09-wot-sec-minutes.html
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]/
ER's question about Section 6 of Security and Privacy doc
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>
[16]https://github.com/w3c/wot/blob/master/plugfest/2018-prague
/preparation.md#user-content-21-4-layered-servients
[16] https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation.md#user-content-21-4-layered-servients
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> [17]wot-architecture repo
[17] https://github.com/w3c/wot-architecture
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> [18]PlugFest Summary slides
[18] https://github.com/w3c/wot/blob/master/plugfest/2018-prague/docs/PlugfestSummary180326a.pdf
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
security metadata proposal
PR #88
<kaz> [19]wot-security pullrequest 88
[19] https://github.com/w3c/wot-security/pull/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
issues raised by Jason Novak
* issue #72
McCool: replied quickly to each
issue #72: fingerprinting risks
<kaz> [20]issue 72
[20] https://github.com/w3c/wot-security/issues/72
McCool: access rights for discovery
* issue #71
issue #71: Thing Directory privacy risks (handing over
information to a service)
<kaz> [21]issue 71
[21] https://github.com/w3c/wot-security/issues/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_
* issue #70
<kaz> [22]issue 70
[22] https://github.com/w3c/wot-security/issues/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
* issue #69
<kaz> [23]issue 69
[23] https://github.com/w3c/wot-security/issues/69
Elena: can make a small change to address this
* issue #68
<kaz> [24]issue 68
[24] https://github.com/w3c/wot-security/issues/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]
Summary of Action Items
[NEW] ACTION: elena to work on [25]issue 68 (Thing Provider
Data Specification) and [26]issue 69 (Passive Observers Risk)
[NEW] ACTION: mccool to work on [27]issue 70 (Require Not
Exposing Immutable Hardware Identifiers?)
[NEW] ACTION: elena/koster to work on terminology
[ONGOING] ACTION: mccool to talk with security guys about
testing/validation timeline
[25] https://github.com/w3c/wot-security/issues/68
[26] https://github.com/w3c/wot-security/issues/69
[27] https://github.com/w3c/wot-security/issues/70
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.152 ([29]CVS log)
$Date: 2018/04/25 09:16:57 $
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 25 April 2018 09:23:23 UTC