<kaz> scribenick: mjkoster

Prev minutes

<kaz> prev minutes

<kaz> (several typos: s/tak/talk/; s/pare/pair/;)

<kaz> leftover actions:

<kaz> ACTION: [ONGOING] elena to work on issue 68 (Thing Provider Data Specification) and issue 69 (Passive Observers Risk)

<kaz> ACTION: [ONGOING] mccool to work on issue 70 (Require Not Exposing Immutable Hardware Identifiers?)

<kaz> ACTION: [ONGOING] elena/koster to work on terminology

<kaz> ACTION: [ONGOING] mccool to talk with security guys about testing/validation timeline

McCool: accept the minutes

<kaz> (other than the typos and the leftover actions)

McCool: any objections?

<kaz> (none)

Life cycle transition

Zoltan: we need a mechanism by which the consumed thing application gets notified when the exposed thing is destroyed

McCool: can a management thing have en event?

Zoltan: it needs to tell which object is signalled
... simpler to have the object signal itself

McCool: so, a set of standard events

Zoltan: how does OCF work?
... can observe the /oic/res

McCool: standard APIs for components in the architecture
... network API for runtime using a management thing

Zoltan: how does the script get the signal?

McCool: change of state signal would also cover the unexpected loss of a thing
... not sure what the security implications would be

(discussion on TD life cycle management interface)

McCool: seems incomplete without a TD state change mechanism exposed

Zoltan: we can implement this with TD monitoring
... will create an issue

Review PRs

McCool: PR 90, 91, and 92

* PR #90

Elena: start with PR #90
... 3 issues addressed in this PR
... clarification on what is meant by System User Data
... clarified what is meant by System Provider Data

<kaz> PR 90

<kaz> changed files

Elena: clarified the attack model and including Thing Directory
... question: is Thing Directory out of scope?

McCool: Thing Directory could be addressed in the security recommendations

Elena: it is difficult to define the threat model to the same detail not knowing the protocol
... maybe we can make some general recommendations

McCool: we could explain this in the document

Elena: yes, we can clarify the scope

McCool: can we create an issue to address Thing Directory security?

Elena: we need to add gateway security as out of scope also since we don't cover end to end security

McCool: in a similar way we could make general recommendations
... we can cite external references like IIC
... capture this in the PR comments
... PR #90

* PR #91

McCool: next PR #91 on Security Metadata

<kaz> pr 91

McCool: starting with a simple example
... leading to more complex examples

<kaz> Security Metadata proposal

McCool: ready to merge PR 91

* PR #92

<kaz> PR 92

McCool: Tunnel Configuration

<kaz> changes

McCool: changes to break up long text lines
... not ready to merge; adding a section on shadows

mjk: what about using the term "caching proxy"

Issue #78

<kaz> issue 78

McCool: management API that uses cookies for a use case
... out of time now, any other business?

Actions from today's call

McCool: tunneling+shadow
... elena's PR

<kaz> ACTION: mccool to work on tunneling/shadow for the security metadata proposal

McCool: zoltan create scripting issue for TD life cycle in scripting API
... review examples in the security spec (mjk, elena)

<kaz> ACTION: mccool to work on PR 90

<kaz> ACTION: zkis to create scripting issue for TD life cycle in scripting api

McCool: adjourn

<kaz> ACTION: mjkoster/elena to review examples in the security spec