- 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:37 UTC