- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 30 Apr 2018 23:28:32 +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/23-wot-sec-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT Security 23 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, Barry_Leiba, Michael_Lagally Regrets Kazuaki_Nimura Chair McCool Scribe kaz Contents * [3]Topics 1. [4]prev minutes 2. [5]PR 89 3. [6]PR 88 4. [7]next * [8]Summary of Action Items * [9]Summary of Resolutions __________________________________________________________ [10]scripting issue 111 [10] https://github.com/w3c/wot-scripting-api/issues/111 [11]prev minutes [11] https://www.w3.org/2018/04/16-wot-sec-minutes.html prev minutes McCool: should add action items ... issue 69 for elena and issue 68 as well ... issue 70 for mccool ... terminology for elena/koster ... old action for mccool to talk about testing validation also ... other than those actions, would accept the minutes (no objections) PR 89 [12]pullrequest 89 [12] https://github.com/w3c/wot-security/pull/89 Elena: better to see the rendered version? [13]Rawgit version [13] https://rawgit.com/ereshetova/wot-security/8cda09d2367e657ecf0f4b3993b1396592dd78e7/index.html Elena: section 6.3 ... wanted to updated based on the discussion during f2f ... didn't remove the figures ... added a new section here ... proxy case ... we can discuss the terminology ... describing the scenario with client via local/remote gateways ... currently using "remote proxy servient" and "local proxy servient" as the terms McCool: interesting ... non-WoT connection? ... reverse proxy and forward proxy ... very similar to AWS with device shadows ... slightly different ... forwarding messages not creating shadow ... similar but different ... would call this "split proxy" Kaz: sounds reasonable but we should ask Fujitsu/Panasonic for opinions McCool: right ... note that quite similar to AWS's shadow proxy ... similar pattern ... the difference is that the state is maintained by the local proxy Elena: should we remove "servient" from "remote/local proxy servents"? McCool: either of them could be a servient or a client ... different from HTTP proxy ... which is one-directional ... this is not wrong ... need to clarify entire patterns ... tunnel pattern, HTTP proxy pattern, etc. Elena: the diagrams look pretty much similar McCool: shadow pattern ... Koster, do you agree? Koster: not sure if that requires local/remote proxies McCool: the local proxy here is optional Kaz: would agree ... the pair of "remote proxy" and "local proxy" is a mechanism for tunneling/firewalling McCool: we have this pair to hide the information ... pretty hard to handle NAT traversal itself Elena: only difference would tunneling is... McCool: tunneling doesn't know anything about WoT Elena: direct communication McCool: correct ... so local devices are unaware of the Internet side ... but it works fine ... if you intercept all the possible interaction using proxy ... there are pros/cons with proxy approach and tunnel approach ... we should create another PR for tunneling Elena: yes McCool: highly recommended not to use powerpoint for the diagram ... SVG tool would be better ... could reopen issues/pullrequests for the WoT Architecture as well Elena: and then 6.4 Single-Tenant ... interaction ladder diagram and corresponding TD ... do we have definition? ... how the syntax looks like? McCool: what you have is consistent with my syntax ... main outcome so far ... this is kind of lazy authentication ... there is an issue with Scripting API's exposing ... reasonable to have something for security configuration ... maybe assignment to a number of scripts ... have to look into the details of the script Elena: you don't know the detail ... what syntax is right ... what kind of keywords to have McCool: this (TD vs sequence) itself is not incorrect Elena: would see actual syntax McCool: have to review the syntax ... your security potion is consistent with my proposal ... I'll do one more review Elena: would be great if you could a figure for tunneling McCool: ok ... let's move one PR 88 [14]pullrequest 88 [14] https://github.com/w3c/wot-security/pull/88 McCool: security metadata ... previous proposal presented to the TD TF last Friday ... read through authentication schemes [15]rendered version [15] https://github.com/mmccool/wot-security/blob/c4167cea9a5d21f14e96be7da6a2877ac34ce079/wot-security-metadata.md McCool: goes through the TD Example ... this example has many definitions ... did some substitution ... had security for map ... changed to this ... no security definition ... just have [[ security: "basicConfig",]] ... equivalent with what we currently have ... that is my modified proposal ... you can have name definition, etc. ... pretty big changes from syntax viewpoint ... the other thing ... added digest ... under "Detailed Specifications of Configurations" ... "Digest Authentication" added ... under Algorithm ... MD5 hashing is not good but used for digest ... Obsolete and insecure ciphersuites are be supported for compatibility with older services but SHOULD be flagged with warnings by a validation system. ... also the case ... a couple of things about validation ... added "digest" to "Protocol-Specific Notes" as well ... also updated the References ... e.g., [16]https://www.iana.org/assignments/http-authschemes/http-auth schemes.xhtml ... questions? ... alternate syntax? ... need further explanation? ... can merge this PR so that people can see it [16] https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml Elena: this one should be merged ... hard to track the changes... McCool: time to merge this ... don't be impacted by the change with JSON-LD 1.1 ... you could leave out the global defaults ... a couple of features with pre-processing ... but can leave them out ... Koster, attended the TD call on Friday? Koster: yes [17]TD minutes - April 20 [17] https://www.w3.org/2018/04/20-wot-td-minutes.html Koster: security notation separate from JSON-LD ... not built-in ... but would see examples McCool: shows "SecurityDefinitions" "securityDefinitions": { "basicConfig": { "scheme": "basic" }, "ocfConfig": { "scheme": "ocf" }, "apikeyConfig": { "scheme": "apikey", "in": "header" } }, ]] McCool: these modeling to be substituted in ... if we don't mention security at all, security would appear by default ... or empty array ... 2 level of substitution ... macro level ... or single substitution ... let me clean up the proposal and check in ... maybe could do some prototyping ... the other question ... need to write done some requirement ... to make the definition not redundant ... having a global default would be nice ... the only question might be whether it would be complicated or not Koster: interrupt interaction ... API keys as part of the form McCool: another good question ... what is the purpose of the metadata ... how that would help the user ... in the case of an IoT device, there might not be a user ... you have to provide information beforehand ... the other general question ... issue tracker ... what is the purpose of metadata ... instance vs type information ... security information is provided as instance information ... kind of redundant ... what we hav here is ... what would be protocol-independent information? ... particularly, TD guys would nail done the security definition ... in particular, for digest ... there is encoding for digesting ... boils down to what kind of metadata is needed ... might forgot something but should be able to get 90% of what to do ... need to think about all the different parameters and what is needed ... this would be a good start ... so OK with merging this PR for security metadata proposal. right? (no objections) next McCool: we should be able to close some of the existing issues [18]security issues [18] https://github.com/w3c/wot-security/issues [adjourned] Summary of Action Items ACTION: [ONGOING] elena to work on issue 68 (Thing Provider Data Specification) and issue 69 (Passive Observers Risk) ACTION: [ONGOING] mccool to work on issue 70 (Require Not Exposing Immutable Hardware Identifiers?) ACTION: [ONGOING] elena/koster to work on terminology ACTION: [ONGOING] mccool to talk with security guys about testing/validation timeline Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [19]scribe.perl version 1.152 ([20]CVS log) $Date: 2018/04/30 14:24:19 $ [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 30 April 2018 14:29:44 UTC