Security Use Cases and Scenarios - IG

<inserted> scribenick: kaz

elena: [WoT F2F Dusseldorf]
... Security Use Cases and Scenarios

preesnt+ Elena, Niklas

<elena> https://github.com/ereshetova/wot/blob/master/security-privacy/SecurityScenarios.md

elena: shows MD page
... scenario 1 - Home environment
... user privacy is important
... what are the WoT security objectives?
... goes through the table of Threat name and Examples
... important to gather different use cases
... scenario 3 - Industrial/Critical infrastructure environment

danbri: user privacy

elena: collecting first ideas so far

mm: general use cases on both privacy and security
... medical is an important use case
... devices in hospitals communicate with each other
... and industrial
... 2 use cases
... full automation case
... and another case employees are included
... not sure about agreement between employees and employer

elena: medical use case require high privacy

mm: automation within industrial environment
... 2 cases
... 1. not directly monitoring people, e.g., fully automated factory
... 2. employee monitoring

mk: maybe more concentrate on some core part?
... definition of privacy concern, etc.
... privacy and efficiency

danbri: small badge system?

(improving microphone setting...)

mm: repeats the industrial use case including 2 possible settings

mk: please don't combine the 2 use cases

mm: ok
... maybe can split out into 2 use cases

<dsr> Some differentiators: privacy when people are involved, safety when critical infrastrure is involved

<dsr> another is cost, e.g. when failure results in equipment damage and a cost to business

<dsr> smart cities may be interesting as it is a public environment with lots of people

mk: wondering about the goal and what to record here...

<dsr> mk: what is the goal for this exercise?

<dsr> scribenick: dsr

elena: the aim is to group security advice to make it easier for people to see what to apply

mk: it is worth looking at other IoT alliances and SDO’s to see how they are approaching this challenge

elena: sure, and we will want to see what security approaches are relevant to each layer in the comms architecture

mm: IIC is focusing on industrial use cases, as an example

the use cases are important as we are bridging different domains

mm: we may also want to consider mobile use cases

kaz: if the aim of this session is reporting the security TF's work to the group and getting feedback/advice from the group, maybe it would be more effective to do this in a break out session?

mm types in short descriptions of the broad kinds of use cases we should work on

Dave suggests adding law and order to the smart cities use case consideration

mm: also fire and emergency services

uday: we may want to consider coupling between use cases, e.g. smart homes and smart cities

mk: I like the idea of a decision tree as an outcome of ths study

elena: I agree

you usually extract the differentiators from the use cases

mm attempts to list some of the factors, e.g. different classes of people, whether the devices are personal or not, etc.

elena: we can think about what is the impact

mm: we can refer to existing materials, most of which are specific to a given domain

you might be unwilling to share information with insecure systems

danbri: devices in a home may be used to identify empty homes as targets for burglary

mm: personally identifiable information, e.g. for personal devices vs tracking people in a street in an anonymous approach

elena: confidential information may not be tied to people

mm asks elena if there are any standards we can refer to here?

the IIC security framework for instance, talks about several categories of risks

this could help us with scoping our discussion

kaz: maybe we need to look at both providers and consumers of services

mm: the flow of risk may be in the opposite direction

i.e. the risk could come from the consumer

zoltan: …

mm: fake data where false information is being propagated by an attacker

elena: that is a very different level of use case

Dave: fake data can compromise safety

mm: and physical security
... asks for a show of hands for people interested in brain storming on use cases (Soumya and Dave raise their hands)

elena: we will continue with security tomorrow, right?

mk: Review of Existing/Proposed Security Architecture

elena: after that we will have a session on privacy

mm points to the security and privacy questionnaires that Elena has created.

<zkis> https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf

mm: this was inspired by IETF work
... let’s give people a chance to review the email I just sent on this

mm thanks Elena, who leaves …

<kaz> [break]

<inserted> McCool's Notes

Security Next Steps

<inserted> scribenick: kaz

mk: comment on next step for security
... we ran into security discussion
... need to look at practical aspects
... let's clarify the next steps and roadmap

mm: think about relevant use cases
... generate concrete document
... and think about APIs
... next step is working down use cases including mitigation
... one category is existing mechanisms
... and then what kind of scripting API needed
... couple of recommendations for security APIs

mk: security vocabulary
... Panasonic was thinking about security for exposed things
... let's see what is included in their implementations
... we also have some ideas
... then OCF as well

mm: next iteration of OCF binding should include access control
... prioritized list of what to do
... third category is kind of bottom-up

mk: right progress with the Security TF so far?

mm: individuals are liaison communities
... bubble up during the security tf calls

zkis: based on case by case
... in order to have security use cases
... should get members' input
... also OCF network
... deployment is out of Charter
... but we can describe requirements
... and have demo deployment

<zkis> proposal: WG and IG members should describe typical deployment scenarios

<zkis> we should solve security issues cases by case, for those deployment scenarios

<zkis> for instance, in OCF, a WoT bridge is needed that undergoes the OCF security provisioning

mk: would like to encourage people to think about how to transfer this

mm: making issues on GitHub
... discussion during the main call as well

mk: presentation by IETF ACE
... Ari and Carsten
... OCF want to reuse IETF idea

<dsr> scribenick: dsr

Synchronization [IG] - Nimura

<kaz> scribenick: kaz

nimura: review the discussion from the Osaka f2f
... [Conclusions and Proposals]

Servient Synchronization

<inserted> scribenick: dsr

presented by Nimura-san

<kaz> nimura: discussion during the scripting calls

<kaz> https://www.w3.org/2017/05/wot-f2f/slides/Sync-WoT-Servient-170517.pdf

This relates to use cases for synchronising proxies, e.g. a proxy in the cloud for a thing behind a firewall

<kaz> https://github.com/w3c/wot-scripting-api/issues/28#issuecomment-308526421

<kaz> https://github.com/knimura/wot-scripting-api/blob/master/ReverseProxy.md

Nimura-san leads us through the reverse proxy use cases

This covers the use of a cache for operation when there are connectivity problems

This may involve republishing a thing description in the cloud when creating a cloud-based proxy for a thing hosted behind a firewall

<McCool> couple of questions - first, is the TD repo a Thing with a TD? second, what about security? Access to the proxy should require the same credentials as access to the device, and what about encrypted connections and/or payloads?

<McCool> also, can TD repo and/or TD recognize when something is a proxy for another thing?

Nimura-san: we will need to think about that

Michael_Koster: we should talk about the details of the design pattern

<McCool> koster is noting we are working on some related design patterns for links

and related work we’ve been doing

<McCool> I actually think "proxy" should be built into the scripting API so it can be done in a consistent way...

<McCool> perhaps with some controls, eg. to override or hide specific resources

mk: we could learn from the web architecture, e.g. the proxy looks like an origin server to the client

If a client (consumed thing) is not connected to the network, the state can be accessed from a cache

<mjkoster> zoltan: this is an application pattern

mm: should proxies be built into the architecture or treated as an add on - there is a case for the former to promote re-use

mk: I would advise against standardising this

mm: a library would promote consistency

<McCool> having a utility library at least would promote consistency

Zoltan: I agree with Matthias on this, but wonder about necessary network elements such as the TD Repository ...

<McCool> having standard proxies as services is similar to having particular system services... can be adopted or deployed if required...

mk talks about repositories …

<mkovatsc> +1 to Zoltan's comment over WebEx

<mjkoster> matthias: td repo and CoRE resource directory are similar patterns

mm: we could support this via open source implementations of the pattern

Nimura-san: this is an application layer, right (checking with Zoltan)

Zoltan: I am more interested in this kind of caching and synchronisation

mk: this is a good test of whether our scripting API is sufficient

mm: we should be documenting design patterns

perhaps on the wiki?

<McCool> where do we document these "design patterns"

mk: prefer to use the wot github repository

<McCool> matthias suggests putting in architecture repo

<McCool> kaz how does this relate to specification? appendix?

Kaz: I would like to find a way to publlish Nimura-san’s work

mk: perhaps as an appendix?

<McCool> matthias: should go into architecture document...

mk: my main point is that it is premature to decide where to put it

mm: we need to clearly mark it as informative

<McCool> early break for lunch...

<kaz> [ lunch ]

Script Management

presented by Nimur-san

<scribe> scribenick: dsr

WoT ManagerThing as a thing for managing servients

<kaz> nimura-san's write-up

Commands include script installation and uninstallation, script execution (start and stop).

A set of optional commands.

The ManagerThing can be used by clients to remotely manage the servient.

Nimura-san leads us through the document (see link above).

<McCool> Wondering: if device reboots, and is running a script, is it restarted automatically? In other words, how do the managerThing verbs map onto systemd-like installation semantics? (stop/start vs enable/disable).

<McCool> idea is that start (eg run) is only for the current instance of a running device, but "enable" implies it starts automatically at boot

Zoltan: why are you using CoAP for the manager thing?

Nimura-san: this is just an example

Zoltan: do we have any requirements, e.g. for the use of HTTPS or a standard port etc.?

mk: I don’t think we need to standardise the choice of a port or HTTPS etc.

We should advise the use of a secure connection though

Zoltan: do you want to standardise the manager thing?

mk: no, as there are many choices people could make, it would be good to establish the design pattern though

Zoltan: this is not only the application space as it also impacts the system space

mk: it is good to provide a design pattern, but other ideas may come along, so we shouldn’t be prescriptive here

mm: I want to +1 the idea of the example using a secure connection

we may want to discuss whether we want to recommend a port

mm: is running persistent across restart of a server machine?

Dave: we need to make this clear and to provide use cases to back this up

<McCool> to consider: should there be an "update" verb?

<McCool> so install creates a new thing, but update only works on existing things

<zkis> +1 for update command

Zoltan: we also need to consider the vocabulary implications

<zkis> We need help from the TD taskforce for defining vocabulary and TD for Script Management Thing

<McCool> also: decomissioning. I assume "uninstall" should also delete all data associate with the Thing instance

Sebastian: should we define a standard vocabulary for management actions etc.?

mk: we should defer standardising the vocabulary until there is plenty of experience

<McCool> another set of verbs: debugging...

Zoltan: I agree we should distinguish from the core TD vocabulary and we should continue our work on exploring the space of management services

mk: we should use these experiments to verify that the core vocabulary and APIs are adequate

mm: we may also want to work on exploring logging and debugging services

<uday> Should we couple manager thing with Discovery?

The manager thing is a back door and the security needs to be well thought through

mm: the question is whether we have a front door for debugging or some back end solution

the former would seem preferable

mm: I am raising this for future discussion

Zoltan: this is a separate functionality from the management services and we should open this as a separate github issue

<McCool> where should I post issues? Can create two: update; debugging

<McCool> should issues go here? https://github.com/w3c/wot-scripting-api/issues

Nimura-san talks about associating scripts with a handle for identification purposes

Zoltan: we need to experiment with how to identify scripts

mk: we could use URIs and look for inspiration from hypermedia controls

we could then define a REST API for alignment with how the Web works

Kaz: these mandatory and optional commands are for managing the state of the servient

we should clarify how the management vocabulary relates to the servient state

Darko: do we need metadata for scripts?

e.g. for versions of scripts

Zoltan: we could re-use ideas from the web app manifest for this

<zkis> https://github.com/w3c/wot-scripting-api/issues/29

Dave: do we want set some expectations for using a ManagerThing in the next plugfest?

<mjkoster> mkovatsc: HATEOAS pattern for script management

mk: I want to set out some ideas for hypermedia controls based approach

Sebastian: I would prefer to see further demos before we bring it to a plugfest

<mjkoster> zoltan: expose OCF resources in wot thing and add scripts

Zoltan: we could create a demo of dynamically installing and running scripts for some OCF devices

mm: this could be quite challenging, e.g. as it involves discovery, I would think that small technical demos would be fine.

<mjkoster> mkovatsc: sensor fusion like pattern

Zoltan: we can indeed do some demos but still have lots of things to work on

mk: we can use the main call to coordinate ideas and converge on a common understanding

<zkis> please add use cases to https://github.com/w3c/wot-scripting-api/issues/23

Michael_Koster: I don’t see a clear explanation of the script handle

We need a semantic explanation …

Zoltan: yes, this is work in progress

Nimura-san: how should we handle this topic going forward?

Sebastian: we need to gather idea for the TD vocabulary for managment services

Zoltan: we can use the scripting repo in the interim

mk: we need to make it easy for people to find this information

Kaz: may be a subdirectory?

mk: yes

Nimura-san: I will make pull request with the updates from today’s discussion

Data Types [WG]

<Victor> http://w3c.github.io/wot/current-practices/wot-practices.html#type-system

<Victor> Dave's demo: https://www.w3.org/WoT/demos/td2ttl/

<Victor> data type comparison: https://github.com/vcharpenay/wot/blob/master/proposals/dsr-td/td-type-system-comparison.md

<kaz> scribenick: kaz

dsr: [Formal Basis as Linked Data]
... where the type systems come from?
... properties, actions, events and metadata
... core types: boolean, number, integer, string, enumeration
... compound types: can be nested
... object, collection (array), vector
... thing meaning URI to TD
... univons of types for flexibility
... basic constraints: ranges, patterns, readonly/writeable, optional/required

mm: existing ontology on type systems

dsr: if there is something we can use

seb: something missing
... max/min

dsr: that's included in range

seb: schema or json.schema

<McCool> is there an existing ontology we can adopt; an example would be SCRO

<McCool> http://www.indiana.edu/~awny/index.php/research/ontologies/10-scro

<McCool> but dsr did make the point that we conversely don't want to adopt extra baggage (and SCRO has a lot...)

seb: maybe we could complete this list in accordance of those existing mechanism

dsr: number depends on platforms

mk: what is the goal and to achieve?
... how to represent the type on the other side of the system?
... most of them could be modeled by JSON types

<McCool> comment - we could define our own system, but still associate it with an external ontology, such as SCRO, for reference

mk: you could reshuffle this list and make it in order
... could you see simplified types in JS?
... and see how to model this
... basically we want to use JS as the basis, why do you want to consider types?

dsr: probably would better match with objects from OCF, etc.

mk: special kind of array?

dsr: typedef is common for programming
... some of programming languages only have core types

mk: this would require something that JS doesn't have...

koster: not comfortable with these types

<soumya> +1 for koster's comment on vectors

<mjkoster> mkoster: seems like number types and structure types may need to be handled differently

<McCool> kaz: resolution of numbers important

koster: we should think about UC...

danbri: Google has started to participate in WoT
... important area but way too much for W3C

dsr: we can incrementally work based on experiments

mm: how do we specify what the data type system is?
... clear specification is needed
... we should narrow the focus based on our need
... we don't have to think about this until we have specific use cases
... think we should see minimum set

<mjkoster> mkoster: structures are needed to describe payloads, value constraints are needed to describe instances of interactions

dsr: e.g., CSS, started with minimum set of features (and now has various features)

mk: this would help our discussion on scripting API but you don't have to jump into the details of extension of type set for JSON/JSON-LD

<mjkoster> mkovatsc: the type system is decoupled from the semantics and makes it hard to do some filters like units

taki: working on creating new type systems would take much time
... would see if json.schema is really not enough
... choice could be better fit for union mechanism

vic: there is choice in json.schema
... just saw examples from OCF. can show them.

<mjkoster> mkoster: "oneOf"

dsr: e.g., new features of CSS would allow you easier styling

<danbri> some related experiments from ericp at w3c: https://www.w3.org/WoT/demos/shrl/test.html http://tinyurl.com/y9fm2zsy http://tinyurl.com/yay2xzjd (using Shex over the RDF graph data model).

seba: why we need vectors, for example?

<McCool> sebastian: is there an example for vectors?

<McCool> McCool: RGBcolor uses a 3-tuple

<McCool> used in lighting, of course

<McCool> RGBled in our OCF demo used it

<McCool> of course we could also use an array, but it was also a specific length

<mkovatsc> Qß

<mjkoster> mkoster: a map is suitable for RGB or RGBW

<mjkoster> else you would need 2 types, etc...

<McCool> true, and basically that is how it is done in JSON

<McCool> and was done in the OCF example

mm: very complicated data cases
... jpeg, png, etc.
... we should work case-driven

<mjkoster> jpeg and png are mediatypes

<mjkoster> not datatypes

<Zakim> kaz, you wanted to wonder if we want to make JS yet another mathematica

<inserted> kaz: do we really need to extend JS to make it yet another mathematica? we should clarify use cases based on plugfest demos, etc.

<McCool> what I meant, was that we should only define what we need for OUR scripting API, not for all possible scripting APIs

<Zakim> danbri, you wanted to ask if there is an explicit list of usecases for the type system (e.g. validation? codegen? ...)

<McCool> defining a mechanism for defining all possible scripting APIs is beyond the scope of this particular WG (not that it would not be useful, it just is not in scope here)

<McCool> let's just define our scripting API and introduce definitions only for the types we need

<mjkoster_> danbri: need to be explicit about what the type system is used for

mk: we should start with some initial set
... not sure what the blocking point is
... from different data models

<mjkoster_> mkovatsc: define how data are presented to the application

mk: need schema information and semantic annotation

<mjkoster_> ...it seems like the json types are sufficient to get started and build upon

<mjkoster_> dsr: we gain convenience

<danbri> (for the notes - dsr responded to my request for usecases for the type system, by pointing to the introduction of https://github.com/w3c/wot/blob/master/proposals/dsr-td/td-draft-spec-dsr.md)

<danbri> ... including code generation (if I understand right), definitions for actions/events/properties, and also validation.

mk: seems to be too ambitious...

seb: would be helpful to show us why we need these additional types

<mjkoster_> sebastian: +1 what Matthias said, the json types seem sufficient

<danbri> Maybe these can be requirements and SHACL or SHEX can be taken as candidate ways of meeting those?

<mjkoster_> dsr: if we use low level constraints, there is a lot unspecified

<mjkoster_> dsr: numbers mean different things in differnent programming languages

<danbri> on screen: comparison of OWL and JSON Schema from (somewhere in https://github.com/w3c/wot/tree/master/proposals)

<mjkoster_> victor: presents json-schema vs. owl chart, including OCF resource type examples

https://github.com/vcharpenay/wot/blob/master/proposals/dsr-td/td-type-system-comparison.md

dape: you can reuse json.schema if it works

vic: schema.org also?

danbri: schema.org is declarative not validator
... btw, how deep this group work on SHACL?

<mjkoster_> victor: it amy be difficult to map OCF using SHACL, for example

vic: need for concrete examples of each feature
... your listed additional features of type systemss
... myself will continue this way of comprison (e.g., JSON vs OWL)

mk: feel as if we were back to Montreal...
... we looked at json schema, etc.
... could use metadata for modeling linked data with some restriction

<McCool> time check... we are well into the break. Can we wrap up?

<mjkoster_> mkovatsc: mapping from json-schema types to linked data, with additional constraints added using linked data

<mjkoster_> danbri: look at what is done in json-schema and express in RDF rather than referencing json-schema directly

<danbri> danbri: "my advice would be not to normatively reference JSON Schema, but take its actual use for IoT as driving requirements for something similar but on top of the Linked Data (i.e. RDF) data model. I'd predict SHACL/Shex will be the main focus, but RDFS/OWL used for basic term declarations too."

[ break ]

TD and Links [WG]

<scribe> scribenick: McCool

victor: presenting what did for plugfest

wrapping SSN in things

use links to get values

or invoke actions

for now links are abstract

but we might (want to) make them more concrete

SSN/SOSA model

important classes are observable properties and feature of interest

sensors can make observations

observations are events where properties are associated with values

values are string, number, or more complex structure

made an alignment with our resource model

feature or interest -> Thing; observable -> Property; observation -> Event

but association is not exact

maybe we could use links to model the whole thing

SSN dataset usually has several observations

cannot have this in a TD; cannot have histories

servient can subscribe to an event to get a result, but cannot get previous events

so... what if we had a history, or previous, or client

also, uri templates

we haven't done anything with those

relation types that are already registered for CoAP, etc

already have some interesting semantics, such as collections

presented a TD eample with an SSN dataset

had mechanism to get latest, but also history

proposal: add a relation type to each link

so you can ask for the latest, or older observations using a timestamp

using relation type history

some alternatives here: queue like in the Mozilla proposal; or query to search over timestamps

matthias: rel is used for something else, doesn't think semantics

michael (k) may have some comments

dsr: can we connect to linked data model

victor: normally made links with URI templates

but may be tricky to do validation

but if use JSON-LD features...

either we have a predefined set of relation types are define as properties

validation may be hard

matthias: alt to rel property would be to have two related properties

victor: could distinguish links with different @type

questions about mapping

Darko: should both event and property be observable properties since they produce data?

victor: if you look at other systems, can have complex input data to queries

but did not think of this, should experiment in this direction

mk: been looking at a lot of use cases for linking

not even sure about rel

but if are using links only to point to endpoints, don't need rel

if want to build a td that points to other tds as an index, for instance, then we might want to use rel

it does things that attributes don't do

dsr: don't think we need this; can use an API
... also think timestamps should come explictly as part of the data
... no need to expose that as part of the TD
... did example with electrocardiogram data

victor: understand argument that we could have simpler solution

<mjkoster> (comment) We should not be too focused on this one use case for linking, and this one link term "rel"

matthias: going back to mk's comment

how rel was used in this example makes things more complicated

mk pointed out where it would make sense

where one thing is related to something else, eg composition

when we have to express HOW things are related

<mjkoster> mkovatsc: showing how things are related does make sense in some cases, but not this case

URI template should be considered in protocol bindings

<mjkoster> mkovatsc: should consider this mechanism also in the binding templates

McCool: looks similar to the issue we have with multiple if types eg in OCF bindings

would be nice to solve this and that the same way

<mjkoster> mccool: could use links to express/select query parameters at the protocol level

what do we do next in the td?

started with serialization

we have discussed compression using shared knowledge, we have an enhanced data set, and then we have the proposal from Mozilla

<soumya> Benjamin and I will participate in the future TD works regularly

seb: it would be very good to involve Ben from Mozilla in this discussion

Matthias: have drafted quick response to Mozilla, sent to team-wot for review

will invite him to give a presentation to group, probably in two weeks or four weeks

26 July or 9 Aug

we have discussed JSON serialization before; Mozilla proposal may bump up the priority

we have a baseline using JSON-LD that works for now though; but would be fine to look at additional serializations

<mjkoster> (comment) danbri may have some input to the JSON serialization question

iot.schema.org - next Plugfest would be interesting to actively use, but maybe not so easy

mk: no showstoppers, but there is work to do

need to arrange for access, and have some experimental vocabularies

next, we want to enhance the core vocabulary

need for instance we might want a "method" (POST, PUT, etc); may need URI template

<mjkoster> sebastian: protocol binding is priority 1

<mjkoster> ... semantic annotation is priority 2

who is on the team?

matthias: this IS a new TF, since it is associated with a deliverable

<mjkoster> mkovatsc: protocol binding is a new task force and a new deliverable

<soumya> I will join this as well

also uday

matthias: unfortunately, still in IG as a proposal

maybe can resolve with matthias making another proposal

then we can start populating the wg

next, managerthing

will have a deep discussion

will define a set of vocabularies to support it

then look at a set of examples, aim for some demos in the next f2f

show some managed things

next, data types

dave to provide some concrete use cases

then define mapping between linked data and JSON schema

use ShEx and/or SHACL for validation

victor: define mapping using OWL and JSON-Schema; equivalent

correction: ShEx and/or SHACL for validation; OWL and RDFS

matthias: have to avoid referencing JSON-Schema

instead we will model features using RDF so things are formally defined in an equivalent way

dsr: use cases from Echonet, oneM2M, etc. that can support each of these features

matthias: start with core definitions that come from JSON-Schema for instance; it would be good to establish that we CAN extend to more abstract types, but we may not use them right away

let's start with a core that we can use right away

dsr: worth having some plain prose descriptions

mccool: formal is normative, prose description to be informative

next, links

victor: proposal to use IANA rel for links

but, based on feedback, will look more at using this for relations

darko: this is a recipe idea (relations)

example, a group of lamps can be related to each other

or a room could be a collection of things

McCool: I think we need to do more work on events and actions

<mjkoster> mccool: example ROS functionality for long running actions, check status, cancel, etc.

matthias: we can treat the Mozilla proposal as a prescriptive proposal we can try to describe

mccool: we can look at other things as well, such as MQTT/ROS for events, and ROS for actins

mkoster: in proposals folder there is something for events

for events, who can work on it?

nakasan

mccool: my use case is ROS, which has both events and actions

kaz: example td, possible relation between manager things and action/event discussion

mkoster: simple actions are already there, just need more definition

move to adjourn...

<kaz> [ Tech Day 2 ends ]