See also: IRC log
<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: 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> TPAC page
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> 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