- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 23 Jun 2017 22:28:20 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2017/06/23-wot-sec-minutes.html also as text below. Thanks a lot for taking these minutes, Michael McCool! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT IG - Security 23 Jun 2017 [2]Agenda [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda See also: [3]IRC log [3] http://www.w3.org/2017/06/23-wot-sec-irc Attendees Present Kaz_Ashimura, Dave_Raggett, Elena_Reshetova, Michael_Koster, Michael_McCool, Oliver_Pfaff, Daniel_Ibaseta Regrets Chair McCool Scribe McCool Contents * [4]Topics * [5]Summary of Action Items * [6]Summary of Resolutions __________________________________________________________ <kaz> scribenick: McCool privacy questionnaire - placeholder document, Elena tried to fill out, ran into problems for instance: unique identifiers? however, let's also talk about our agenda threat model: not in its end state how do we get others to review, get closure on it? mccool suggestion: get a representative subset to review it <kaz> [ kaz wonders if the resource on RFC6973 is: [7]https://tools.ietf.org/html/rfc6973] [7] https://tools.ietf.org/html/rfc6973 get internal reviewers through it first, then look at external review there is a w3c security group as well: and they are required to review anyway we should plan to have some kind of report out at TPAC in November (our fall F2F) <kaz> [8]TPAC page [8] https://www.w3.org/2017/11/TPAC/schedule.html what are our deliverables? threat model; security architecture (high level description of main concepts; levels; requirements; measures) at f2f, let's discuss whether we should have an official white paper but, normally don't do that in W3C; from W3C process viewpoint, our deliverables are "grope Note", "WD", "Recommendation", etc. we should discuss in chair and main call dsr: it would be a "note", since it is informative McCool: my opinion is that an official document will get more serious reviews <inserted> kaz: question on the resource for RFC6973. is the following link the right one? <kaz> [9]https://tools.ietf.org/html/rfc6973 [9] https://tools.ietf.org/html/rfc6973 elena: section 7: guidelines is the "questionnaire" McCool: another major deliverable: recommendations to each TF but... before that, need to study each of the protocols we are supporting, and understand all the related work need an organized study McCool: suggest we think about and make our own "questionnaire" for ourselves before we look at each protocol then we know what to look for for example, for each protocol, we want to know how data is protected, how authorization and identification is handled, how each of the threats we identified is mitigated if no more questions... let's go through the privacy questionnaire privacy: unique identifier? TD for F2F is released... we should go through it now. Should see how these questions. Koster: the TD group is willing to look at whether the TD should be a flat file or can be broken up mccool: breaking it up would have advantages for privacy, you would only have to expose a subset ... think this can fit into existing structure Koster: we may HAVE to break it up for protocol bindings depending on the serialization eg an XML format using a JSON template or vice-versa <kaz> +1 to Koster's view mcCool: three categoires: TD metadata; list of interactions; data returned by interactions Elena: mostly td; maybe also discovery protocol Dave: relates to metadata and semantics discussion in TD ... rather than focusing on protocol, think about the data ... simple JSON model; more sophisticated RDF models, etc. ... will be hard to do location in our group, for instance; need to depend on outside standards McCool: we need to discuss in depth, many issues Dave: access control was discussed in IG ... for discovery task force Elena: was there documentation for that? Kaz: Discovery TF was stalled... maybe should rebuild McCool: maybe should consider putting basic access controls for TD in scope Dave: we need to look at requirements, consider modularity issue again Koster: need to consider different contexts: local T2T; cloud services, distributed services (edge/fog), McCool: also person-to-thing, person-to-person Koster: want to control what information gets exposed to who, i.e. energy usage to electrictiy company, but not other information Elena: it would be good to get some use cases written down Koster: look at functional relationships rather than surveillance opportunities McCool: (checks the speaker queue) <Zakim> kaz, you wanted to mention the discussion on the structure of TD is related to Kajimoto-san's @include idea scribenick: kaz Kaz: the discussion on the structure of TD (e.g., monolithic vs modularized) is related to Kajimoto-san's @include idea, so we should think about that as well. scribenick: McCool looking at questionnaire... quick survey, we will have to go into more depth later retention: relates to lifecycle, mechanisms to "clear" devices Koster: user control, control over sharing: granularity matters here ... again the modularity and the ability to hide information; probably important to manage safe interactions ... can we compartmentalize information? Elena: security section is similar to the threats we have looked at already ... stored data is new: privacy implications for what data is stored McCool: an example is that certificates might reveal what companies you have a relationship with adjourn Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [10]scribe.perl version 1.152 ([11]CVS log) $Date: 2017/06/23 13:19:33 $ [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [11] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 23 June 2017 13:29:35 UTC