<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