- 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