- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 12 Jun 2018 19:01:01 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2018/06/04-wot-sec-minutes.html also as text below. Thanks a lot for taking these minutes, Michael Koster! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT Security 04 Jun 2018 Attendees Present Kaz_Ashimura, Michael_McCool, Elena_Reshetova, Kazuaki_Nimura, Michael_Koster, Tomoaki_Mizushima Regrets Chair McCool Scribe mjkoster, kaz Contents * [2]Topics 1. [3]Agenda review 2. [4]Review previous minutes 3. [5]Security metadata PR 4. [6]Follow up on the issue of how security metadata is used in TD 5. [7]PR #103 6. [8]Security for the next plugfest 7. [9]Actions * [10]Summary of Action Items * [11]Summary of Resolutions __________________________________________________________ <kaz> scribenick: mjkoster Agenda review McCool: goes through the [12]agenda [12] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda review previous minutes <kaz> [13]prev minutes [13] https://www.w3.org/2018/05/28-wot-sec-minutes.html <kaz> explanation on Linux Security Summit should be added (conflict with TPAC and Elena can't join TPAC) McCool: more explanation is needed in section discussion TPAC conflict ... remove mention of OASIS <McCool> mccool: change "one way is Oasis" to "I just have to follow the internal Intel processes" McCool: minutes accepted except the above tweaks Security metadata PR <kaz> [14]PR 144 [14] https://github.com/w3c/wot-thing-description/pull/144 #144 McCool: comments about OCF security scheme ... removed OCF from the core vocabulary, but the security vocabulary needs to be more open ended ... can we use a custom extension on security vocabulary? Koster: this is what I meant by extension points needed for both security and forms McCool: need to explore how to include these as extensions to the core vocabulary ... review individual updates, http diff <kaz> [15]HTML diff [15] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html McCool: the main change is in the security section of the TD document ... want to change from URI to URL <kaz> [16]5.4 Security Vocabulary Definition [16] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html#sec-security-vocabulary-definition McCool: removed ocf as a scheme ... oauth and bearer are separate schemes, oauth implies bearer pattern and doesn't need to include the term "bearer" with oauth ... took out the security definitions section ... now the security in lower level constructs will over-ride the definitions in higher level constructs ... examples in the document of over-ride behavior ... same levels, different levels, multiple schemes examples ... multiple schemes at the same instance provide a choice of schemes ... in other words the "or" pattern ... removes security definitions for links ... mechanism for adding a scheme from an external vocabulary ... one issue is that a lot of the terms are defined as strings but should be enumeration types ... more constraints would be good for validation ... how are the constraints applied from external namespaces? ... need a way to add values which makes the validation harder ... its a general problem ... has anyone else reviewed? Elena: have started reviewing McCool: is it ready to include in the editors draft? ... any objections to merging with the TD master branch Elena: what about the security and privacy consideration section? McCool: some fixed needed ... will do a few more changes and extend the example to show "or" pattern ... need to draft a section for the TD document, after the plugfest ... any other changes needed? ... OK, will make these changes and merge Follow up on the issue of how security metadata is used in TD McCool: to know what the pre-requisites are for accessing a thing ... sometimes the metadata are exposed in the protocol ... exposing in TD enables developers to plan in advance ... however there is a tension between class and instance TDs ... security metadata makes more sense in a class TD, and ties into class templates <inserted> scribenick: kaz Koster: all of the information put into the TD could be sort of links/hypermedia ... maybe annotations of different levels ... a class template might make sense ... also pre-qualified things ... another stage of filtering ... to choose appropriate security mechanism ... more granular hypermedia mechanism ... there are bunch of differences ... there might be a way of discovery dynamically McCool: many choices among access points <inserted> scribenick: mjkoster McCool: the optimization of having it all in one place may be substantial ... being able to plan ahead <inserted> scribenick: kaz Koster: do we need a definition section? ... would see use cases ... going to build a client ... and consider how to use security ... not sure at the moment MkCool: typed in a bunch of stuff ... 3 levels of things relevant here ... what include in core vocabulary, etc. ... 3 protocols which matter: HTTP, CoAP and MQTT <inserted> scribenick: mjkoster McCool: protocols that matter are http, coap, and mqtt ... what are the choices in schemes for these different protocols? ... http has a lot of choices, but maybe CoAP and MQTT are more limited to a fixed set of schemes ... MQTT has basic ... CoAP has DTLS ... what about object security? ... so things that have choice should be included, things that are accepted standards should be included ... the schemes and options we have are probably good enough PR #103 McCool: please review for discussion at the next meeting <kaz> [17]PR 103 [17] https://github.com/w3c/wot-security/pull/103 Security for the next plugfest <kaz> [18]McCool's slides [18] https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/Security-Bundang-PlugFest-Preparation.pptx McCool: would like to get to a set of concrete objectives ... get everyone to use security as a standard practice ... maybe starting with TLS ... online access to things will drive secure implementations ... focus on basic, digest, and bearer style auth ... protection of a thing directory API, using auth ... there is an npm option that was effective in resolving many of hte issues in node-wot by updating packages ... recommended practices, where should this go? Actions McCool: finish PR and merge it ... tools to use ... other ongoing actions from the last minutes ... just the one new action on the PR integration ... meeting adjourned Summary of Action Items [ONGOING] ACTION: mccool to talk with security guys about testing/validation timeline [ONGOING] ACTION: mccool to work on issue 70 (Require Not Exposing Immutable Hardware Identifiers?) [ONGOING] ACTION: mjkoster/elena to review examples in the security spec [ONGOING] ACTION: mccool to write a short proposal on what security tools to use for the next plugfest [NEW] ACTION: mccool to finish TD PR 144 (Security metadata) and merge it Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [19]scribe.perl version 1.152 ([20]CVS log) $Date: 2018/06/12 09:55:56 $ [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 12 June 2018 10:02:12 UTC