<mkovatsc> Hi Zoltan

<mkovatsc> There was a local quetion, if we could start with the PlugFest feedback

<mkovatsc> Yet I understand Elena can only join after the break

<mkovatsc> How about you? It would be good to have you in the Eventing discussion

<kaz> remote: Ben_Francis, Zoltan_Kis

<kaz> scribenick: dsr

<scribe> meeting: Web of Things IG/WG face to face

Agenda

Kajimoto-san introduces the agenda

WoT Architecture

Matthias asks people who here for the first time to raise their hands

<Vagner_Br> https://github.com/w3c/wot-architecture/blob/master/terminology.md

Matthias points to the WoT terminology document as an aid to understanding the terms we are using

<kaz> remote+ Maxime_Lefrançois

<kaz> WoT Terminology

<kaz> WoT Architecture document

Matthias decribes how we are using the term “servient” for a WoT end point

<kaz> [Matthias explains the architecture based on the Figure 12 in the document]

<zkis> "Endpoint" needs to be defined. For instance in OCF there could be multiple endpoints in a "servient" (device)

“Thing” is an entity that has a thing description.

Zoltan notes the need for defininging the term “end point” for WoT.

Michael: we should collect terms where we need further discussion.

Matthias asks for feedback from newcomers

Kathy: (Mozilla) “Servient” is a little new to me as a term

I would prefer words that better reflect what people are implementing

<benfrancis> Why not just use "server" and "client". Surely not every server needs to be a client?

<zkis> example for OCF endpoint list for a device (servient): ​​"eps": [

<zkis> {"ep": "coap://[fe80::a4ca:5493:e96:3cea]:1111", "ttl": 86400,"pri": 2},

<zkis> {"ep": "coaps://[fe80::a4ca:5493:e96:3cea]:1112", "ttl": 86400,"pri": 1},

<zkis> {"ep": "coap+tcp://[2001:db8:a::123]:2222", "ttl": 86400,"pri": 3}

<zkis> ]​​

Michael: new terms do create a learning curve for newcomers

<benfrancis> (and not every client needs to be a server)

<scribe> ACTION: mkovatsc to review terminology in regards to reducing the learning curve

<trackbot> Created ACTION-122 - Review terminology in regards to reducing the learning curve [on Matthias Kovatsch - due 2017-11-13].

<kaz> [Matthias explains the structure using Figure 9]

Matthias continues his walk through the architectural landscape for WoT

This includes gateways, clouds, web browsers, direct access to devices

Enabling devices to function as first class web of things citizens avoids the need for gateway hell

Kathy: where do you see interoperability with IoT standards, e.g. OCF and oneM2M

Matthias: this is what we use binding templates for as a means to interface with different IoT standards

Michael (Intel): Intel is part of OCF and we’ve been working on OCF integration as part of our plugfest work

<mkovatsc> https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame

<zkis> Michael: OCF already presents metadata description of interfaces, we try to convert those to WoT Thing Descriptions

PlugFest Feedback

Matsukura-san presents an overview of the plugfest that took place over the weekend

<Mizushima> https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md

Matsukura-san shows a diagram that shows the relationships between the components provided by different participants.

Matthias provides further background on the use of local proxies

Michael: one challenge is there can be multiple URIs and channels for the same device, so comparing them can be difficult.

<kajimoto> -

<scribe> ACTION: Sebastian to provide text on TD management and publication

<trackbot> 'Sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).

<scribe> ACTION: skbisch to provide text on TD management and publication

<trackbot> Created ACTION-123 - to provide text on td management and publication [on Sebastian Käbisch - due 2017-11-13].

Michael: semantic search is important

Darko: we will talk about this later

Michael describes how he handles local and remote URIs for things

(Dave: this seems to be a confusion between URIs as identifiers for things, and URIs for accessing things)

Michael: we should table this for now and come back to it later.

Matsukura-san continues with his summary of the plugfest

Matthias: any other issues that came up in respect to synchronisation?

[no]

Michael presents some slides on semantic and his work on an OCF metadata translator

There are some semantic annotation issues, e.g. missing or inconsistent terminology

these reflect the lack of maturity in IoT ontology development

Michael: we want to describe things as hosting a set of capabilities

Darko: we’ve been looking at using the capability vocabulary from iot.schema.org

<kaz> -> iot.schema.org iot.schema.org

He shows how this has been integrated with the thing directory

The iot.schema.org vocabulary is based upon existing models

Richard: What is the mechanism for contributing to the iot.schema.org work?

Darko: Michael Koster and I are leading this as a community group

What provision is made for versioning of models?

Darko: we haven’t looked at that as yet apart from Github itself

We want to follow best practices from schema.org

Michael: the version could be included as part of the URI

Darko: for now this is really experimental and put in place for this plugfest

Matthias: the thing description defines how a given capability is expressed as the object interface.

<kaz> iotschema.org/Capability

Darko: as the schema’s mature, they can be moved over to schema.org

Michael_Koster: we plan to use W3C Community groups to support this

We need to enable people to describe their own devices effectively

Dave: this relates to my new role as the W3C Data Activity lead, and the study I am doing with the Open Data Institute on tooling and practices for web data standardisation - the aim is to make W3C a better venue for web data standardisation

I will send a pointer to the study to the public list

Matthias introduces the scripting API

scribe: and the challenges for including metadata in the API

Darko: We already need to define some common prefixes for namespaces.

Daniel: this is like qualified names for XML, and we should discuss this further

<kaz> [[

<kaz> General Thing metadata:

<kaz> dictionary ThingInit {

<kaz> DOMSTring name; USVString url; Dictionary description;

<kaz> };

<kaz> Interaction annotations:

<kaz> dictionary ThingPropertyInit {

<kaz> sequence<SemanticType>semanticTypes; ThingDescription description;

<kaz> };

<kaz> Algorithm for contexts:

<kaz> dictionary SemanticType {

<kaz> DOMString name; USVString context;

<kaz> };

<kaz> ]]

<kaz> nimura: what about normalization/categorization of the vocabulary?

<kaz> ... same terms from various industries

<kaz> matthias: something to be discussed by the LD TF

Matthias: this sounds like something for the semantic processing task force

<zkis> The SemanticType dictionary is meant for defining solution-specific or standardized semantic type annotations with an ExposedThing. The other Things that take part of the solution will understand them. All other will understand the standardized one (atm none).

<benfrancis> Regarding plain JSON serialization, task force in Interest Group working on a proposal here https://benfrancis.github.io/wot/proposals/json-td/index.html

Matthias notes that challenge of scripting access to thing descriptions for introspection.

<benfrancis> (sent pull request to W3C repo for comment https://github.com/w3c/wot/pull/363)

Dave: you could use a simple JSON API or an RDF based tripple API

<kaz> [morning break]

<kaz> scribenick: kaz

Security

mk: [Beaer Token]
... "security": {
... [Forward Proxy]
... security feature
... mode: proxy,
... href: http://plugfest.thingweb.io:8087,
... authorizatin: Basic
... }
... what kind of security is used

mm: assume HTTPS
... issue on local HTTPS

mk: need certificate for HTTPS
... any body working on security?
... maintaining the security part of the code?
... beaer token

mm: will be

mk: authorization: Bearer ?
... root certificate you need
... we can have wot client
... how to get credential?

kaz: Ajitomi-san from Toshiba working on HTTPS local network
... breakout session on Wednesday

mk: the session time is not assigned yet?

kaz: right

mk: any comments from Elena?

er: what the proxy should do?

mk: kind of how to solve the security issues over the firewall
... local proxy connected to devices behind the firewall
... what kind of authorization mechanism for security?
... e.g., water pump plant in Munich

er: need to describe access control

mm: every resource linked with authorization mechanism
... can collect access control information

er: you want to specify the number of the devices
... need to care about the structure of the system

mk: you can access everything once you got access
... within the network, e.g., a factory
... a possibility is not allowing permission for accessing devices

mm: not showing devices people don't have permission
... TD to specify who to get access permission?
... do we want to have another level for security?

mk: would recommend not too engineering mechanism at the beginning
... big iot project presented in Dusseldorf
... snippets of different actions
... separated from the basic TD use cases
... we can see good practices already
... example was
... the web server shows links
... which you can interact with
... also enforcement later on
... possible administration view
... could be a good way

er: do we need to combine security here?

mk: could be done separately

<ohsumi> exit

mk: but could be combined and go to some specific field
... how is it aligned with TD?
... proxy consumes and forwards information to devices
... e.g., remote devices in Munich
... proxy also there
... convert information to the public side

er: proxy verifies the connection?

mk: only the authorized fields go to the device side
... should discuss more concrete industry use cases

sk: have a comment
... should be more flexible
... e.g., multiple security entries

mk: reminds me of 2 things
... merging the areas
... identify to use which one, this or that

sk: we can put 2 information

mk: [Bearer Token]
... hoping to have more examples
... e.g., OCF bridge

mm: OCF bridges don't include OCF security yet

mk: spec published?

mm: OCF 1.0 is public

mk: one part is testing and another part is collecting good use cases
... multiplexing and merging different approaches
... what about Panasonic's security approach?
... already as an array?

mm: we identify the roles of each one
... from the array

er: each approach may have some issue

mk: we keep it open
... and would look into other organizations
... would suggest we don't try over-engineering at the moment

WoT Architecture: Event Models

mk: possibility of observable property
... [Observable Properties]
... change-of-value notifications
... good match with CoAP observe

mm: related to actions
... had discussion during the plugfest
... we have properties and get/set
... separately declared
... related issue on actions
... observable is kind of event
... implies events
... would be useful to have some simple mechanism
... handle the issues consistently

mk: [Interaction Model]
... discussio with Koster
... buffer on the semantic model

<Zakim> dsr, you wanted to mention observables and data validation

mk: [Observable Properties]

dsr: data validation
... you can define different handlers

mk: talking about the implementation viewpoint?
... this idea itself is independent from JS or anything
... (going back to the slides)
... [Observable Properties]

dsr: properties are observable

mk: don't have to define events
... what would be the best fit for use cases?

<dsr> observerables as per ECMAScript

zk: talks about some scenario
... expose some property

<dsr> observables provide a design pattern for value changes and for handing errors, e.g. when an assignment conflicts with a properties description

zk: people need to specify which property is observable

mm: we can specify a property is observable

<dsr> (Dave wants to know the use cases where properties are not observable)

mm: but how can be observable?

mk: you've described what to do on the binding level

<dsr> ECMAScript observables: https://tc39.github.io/proposal-observable/

mm: marking if a property is observable is simple extension

<dsr> Also: https://github.com/tc39/proposal-observable

mk: how much support for this?
... we have to come up with some concrete text
... anyone remember who brought this idea?

sk: started with CoAP observe?

koster: explains
... suggestion not to have event handling for each property
... goes back to multiple interaction protocols
... my theory is having events to handle more high-level controls
... not just for set/get

mk: value notification associated
... difference from change value notifications?
... in that sense, I can follow the discussion
... any other opinions?

sk: what we have at the moment
... question on interaction model
... need both property and event?

mm: there are systems already
... just read/write/observe
... no other things
... think about eventing model
... pub/sub etc.

zk: event means notification

koster: change of the state

mm: should be observable property

koster: need events of some kind

mm: should have simple events

mk: the issue is that it's quite complex
... CoAP has observable property functionality
... need consistent mechanism with that

koster: CoAP observable is unreliable by design in that way
... most of the protocols have good hand-shaking mechanism
... which CoAP doesn't have

zk: we can't guarantee event delivery

richard: what's the practical way?

<zkis> we can't guarantee event delivery

richard: who would get notification?

mm: get/set/observe kind of methods could be used

<dsr> Dave thinks this is overblown. The synchronisation protocols need to transmit property value updates and regular events, so in principle, any property can be observable, and this is mostly about the API, e.g. the ECMA observable pattern

richard: talks about some example
... button press could be observable
... you can get any status the system exposes as observable
... any reason not to make any properties observable?

dsr: should decouple from the underlying protocols

mm: an example of HTTP endpoint
... can get/post values

mk: would summarize

<benfrancis> This is the problem with everything being so abstract. If a device implements a REST API then all properties can support GET and PUT. If a device implements a WebSocket API then all properties can probably be observable. But trying to define this in an abstract way for all possible bindings is... challenging.

mk: nice to get comments
... we can't guarantee events reach the user
... you might miss something if the connection is lost
... if you have a critical application, need some additional mechanism

<benfrancis> I don't see how ECMAScript observables helps. That's just if the API is being consumed in JavaScript and doesn't explain how property changes and events are sent over the wire.

mk: there is a pro with having observable property
... events to be used for important purposes
... would suggest we start implementation for events
... have to tackle the issue of events

zk: action to return TD?

mk: not enforced

mm: you could follow HATEOUS approach for example

<benfrancis> Again, getting concrete... With REST an action request can be POSTed and then GET the resulting action request URL to get status. With WebSocket API could use requestAction and actionStatus messages asynchronously.

kk: before lunch, some announcement
... demo from 13:15

[lunch]

Mozilla demo

mm: how to get location?
... registered?

OpenDay: Recent Publications and Vision 1

WoT Architecture FPWD

Scripting API FPWD

-> @@@binding draft

-> @@@security draft

mk: goes through the draft specs
... terminology defined within a separate page

terminology section

actual definition on the MD file

mk: goes through the use cases

Use Cases

mk: Security considerations

Security

mk: and actual content on the architecture

WoT Building Blocks

scribe: Thing, Thing Description, Binding Templates

mm: security contains many resources

mk: Scripting API
... explains the structure of the documents
... WoT Architecture itself as a document
... and documents on each building block
... next WoT deployment scenarios

WoT deployment scenarios and guidelines

mk: WoT client, Servient on Device
... resource-constrained device as a Thing
... bigger picture on "servient on cloud server and gateway" (Fig 19)
... servient on cloud server only (Fig 20)
... please add your scenarios as well
... need more work on discovery
... connectivity and security
... need guidance from the security group
... we should add clarifications based on what we've been doing
... people prefer simple approach as a starting point
... so maybe can start with the Thing directory approach

soumya: working on discovery tf

mk: this is higher-level discussion here

mm: Thing Directory could be a SPARQL endpoint
... would be powerful
... and multiple endpoints could collaborate with each other

mk: need to describe issues and guidance
... what are the design patterns people need

soumya: looked into the SPARQL option
... will be happy to do more detailed work

mk: question on "who have read the FPWD?"

(some raise their hands)

hb: accessibility issues?

mk: so far machine-to-machine communication
... what kind of user interface needed
... could be levelaged by some kind of multimodal interface

kathy: separated UI from the system

mm: e.g., audio audible alarm
... accessibility requirements

kaz: mentions there was a session on accessibility for WoT during the Web Conf last year

hb: would like a link to the report from the session on accessibility for WoT during the Web Conf last year

@@@link tbd

TD

sk: [Basic Facts about TD's FPWD]

<mkovatsc> https://www.w3.org/TR/2017/WD-wot-thing-description-20170914/

sk: reflects the experiences of around 8 PlugFest meetings
... (summarizes the plugfest efforts)
... reflects WoT's Properties, Actions and Events
... domain independent
... open to integrate exisiting domain knowledge
... expectation is being index.html of Things/devices
... [TD Core Model]
... (explains the TD model diagram)
... what kind of interaction model you use?
... how does the payload look like?
... reflecting communication metadata
... [TD Serialization with JSON-LD]
... small example TD
... define context, e.g., w3c-wot-td-context
... W3C WoT TD vocabulary
... and domain-specific vocabulary
... JSON Schema-base types and semantics
... e.g., Celsius as unit
... possibly which kind of UI to be used
... [Let's go in!]

mk: asks who read the TD draft

(some, more than the architecture, raise their hands)

TD FPWD

sk: goes through the document
... Introduction, Terminology
... Namespaces
... TD relies on
... can follow the link to get the namespace

https://www.w3.org/ns/td/

sk: open issue on listing all the possible namespaces
... another issue on validation
... just the structure?
... or need interpretion?
... what is the expectation?
... and then core model
... next, serialization as JSON-LD
... discussion during the TD task force calls
... can reuse external context using "@context"
... multiple examples there

<McCool> McCool: noting in passing that TD doc describes "security" as containing "an array of objects"

sk: example 3 on sensor
... link capability
... and security
... currently short section

mm: array of objects
... in the table at 6.1
... is that correct?

sk: complex type is possible
... (goes through "6.5 Type System")

type system

mk: related to binding
... abstract structural description for inter-conversion
... how to serialize that

kathy: Ben provided some idea on possible serialization

sk: will talk about that later
... we have to describe what the client expects

da: representation of complex data type
... how to validate?
... JSON Schema?
... how to translate complicated data written in RDF?

mk: take the vocabulary from JSON Schema but represent the date in JSON-LD

da: can you still apply JSON Schema?

sk: is your point "how to validate TD"?
... that's still an open issue

mm: no type associated with property itself
... maybe good to have default mapping for property itself

sk: question about payload
... what the device offers
... how you can get access to the data?
... we should be clear about the differentiation

mm: is there any simple default coding?

sk: we can use JSON Schema to check the structure
... and then
... plenty of examples here
... and need to add content for security&privacy considerations
... [Current Experiments and Next Plans]
... introduce observable flag in property for TPAC plugfest
... JSON Schema as linked data representation
... metadata for some protocol bindings, e.g., method, headerOptions, ...
... URI template, e.g., /blabla/{timestamp}
... TD management and publication
... alternative TD serializations (Mozilla proposal, EVRYTHNG proposal)
... how the core TD model should look like?
... to integrate domain-specific knowledge, etc.
... Daniel looking into binary serialization, e.g., EXI and CBOR

mk: given the time schedule, maybe could talk about JSON serialization?
... need to clarify extension points
... JSON-LD work by the WG
... and JSON work by the BG so far

kathy: Ben made a proposal

<sebastian> https://benfrancis.github.io/wot/proposals/json-td/

<kgiori> https://benfrancis.github.io/wot/proposals/json-td/

dsr: (will talk about that for Ben)
... [JSON Web Thing Description]
... (shows the example including "My Lamp")

[[

{

"name":"My Lamp",

"type": "thing",

"description": "A web connected lamp",

"properties": {

"on": {

"type": "boolean,

"description": "Whether the lamp is turned on",

"href": "/things/lamp/properties/on"

},

"brightness" : {

"type": "number",

"description": "The level of light from 0-100",

"min" : 0,

"max" : 100,

"href": "/things/lamp/properties/brightness"

}

},

"actions": {

"toggle": {

"description": "Toggle the lamp on and off"

}

},

"events": {

"overheating": {

"description": "The lamp has exceeded its safe operating temperature"

}

},

"links": {

"properties": "/thing/lamp/properties",

"actions": "/things/lamp/actions",

"events": "/things/lamp/events"

}

}

]]

dsr: some of them not necessary

mm: we don't have "description"
... we have properties associated with input/output
... so not just an alternative data format

mk: different model
... we could cover the details, though
... what is the parameter for interactions?

dsr: would look into the proposals by Ben and EVRYTHNG
... each company involved in HTTP

mk: more complicated example could be also covered
... there is no media type definition but could assume it's application/json
... also could think about invisible properties like description

sk: 2 years ago when we started TD work, the definition was similar to this
... but after 8 PlugFest efforts, TD has changed
... btw, not sure about links

Links member

mm: probably more contentious

[[

"links": {

"properties": "/thing/lamp/properties",

"actions": "/things/lamp/actions",

"events": "/things/lamp/events"

}

]]

mk: there are several discussions which have been done separately
... we remove type as property from TD

dsr: this work is still at its early stage

mk: how it would look like with some more complicated use cases?

dsr: would require further investigation

mk: we've been working as the whole group during PlugFests
... but you've been working separately
... maybe you could bring your implementation to PlugFest

sk: there is a GitHub repo to collect concrete TDs for the PlugFest in Burlingame

<yamada> https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame/TDs

sk: you can put your TDs there

Scripting API

mk: one of the optional building blocks

Scripting API FPWD

mk: WoT object and APIs

WoT Object

mk: 3 methods: discover, consume and expose

<McCool> McCool: before I forget: noticed that in TD document all examples for properties show only "outputData" but there is no example for a writable Property which needs both inputData and outputData with the same type... which shows the weird issue that Properties don't have types, only their input and outputs do. Perhaps properties should have types... then we could infer default JSON encodings (for example) for inputData and outputData (depending on "writable")

mk: abstraction for Things
... wot.discover() to discover things
... consume means using device's capability
... scripting discussion one year old
... we're operating the spec defined by this document during our PlugFest
... ThingFilter dictionary
... ConsumedThing interface
... requests to servers to retrieve/update properties, invoke actions, etc.
... setProperty, getProperty
... observe, originally for events
... no implementation for observable property, maybe next PlugFest
... next, ExposedThing interface

<sebastian> I uploaded the TD FPWD slides here: https://www.w3.org/WoT/IG/wiki/images/b/b5/TD_First_Public_Working_Draft.pdf

<sebastian> welcome

mk: TD builders: addProperty, etc.
... need simplification

<zkis> see also https://github.com/w3c/wot-scripting-api/issues/78

mk: hooks using RequestHandler
... personally think it's confusing to have both TD builders and request handlers
... how to modify Things dynamically?
... need detailed algorithm definition
... nimura-san?
... browser implementations can cover HTTP/HTTPS
... WebSocket might be complicated since it has initiation part
... good to see CoAP support by Web browsers

mm: going to use polyfill

mk: JS approach quite inline with the Web Browser work

dsr: how many implementations for Scripting?

mk: 3?
... Fujitsu, Intel (Zoltan for node iotivity) and Siemens (node-wot)

mm: we're more focused on JavaScript version

mk: there is a chance to use another abstraction but so far we've been focused in JavaScript

zk: there is an issue on scripting

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

mk: what is the minimum set for a runtime?

<zkis> see comment https://github.com/w3c/wot-scripting-api/issues/78#issuecomment-340699513

[[

Promise<ThingDescription> fetchDescription(USVString url);

]]

mk: for the ConsumedThing interface

[[

Observable<any> observe(DOMString name); // event / property change notifications

]]

mk: for both observable events and properties

richard: observe for consumedThing?

mk: could be 2 entries, but do we really need 2?

richard: 2 different concepts
... another point, should change the name for "description"
... maybe text?

mm: +1

mk: Thing builder...
... opening a can of worms...
... if you create an object for a Thing, you'll feed some TD
... what would be a programmatic approach?

zk: nice to have concrete use case description and continue the discussion
... would like input for my comments

[afternoon break till 15:45]

Binding

koster: [Protocol BInding Templates]
... problem solved with protocol bindings...
... adapt common WoT client abstraction to diverse things
... which use different protocols
... architecture
... layer between application clientand device protocols
... [Use cases]
... mapping of the WoT abstract interactions: events, actions, properties
... adapt to existingdevice ecosystems: OCF, LWM2M/IPSO, Bluetooth, Zigbee, Echonet
... [Architecture]
... diagram here
... Thing Description includes interaction model and binding template
... what to do and how to do, respectively
... [Protocol Adaptation]
... client of proxy uses information in the Thing Description to adapt to protocol specifics
... payload structure

mk: difference between payload structure and JSON type?

koster: payload structure could be array, etc.
... specific way for OCF, etc.
... for example, using JSON

mk: maybe just an example and actually don't need?

koster: [TD Extensions]
... inputData and outputData describe the payload structure
... value constraints enable the client to adapt to the data (e.g., 0-100 for brightness)
... [Example inputData Element]
... payload structure:
... fields: [

{

name: brightnesss,

value: {

type: integer,

@type: sch:levelvalue,

min: 0,

max: 255

}

}

mm: could be array?
... and wondering about unit

mk: sch:unit?

mm: based on JSON-LD

koster: [Link Metadata Example]
... and then link part
... href describes URI
... rel - methods for interaction
... "wot: invokeAction"
... and then "coap:methodName"
... related to "HTTP linked data vocabulary"

mk: maybe possible to reuse the vocabulary?
... could work out to define coap request

mm: need to add conditional elements

koster: special things for OCF, e.g., coap:fildName: 12
... and coap:fieldName: 2053
... [Payload Variation by Protocol]
... OCF Batch Interface
... and LWM2M/IPSO
... [inputData for OCF Batch]
... nested object here
... [inputData for LWM2M/IPSO]
... "@type" specifies the expected type, e.g., "sch:levelvalue"
... questions?

(no specific questions)

koster: will continue to work and publish it at some point

Security

security draft

mm: still an Editor's draft
... define informative considerations for security
... who can attack you, etc.
... some work on the industry side
... threat model for IoT included
... privary stakeholders, supported physical roles
... assets, adversalies, attack surfaces
... framework on how to use WoT
... security objectives
... stakeholders, who does what
... a lot from usual IoT consideration
... with WoT consideration
... issue on maintaining scripting api
... also issues with OEM
... what part of the lifecycle to care about?
... so far mostly focused in the use part
... other part of the lifecycle later
... regarding the run time

WoT high-level architecture security view

mm: wide variety of implementations
... and then various kinds of threats here
... there are many green boxes (editors notes)
... more and more concrete things
... and then have security objectives
... home environment
... and also business/workplace environment
... critical environment
... existing security best practices: 4 references here
... Garcia17, IicSF 16, IETFACE, ISF17
... and then a number of references for privacy
... recommended security practices
... secure delivery/strage of TD
... secure transports, avod heavy functional processing without authentication
... avoid exposing immutable identifiers
... examples of WoT security configurations
... various issues with gateway
... e.g., WoT gateway is not a trusted entity?
... WoT Servient Multi-Tenant
... what are the extra requirements?
... we need validation and testing as well
... this document still work in progress

mk: something similar by IETF?
... maybe should get rid of overlapping content

mm: making security mandatory is a good idea but that's not possible in some cases
... subset of TD for non-secure devices?
... might be good to have discussion what is required field

mk: comments on web service penetration

mm: would think about that

semantic annotation

TD extended with iotschema.org

@@@ slides tbd

da: experience from yesterday
... discovery problem, iotschema and what's next
... that's about recipe
... [Motivation: Thing Discovery
... we have a guy here
... needs to find an air conditioner
... how to do that?
... exact name of the thing?
... possibly
... query based on string
... request MyAirConditionerP1
... nad get TD
... but wouldn't it be nicer to use more abstract concept?
... e.g., just using "AirConditioner"
... [iotschema.org]
... you can go online and browser the device (capability)
... can just take the url like: iotschema.org/AirConditioner
... what to explore and get TD immediately
... not only discovering things using that abstract name
... but also target also can be defined
... interaction patterns of AirConditioner Capability
... IoT interoperability
... [Overview IoT Schema]
... [Narrow Waist in System Design]
... many apps - WoT (semantic interoperability) - IoT (IP networks, LAN/WAN) - many devices from different ecosystems (Fairhair, OCF, dotdot, Z-Wave)
... [What needs to be built]
... app level semantic interoperability
... well-known formats to describe common affordances of connected things

dsr: what about the location?

da: still need dome ontology
... not mentioning the details here
... [Layers in the Semantic Stack]
... common protocols a the bottom
... diverse devices from device ecosystems (OCF, Zigbee, Z-Wave, Fairhair)
... Web of THings semantic narrow waist
... iotschema.org, ontologies
... W3C TD, hypermedia controls
... [Capability Abstraction]
... proposal is doing this
... notion of capabilities
... connected things expose simple "traits"
... [Exapmles of Capabilities]
... Thing/Capabilities/Properties/Type/Actions
... Motion Sensor/Motion Sensing/Motion/Boolean/(read)
... is there an appropriate way?
... data point by the device
... high-level abstraction of the characteristics of the thing
... possibly 2 similar things from 2 different manufacturers
... [Different Layers of iotschema.org]
... quite high-level abstaction
... Data Types -> Interaction Patterns -> Capabilities
... [Available Resources for iotschema]
... resources here
... current schema location: http://iotschema.org
... working document and notes on google doc
... [TD RECIPES]
... what else could be done?
... even if we can query the AirConditioner...
... still some problem
... for users to be familiar with SPARQL and semantic models
... [Recipe]
... application templates
... to easily create WoT apps
... interaction patterns (events, properties, actions)
... and interactions (event A - action B)
... corresnpond to discovery and script generation, respectively
... [Recipe Example]
... motion detector light switch
... turn a light on when motion is detected in a room
... ingredients: MotionStatus Property, TurnOn Action, TurnOff Action
... interactions: SUBSCRIBE Motion Status, UPDATE TurnOn (or UPDATE TurnOff)
... graphical representation here
... TD interaction patterns and iotschema.org capability for ingredients
... implemented with W3C WoT scripting api for interacitons
... discovery and binding will be automtated
... [Example Recipe]
... JSON example
... @type: http://iotschema.org/MotionDetected (as interaction pattern)
... [Tool: Recipe WOrkbench]
... there is a tool for that purpose
... would demonstrate on Wednesday
... can save the template and distribute it

dsr: an example with sensor and light in a same room

da: explained very simple example
... you can add constraints to the recipe
... all the information will be taken into account
... the use is still included

<dsr> users could be asked to browse candidates and select between them based upon the contexr

ICA data profile - QingAn

qa: 100 of iot related companies
... ICA defines a data profile for various devices
... air conditioner, cleaning robot, etc.
... examples of air conditioner
... switch, wind speed, etc.
... [ICA Standardization - Connectivity]
... semantic vocabulary work
... would like collaboration with W3C

mk: semantic model based on iotschema.org
... thinking about how to reuse that
... we should clarify how to align this work

mm: how to line up things
... decompose the device's capability and get appropriate granularity

mk: W3C WoT provides recommendations for essential points

qa: main issue is which one is dominant

kathy: resource on that organization?

mk: you can send the slide and the resource of the organization
... we can add link to the agenda
... wraps up
... some more discussion possibly during the dev meetup later
... tomorrow we'll start with TD discussion

[day 1 ends]

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Katherine/Kathy/g
Succeeded: i/Kajimoto-san introduces/topic: Agenda
Succeeded: i/Matthias asks people/topic: WoT Architecture
Succeeded: i/Matsukura-san presents/topic: PlugFest Feedback
Succeeded: s/What is/Richard: What is/
Succeeded: s/... authorization/mk: authorization/
Succeeded: s/cases/cases?/
Succeeded: s/read/just read/
Succeeded: s/guarantee observable properties/guarantee event delivery/
Succeeded: s/@@@/to the report from the session on accessibility for WoT during the Web Conf last year/
Succeeded: s/Basic Facts about TD's FPWD/[Basic Facts about TD's FPWD]/
Succeeded: s/use/use?/
Succeeded: s/... example/sk: example/
Succeeded: s/layer/array/
Succeeded: s/Lamp"/Lamp")/
Succeeded: s/disover/3 methods: discover/
Succeeded: s/modifiers/builders/
Succeeded: s/Wtype/@type/
Succeeded: s/stakeholdeers/stakeholders/
Succeeded: s/impossible to reuse/possible to reuse/
Succeeded: s/mostly/so far mostly/
Succeeded: s/objective/objectives/
Succeeded: s/testing/validation and testing/
Succeeded: s/apps/many apps/
Succeeded: s/.. connected/... connected/
Succeeded: s/Exampes/Exapmles/
Succeeded: s/representation/representation here/
Succeeded: s/the based/them based/
Succeeded: s/rrsagent, draft mintues//
Succeeded: s/wrapps/wraps/
Present: tbd DarkoAnicic Michael_McCool Dave_Raggett Arnaud_Braud Kaz_Ashimura(W3C) Dave_Raggett(W3C) Michael_McCool(Intel) Qing_An(Alibaba) Sebastian_Kaebisch(Siemens) Kazuaki_Nimura(Fujitsu) Kunihiko_Toumura(Hitachi) Tomoaki_Mizushima(IRI) Kazuo_Kajimoto(Panasonic) Matthias_Kovatsch(Siemens) Takeshi_Yamada(Panasonic) Keichi_Tokuyama(Panasonic) Toru_Kawaguchi(Panasonic) Masato_Ohura(Panasonic) Uday_Davuluru(Innogy_SE) Andrei_Ciortea(Siemens) Kimberly_Garcia(Siemens) Bingxuan_Wang(China_Mobile) Yuichi_Hanada(Fujitsu) Takeshi_Sano(Fujitsu) Braud_Arnaud(Orange) Alexandre_Bertails(Apple) Fabien_Gandon(INRIA) Paul_Changjin_Jeong(HTML5_Forum) Barry_Leiba(Huawei) Bob_Bailey(Thomson_Reuters) Soichiro_Isobe(Access) Vagner_Diniz(NIC.br) Michael_Koster(SmartThings) Kathy_Giori(Mozilla) Wonsuk_Lee Daniel_Peintner(Siemens) Takuki_Kamiya(Fujitsu) Nickolas_Kavantzas(Oracle) Darko_Anicic(Siemens) Ryuichi_Matsukura(Fujitsu) Alex_Russel(Google) Yoshiro_Yoneya(JPRS) Yoshiaki_Ohsumi(Panasonic) Makoto_Odamaki(Ricoh) Shigeya_Suzuki(W3C) Juya_Yoshida(Softbank) Richard_Bair(Oracle) odamaki hirokias mlefranc Osamu_Nakamura(W3C) Barry_Leiba Michael McCool Daniel_Appelquist(Samsung/TAG) Hadley_Beeman(TAG) hiroki_asakimori
Found ScribeNick: dsr
Found ScribeNick: kaz
Inferring Scribes: dsr, kaz
Scribes: dsr, kaz
ScribeNicks: dsr, kaz

WARNING: Dash separator lines found.  If you intended them to mark
the start of a new topic, you need the -dashTopics option.
For example:
        <Philippe> ---
        <Philippe> Review of Action Items

Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA#Agenda

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: mkovatsc sebastian skbisch

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)