Group photo from the OCF/T2T/W3C joint meeting on March 23
Group photo from PlugFest March 24-25
Group photo from WoT F2F Meeting on March 26-19
(Some more photos are available online.)
The Agenda and the Live Notes are available on the IRTF T2TRG's GitHub repository and Google Docs, respectively.
<kaz> scribe for today: Kaz, Dave, Kajiwara, Daniel
<inserted> scribenick: kaz
-> https://www.w3.org/WoT/IG/wiki/images/3/3e/2018_W3C_WoT_F2F_Prague_Welcome.pdf
<kaz> next f2f in korea 30 june - 5 july 2018
<inserted> Matthias' Slides
Matthias: [Thing Description Sapporo
2015]
... (shows the TD 2015 version)
... [Thing Desription Montreal 2016]
... and then 2016 version
... domain-specific vocabulary, security metadata,
property/action/event, array
... entry points for interaction
... sapporo version had a single entry point
... montreal version multiple points
... hrefs there
... [Thing Description Now (1/3)]
... TD validator available now
... security work ongoing
... single entry point for interaction again
... new thing is data schema here
... semantic data schema
... e.g., iot:BinarySwitch
... discussion tomorrow
... annotate semantic information as well as syntax
... the other part is protocol binding
... [Thing Description Now (2/3)]
... some default approach here
... basics to build the request using "form" with "href"
... if you use some additional invocation
... deviation from defaults
... e.g., vocabulary for CoAP
... basically coap and also some OCF/CBOR content format
... can be understood by OCF implementation
... invoke action, write action, etc.
... pick up information
... [Thing Description Now (3/3)
... link from one thing to another
... web linking support within TD
... target will be another TD resource
... "rel": "controlledBy"
... e.g., motion detector
... how things are related with each other
... commercial building automation
McCool: possibly orchestration in addition to point-to-point connection
Zoltan: OCF has support for
containers
... wondering about relationship to that
... interaction would be different
Matthias: detailed discussion to be done during the tech days :)
(some more discussion)
Matthias: JSON representation for linking
by IETF
... text version link converted to JSON
McCool: anybody working on this?
... IoT use cases
Johannes: target is thing or interaction
Matthias: [JSON-LD 1.1]
... proposed Charter for a WG
... successor of JSON 1.0 by CG
... AC review until 29 Apr 2018
... we should clarify what our requirements are
... JSON 1.1 does have merits
... but we should focus on the AC review
... to get proper review
... detail to be done tomorrow
... proposed period 1 June 2018-31 December 2019
... should be aware of the reference for CR
... features we need to be kept in
... we should have strict use cases
... mandate from our viewpoint:
... make JSON-LD even more like idiomatic JSON
... using keys not arrays
... [@context #103]
... issue on the TD repo
... discussion with Mozilla
... very active though not participating in the WG
... we need to think about how to simplify TD
... one example is issue 103
-> https://github.com/w3c/wot-thing-description/issues/103 issue 103
Matthias: semantic annotations fully
optional
... we can easily handle this
... register TD-specific media type
... e.g., application/td+json
... preprocessing based on that
... how to convert TD to triples
... and also no restrictive conventions
... e.g., always arrays where possible
Sebastian: wondering about media type registration and versioning
Matthias: you can define td+json
... and then manage versions
Kaz: we should think about that
... there was version attribute in XML-based formats, though
Kajimoto: compatibility question
... currently using JSON-LD 1.0
... compatibility with the parser?
Kaz: how to use "@version"?
... to identify TD version?
Matthias: no, "@version" is to identify JSON-LD version
(some more discussion)
detail for tomorrow
Matthias: [Objects vs Arrays #111]
-> https://github.com/w3c/wot-thing-description/issues/111 issue 111
Matthias: triple representation
inside
... [base #106]
-> https://github.com/w3c/wot-thing-description/issues/106 issue 106
Matthias: lack of interoperability
... need for base URL in addition to TD URL as the base
... [@id/id #105]
-> https://github.com/w3c/wot-thing-description/issues/105 issue 105
Matthias: need for additional urn
... @id mandatory?
<inserted> Matthias: important to match security metadata in runtime
Dave: core model of WoT by RDF
McCool: default URI and additional URI
Matthias: all the tooling is there in semantic web
Danh: you don't need referenceable ID
everytime
... you can identify things using, e.g., Amazon id
Matthias: possibly from multiple
networks
... [schema #107]
-> https://github.com/w3c/wot-thing-description/issues/107 issue 107
Matthias: JSON Schema syntax
... some of the things could be simplified
... e.g., recursive properties
... schema information directly here
... how the semantic annotation needed for this?
McCool: reusing the existing mechanism
Matthias: reusing the modeling work
... [@type #104]
-> https://github.com/w3c/wot-thing-description/issues/104 issue 104
Matthias: type: boolean
... a bit inline with what can be simplified
McCool: similar capability with OCF data model
Matthias: [link vs forms #88, #108]
-> https://github.com/w3c/wot-thing-description/issues/108 issue 108
Matthias: discussion during the OCF joint
meeting as well
... relation from one resource to another
McCool: related to binary payload
... link is one way
Matthias: a bit different
... input data and output data
... could send binary image for action
... one of the concerns
... where is the convergence
... what are the properties?
... properties have links, actions have forms, event have
what?
... a bit more costly
... what are the events or resources?
... [Scripting API]
... entity description within TD and sub entity description
<dsr> Referring back to the discussion on @id, I would advise people look at W3C’s Best Practices for Publishing Linked Data, see http://www.w3.org/TR/ld-bp/ and the section on the role of good URIs in particular
Matthias: (TD example on the left side;
Scripting API example on the right side)
... thing.properties.on.get
... how to deal with TD
Zoltan: we already have an issue about that (on the scripting side)
Matthias: [SImplified Thing Description
with JSON-LD 1.1]
... proposal (work in progress)
Simplified WoT Thing Description under the TD repo
Johannes: used to be active within the WoT
WG
... established EcoG last year
... Electoric Mobility is coming and the pace is increasing
... [Fragmentation is the biggest challenges for a global
interoperable Infrastructure]
... electric power charging is getting more and more
important
... auto-OEBm charging HW manufacturer, shopping mall, charging
operator, fleet, utility, ...
... API-enable approach for that purpose
... [EcoG brings the App Economy to Charging]
... [Inspired by Android]
... [The API for EV Charging]
... API for various charging providers
... [Builiding Blocks of the Hardware Agnostic EcoG Software
Solution]
... SW-stack, OpenAPI, Platform
... EcoG: Bringing together the relavant
Expertise&Experience
... 3 experts
... [We figured out how to monetize EV Charging]
... [Today EV Charging is just Power Transfer]
... e.g., just 2 dollars
... [The Paradigm SHift in E-Mobility: Every Business becomes a
Filling Station]
... traditional gas station to EV filling station
... With the EcoG API every Business turns the Time to charge into
Extra...]
... [Integrated Customer Journey]
... with an EcoG API enabled Charge and Mobiel Phone App
... charging structure with users
... [Unlocking NEW Revenue Streams with the EcoG API business
integration]
... 2 dollars for each => 110 dollars for a super market, 80
dollars for a fleet operation, 12 dollars for a coffee shop
... [EcoG is moving the infrastructure business from boxes to
services]
... [EcoG Traction covers Pilot Customers across
different...]
... [EcoG API Business Architecture]
... ecosystem diagram
... integrating smartphones, smart wathces, etc.
... [Open IoT^h^h^h WoT API to integrate EV Charging]
... [Using Web Technologies for IoT & API Service
Development]
... broaden developer base
... enable the "long tail" market
... maybe there could be some killer-app for the main 80%
... but interested in the 20% long-tail part
... [Using Web Technologies to Secure IoT & API Services]
... web-grade security
... simplified integration
... [Expected Developer Experience make EcoG eeasy to use]
... low entry barrier
... broad community
... rich tooling
... [Two EcoG Demonstrator Sites for testing and project
implementations]
... EcoG Munich, GER
... EcoG Detroit, US
... based on WoT
... also proxy exposed for IoT
... bunch of customers
... Ford, Bosch, VW, ...
... very interested in feedback
Zoltan: reminded me of pysical web
Johannes: several stakeholders from
business owners as well
... running station at supermarkets
... multi-stakeholders there
... we provide/maintain the runtime
Milan: question missed
Johannes: rental cars, family cars
... public charging depending on the charging network
... make it simple for people to use
... possibly free charge based on the car manufacturers
McCool: key area for Web payments as well
[morning break till 11am]
<dsr> scribenick: dsr
We resume after the coffee break …
Matthias introduces Michael Lagally, Oracle
Michael works in the Oracle IoT group
I will review AWS, Azure, and Oracle (IoT Cloud service) in respect to the high level concepts, device descriptions, device models and so forth
Some definitions of terms for a common understanding …
Things, device descriptions, device models (device types/templates), properties, and events
First let’s look at Microsoft Azure IoT Hub
Shows a list of links for the background information
Device Twin is an abstraction of the device state. Actions and events are not part of the Microsoft model. Messages are lightweight. The device twin model does not support templates or aggregating multiple devices into a virtual device
Twins have tags and properties. There are 3 kinds of properties, desired, reported and device identity
Actions could be modelled in terms of posting a payload to a method endpoint
Actions can take arbitrary number of parameters
No dedicate event mechanism, but can be modelled as device to cloud messages.
Shows a slide with an example using JSON as a serialisation format.
Tags are metadata, e.g. the device location
Moving on to Amazon IoT Device Shadows.
Similar in creating cloud based representations of device state
Devices report their state using JSON messages over MQTT
Amazon device shadows have a version, a thing name, a thing type, and a set of attributes.
There is a registry to manage things. They have concepts for thing types and groups
Groups may include other groups
Attribute values are limited to 800 bytes in JSON, probably due to the MQTT protocol
The spec only offers simple types for attributes
However, you can use a rule engine that supports JSON arrays and objects
Actions are similar to Microsoft’s digital twins
Likewise for events.
Moving to Oracle’s IoT approach
Oracle IoT Cloud Service platform manages devices, messages and events
Device models are a blueprint for defining devices, and support simulations without the need for physical devices.
You can create virtual devices as aggregations of other devices.
A device instance is created by registering a device that implements one or more device models (registering with the IoT Cloud Service).
The IoT cloud service can be used to manage device models and device descriptions. We use JSON, but not Linked Data
A simple WoT TD to Oracle device models demo is available
Device models describe metadata, attributes, actions, formats and links
Devices are uniquely identifiable.
Attributes can have a range of types, excluding arrays and objects. Attributes can be read-only.
Our database analytics tools expect flat data, and don’t currently support compound data types
Oracle actions can only take a single parameter, if you need more, format them as a JSON string.
Binary data is a challenge for JSON based messages.
Formats define message payloads and are uniquely identifiable via URNs
Formats are classified as either data or alerts
Human readable descriptions are valuable
Names may include spaces, but that isn’t recommended
Shows an example of a device model in JSON
At the Plugfest, I showed a demo that provides a gateway between the Oracle IoT Cloud Service and the Web of Things Node-wot implementation.
IoT gateways provide a means to connect via MQTT, CoAP, etc.
Can support manual or automatic transformation between device models and WoT thing descriptions
The gateway can expose and consume things …
AWS and Azure only define a data model with no actions and events. The serialization formats are incompatible, none of the solutions define a protocol binding mechanism, this forces device manufacturers to create code for 3 different environments
A unified device model would simplify integration across different platforms and accelerate market adoption
Sebastian: are the plans to add support for compound data types to device models for Azure, AWS, Oracle?
Michael: don’t know about Microsoft and Amazon, but no customer demand for Oracle IoT Cloud Service
The resource limitations are relaxed for apps running on gateways as opposed to resource constrained IoT devices
Dave: can you say anything about Oracle’s support for graph databases, and processing for Linked Data for greater flexibility?
Michael: no
Darko: why haven’t manufacturers driven work on shared models?
Michael: I would say that everyone has developed their own approach independently
Dave: do you see the likelihood of convergence for Web protocols (gateway to cloud, cloud to cloud) as proposed by Mozilla and EVRYTHNG?
Michael: that is the likely evolution, yes
Johannes: what would motivate cloud platform providers to adopt the Web of things?
Michael: Platform providers will adopt what their industrial customers ask for
<Zakim> kaz, you wanted to ask if there are any specific requirements for TD
<kaz> ml: some idea but detail to be discussed later
<inserted> Soumya's slides
Presented by Soumya Kanti Datta, EURECOM
Soumya introduces Eurecom and F-Interop, and their work on testing for the IoT
Interoperability is key for achieving the full potential of the IoT
Semantic interoperability is a way to solve interoperability across heterogeneous data sources, formats and models
SemTest, an industrial extension of the H2020 F-Interop project for work on testing semantic interoperability
This covers lexical, syntactic and semantic checks on messages
Checks at the communication level, lexical/format checks, and data processing checks
SUT = system under test
Question: are there any examples of commercial systems that embody semantic interoperabilty?
Soumya: there are several EU projects that claim to do this
Dave: I want to mention the work by the AIOTI on white papers on semantic interoperability, with a paper from 2 years ago and a new one aimed at developers in preparation - contact me if you want to get involved
Soumya shows a diagram with two connected systems under test
Some discussion about semantic processing involving SPARQL queries
<scribe> New diagram with a Query server positioned in between the two communicating systems under test.
n.b. in regards to the previous talk - RDF Semantic Graph is a W3C standards-based, full-featured graph store in Oracle Database for Linked Data and Social Networks applications.
Soumya: the key is to demonstrate semantic interoperability through explicit semantic modelling
We’ve done some work with oneM2m (see slide 11)
MichaelKoster: applications can interoperate through using the same terms, or through adapting to differences between models
Dave: one approach is to use abstract upper ontologies to relate different models, but this is expensive due to mapping terms to abstract atomic terms, another is to map models at a peer level, this involves conditional rule based transformations
Souyma invites us to fill out his survey (see slide 15)
As of know we (Eurecom) are implementing the tests within the F-Interop platform
Dave: F-Interop is funding a relatively short term effort on testing for the Web of Things, and I would like to talk to people here at the Prague meeting for their ideas on how to proceed
<Ege> Can you repost the survey link
https://goo.gl/forms/h3wgsyOpztxA3lSG2
Matthias encourages work on testing
<inserted> [lunch till 2pm]
<kaz> Milan's slides
<inserted> scribenick: ryo-k
Session: Semantic Annotation and Handling of (meta)Data in IoT Information Models
<inserted> Milan Milenkovic gives his talk
examples to be shown are taken from actual examples
digital transformation is needed, but current IoT standards are inadequate
what and why, not how
Commercial buildings (having 10s of thousands of sensors)
multiple systems, but not interoperable / not reusable semantics
<inserted> scribenick: ryo-k_
Problems and IoT Solution?: pre-internet... error prone (up to 30% error rate!)
very cryptic, only very people know how it works
need/want: portable services, attribute-based searches
"you can't do searches on IoT without semantics"
semantic annotations provides how the thing links to another things, relations to others
[Sensor data and meta-data use]
Haystack notation example
dis stands for display
One thing to like about Haystack: tags are crowdsourced (in the building management community
list of available tags -> pick as many of them that are useful
Rich metadata allows to add new sensors and integrate it without rewriting script
"Enables" attribute-based search (you can't do without it
How to handle metadata?
[Some Learnings and Observations]
Some of the metadata are static, rarely changing
variable metadata key value pairs in info models / separate APIs/queries to fetch static metadata as overlay
Descriptive, not Prescriptive
Dave: This analysis may help to convince people of different domains to standardize metadata
Example app: Finding rogue zones (too hot or too cold)
BMSs generally do not install rogue zone detection
(algorithm) Get all zone IDs, get zone sensor for zone, get setpoint, if difference > threshold then it is a rogue zone
sometimes 10%-50% rogue zones are found (actual results in Berkeley
What do you need to have in Metadata schema? -> looked at published smart-building apps, classified them, find relationships among entities
User input is important
Some applications only use part of the relationship. the parts are different among types of apps
Uncertainty in the metadata
compared Haystack, IFC, Semantic
Semantic sensor networks: (+) Flexibility, (-) Completeness
Take actual applications, analyze them and find what is needed
Dave: There are things can't know in advance, but can we use AI (predictive) technology? -> works maybe for historical data
BIM describes the design intent
iot.schema.org
Motivation: many standardization organizations, many cloud providers with their own notation -> we need some sort of semantic interoperability
What needs to be built? -> well known formats to describe semantics
"capability"
= set of affordances needed to interact with a device
Feature of Interest pattern
IoT needs to interact with physical objects
FoI largely overlaps with schema.org
example: LightControl capability
iot: providesInteractionPattern
all interactions are optional (= not prescriptive)
Lagally: : Q: How do you describe relations between interaction patterns, eg. TurnOff should not be with SetColour? -> The schema does not forbid those settings, this is implementation dependent
Can put restrictions on top of this schema
These restrictions can go into thing description
<kaz> (discussion on "Example: LightControl Capability")
State machine to describe state -> can also be used to forbid certain actions. / but not part of iot.schema.org
@3: How many domains are targeted? -> few. tens, not hundreds
Can mix other capabilities into a capability
Example: SetDimmer Interaction
data level is optional too
thing descriptions mostly differ in data level
(eg: Air conditioners having different temperature range / units)
<kaz> Darko's slides
What's new
schema contains more terms, has more users
proposal of how to use shape constraints
Events are being specified
<kaz> (slides 11)
attributes "writable", "observable"
How you are supposed to use iot.schema.org: example: discovery
How to ask ThingDescription Directory to find "an" air conditioner, not a "specific" air conditioner?
If well-known term exists, then it can be used -> that's what iotschema tries to do
search a term on iotschema.org, find a capability
"Air conditioner Capability"
2nd use case: automatically generate TD Templates
Pick certain terms that our thing should implement (shape constraints for thing) -> generate TD
such tools already exist for schema.org -> let's make one for iotschema
Why shapes are needed? -> they allow us to create variations between things with same capability
Example: one smart light has only "SwitchStatus", other smart light has "CurrentDimmer" "TurnOn" etc.
Shape templates provides a "fill-in-the-blank"-like template
<kaz> [[
<kaz> http://www.w3.org/2018/03/wot-f2f/slides/2018-03-26-W3C-WoT-F2F-Prague-iotschema-v2.pdf
<kaz> Light-SmartThings-TDTemplate.jsonld
<kaz> ]]
3rd use: TD recipes
Recipes = semantic templates for mashup applications
also JSON-LD documents
they allow automatic discovery of thing descriptions, they allow script generation
All steps except implementing application logic is automated with a "recipe"
<kaz> Matthias: asks Darko for explanation on what the objective of the Reccipes, what it provides, etc.
[Demo: OverflowProtection] -> What is the recipe in this case?
Recipes are declarative
(the parts in yellow is the recipe; thing 1 and thing 2 has functions implemented; the discovery provides the "arrows" in the diagram)
<kaz> fyi, minutes from the Mar-16 LD call
<inserted> Kaz: I also asked you to clarify what the "Recipe" was like during the LD call on March 16, but today's main point is not recipe itself, so please move ahead and talk about the main point (semantic interoperability using iotschema.org)
Work plan:
restructuring of iotschema.org, online version of TD generator, demo of applicability in other models like IPSO smart objects/Amazon IoT/TD from Mozilla and EVRYTHNG etc
McCool: Similarities with OCF and Amazon IoT(Alexa skills) are interesting
Toru: : Applicability to ECHONET. how to participate in development?
Darko: We still need to clear process to contribute, but can start contributing on GitHub (github.com/iot-schema-collab)
<kaz> Kaz: as put on the wide sheet on the wall, some of the PlugFest participants already tried semantic annotation using iotschema.org, so you should work with them
Danh: How to add concept like in schema.org?
Darko: If existing concepts not working: find concepts in other specs like OCF, take their resource type/concepts
Feature of Interest may make things worse, they may be arbitrarily implemented/defined
ThingDescription is also influenced by other specs (like in iotschema.org
<kaz> Kaz: given the purpose of this work is semantic interoperability, we might want to think about one specific scenario including multiple vendors, one from OCF, another from oneM2M and yet another from ECHONET, and think about how to use semantic annotation by iot.schema.org for interoperability
(discussion on how to correspond concepts in OCF/iotschema/ECHONET/etc.
<kaz> ari: wonders about the threshold to add entries to iot.schema.org
example: Presence sensor: one uses motion, but others may not use motion, how to describe them?
short answer: make one
but still needs an abstract term ("occupancy"? that is independent of motion, etc)
<kaz> scribenick: kaz
Kaz: many people are interested in
this topic (semantic interoperability), so how to continue the
discussion?
... main call, LD call, PlugFest call?
darko: already discussion within the LD call but need to report back to the main group
Matthias: need some executive summary as well
milan: ask about the work within WoT WG
Matthias: explains the WoT Charter mentions
the mechanism
... e.g., Schema.org
danh: we should have one "place" for the discussion
darko: we want to have definition of simple feature of interest with iotschema.org
[break till 4:30pm]
-> https://github.com/w3c/wot/tree/master/plugfest/2018-prague/PlugfestSlides PlugFest slides
<dape> scribe: dape
<scribe> scribenick: dape
<inserted> -> slides tbd@@@
Jose: work for FIWARE
foundations
... ETSI API specification
... ETSI ISG has mandate to establish info exchange layer
... smart cities is main domain
... there are many mores
... IoT is very important but not only source of information
... Mission: link all data sources
... to make it easier for end users/databases/.. to exchange
information
... idea is to create common API ... in "Context Information
Management"
... does not mean that there is single instance
... extra metadata can be exchanged in different systems
... Example: multi-modal transport ... for example google
maps
... there are other applications/formats
... how to enable such open systems (from different sources)
... goal: keep it simple and achieve:
... * API for developers
... * minimal complexity
... * breaking silos
... * enable data sharing
... Work on Information Model
... core concepts: Entities, relationships having properties
... also have query language
... example: Police report an accident
... car damages lamp
... involved are vehicle and LegalUnity
... ids for vehicle and legalEnitity (police)
... moreover, the damaged lamppost belongs to the municipal with
additional information
... information are published, can be subscribed, consumed
etc
... how are these elements represented?
... JSON-LD is used
... we defined context
... additional terms can be added
... 2 types of nodes
... type "Property" and "Relationship"
Lagally: Who manages IDs?
Jose: Should be managed by each entity (data owner)
Ari: How to discover those IDs?
Jose: query system at certain
location.. et cetera
... Assumptions
... * API is agnostic
... * use URIs to identify
... Possible architectures: Centralised, Distributed,
Federated
... Information model has 3 main concepts: Entity, Relationship,
Property
Lagally: Question, where is clock?
Jose: time for "observedAt" is
example provided by source of data
... Queries, why don't use SQL, SPARQL, ..?
... every database has different approach
... we have flexible subset of queries
Sebastian: Wonder why SQL for example does not suffice needs...
Jose: Do not want to be bound to
SQL...
... want to be flexible
... there are some pre-defined queries (by id, by equality,
...)
... nice to have also queries by geo locations
... API also allows to so Subscription
... similar to query... get informed if a certain condition is
met
Victor: is there RDF representation behind context? File does not seem to exist
Jose: Correct, is not there yet but
can be retrieved from XXXX
... Also ask for formal feedback from working group
... plan to finalize API specification within this year
... work on API introduction for developers
... also tackle security and privacy
Kaz: There is already official
relation between the 2 groups
... want to do a more concrete one between the 2 groups
<kaz> W3C Liaison table
Matthias: 2 things I see
... w.r.t. query I would like to know how powerful the language
is
... e.g. pointer to thing directory, also used in OCF
... in IETF it is registering web things
... SPARQL could be one of this complex query languages
Dave: interested in graph model
... lead of data activity... includes looking at model
... can talk about this later
Matthias: Also you specify data that gets
send around..
... could be good test for WoT
Daniel: Wonder whether there is practical exploration
Jose: There can be many issues, need
to solve security issues
... also there is previous work..
... document database vs graph models
Matthias: Did you look into how to scale this solution?
Jose: we have research experience in
distributed deployment
... no "real" experience...
... centralized approach can work but the goal is distributed
approach
Lagally: Is the assumption to use GSM network?
Jose: no. it is network
agnostic
... Next steps: 1. queries. 2. is time
... also resource directory pointer
Kaz: also possible to join PlugFest
demonstration
... beginning of July Korea, October TPAC
Matthias/Kaz: will look into liaison
<kaz> [briefly mentions the procedure for liaison and actual collaboration]
Jose: collaboration would be desirable
McCool: would like to mention what we
are doing for security
... Issue:
... * many different sec auth schemes
... * interactions may have multiple forms with different
protocols
... Basic Example:
... have basic configuration section
... we also look at OCF, what standards do they use
... do we need all that is used there?
Milan: what is meant with "security" in TD?
McCool: security metadata
... put minimum we can
Matthias: Also telling you where to get auth token
McCool: Please look at .../wot-security/ directory
Matsukura-san's Summary Slides
Matsukura: 5 demonstrations
... first of all thank you to all PlugFest participants and Oracle
hosting PlugFest
... we had more than 20 peoples
... many servients (yellow: application servients, blue: device
servients) [see slides]
... red boxes show support of iot schema
... please check also on github whether figure is correct
... various viewpoints:connect with remote/local proxy
... security, Scripting API
... device simulators
McCool: eventing is yet another thing we might want to add
Soumya: Two connected cars
... accessibility scenario
... 2nd demo: smart home and connected car scenario
... <showing video>
Johannes: Servient running on car?
Soumya: external device...
Sano/Matsukura: servient in 3 locations: Cloud, Japan,
Prague
... showed long polling and event handling
... NodeRED (application) controlled device in Japan
Nimura-san: Scripting API
... LED lamp has on/off only
... script adds capability fadeIn/fadeOut
... also worked with Siemens
... injecting scripts is possible
Kawaguchi: smart house demo
... worked also with Fujitsu
... Echonet gateway
Matthias: Fest plant with small CoAP
devices
... valve can be opened ... goes to tank ... there is also pump
from lower to upper tank
... have sensors watching water levels
... in Munich we had proxy... connected to Oracle IoT Cloud
<Darko shows script talking to Oracle cloud and acting on Fest plant>
Lagally: <showing Oracle IoT
simulators>
... created digital twin based on provided TDs
McCool: I had several things
... OCF smart home instances wired up
... gateway talks CoAP
... make generated TDs available on the fly
... OCF devices available as WoT devices
... also used web camera... with eventing... changing
exposures
... binary data (images) was use case
... long polling was implemented
... voice service was implemented also (Amazon alexa)
<inserted> scribenick: taki
<inserted> Matthias: Are there any conflict for June 30- July 5?
<kaz> (no objections)
<inserted> Matthias: Good.
RESOLUTION: the next F2F will be held in Korea on June 30-July 5 (June 30-July 1 for PlugFest)
McCool: Let's plan for next PlugFest.
... In the afternoon, discuss security metadata.
... Outline. What we tried. What's issue...
... Intel: Two exposed Things.
... local https. Basic auth.
... Not used by anyone else.
... using metadata proposals.
... Siemens. Https + basic auth.
Mattias: and bearer tokens
Matthias: proxy support. forward
proxy.
... and reverse proxies. (things only reachable through
proxies)
... used oracle instance.
... disabled cert check using config flag.
... last plugfest, used bearer tokens with Fujitsu beacon
light.
Soumya: I used https. TD was
encypted.
... It was a plain encryption.
... securoty of Thing itself is under development.
Yamada: Https + bearer token (jwt)
Kawaguchi: Global endpoint.
... Let's encrypt. local http only.
Matsukura: Fujitsu used
https.
... proxy supported https.
... locally http only.
... https supported locally, but turned off for plugfest.
McCool: I will put this up to
Github. people can edit it later.
... and I will create a survey.
McCool recaps what we did in Plugfest...
McCool: Issues such as protocol
error. Probably due to firewall etc.
... Worked in hotel but not at Oracle.
... network disconnection. self-signed certification. those
were also issues.
Kajiwara: we try to enable local
device. using local CA.
... It is a CG work.
... HTTPS Local CG.
McCool: only limited set of
authentication schemes. Only basic auth and beaerer tokens
(jwt).
... Incomplete metadata. Those were issues.
Kawaguchi: cross-site scripting
issue.
... Browser prevented us from using cross-site scripting.
Matthias: Was that your own servient?
Kawaguchi: We allowed it. Proxies
did not.
... I used Chrome.
... I had problem when I used TD.
... Advanced ACE.
... Node-Red did not have problem.
Matthias: Chrome behaved
correctly.
... Copper under firefox was not working.
McCool: I also used curl.
Matthias: Scripting issue. therw was not an issue in fetching.
McCool is creating a slide on scripting API issues...
<kaz> -> McCool's slides tbd@@@
McCool: cross-site scripting
issue specific to using WoT scripting API inside browser.
... "Dashboard" app trying to connect to Things that was at
different location.
... any other issues?
Zoltan: ACL is implemented. Need to do provision manually.
McCool: Next plugfest plan. what
do we wanna do?
... security metadata.
Matthias: 30 June and 1 July.
McCool: We need to be done by 1
June.
... We need to create a consistent security metadata set.
... by then.
... we need to try more authentication strategies.
... OAuth2, wider use of bearer tokens.
Matthias: Pop tokens (at least as a 1-1 prototype)
Elena: API keys
McCool: Basic auth
Barry: digest and basic auth.
what's different?
... digest and local authentication should be used
together.
McCool: OCF is based on
ACE.
... metadata for ACE, and OCF. entry points, roles, etc.
... we also should try non-OCF implementation as well.
Matthias: I have implemetation in
node.wot.
... It is work in progress.
... coap implentation in node is fragmented.
<ryo-k> fyi: web page for httpslocal cg is here https://www.w3.org/community/httpslocal/
McCool: First we define metadata, then need to implement.
Matthias: Can you share OCF ACE information?
McCool: authentication server, certification server. ACL.
Matthias: OCF tends to depend on IETF standards.
McCool: Discussion in IETF T2TRG is necessary.
Ari: Lightweight M2M.
McCool: We are gonna have
lifecycle discussion.
... we have lifecycle diagram.
... it has implication on security.
... we have been focusing on operation phase.
Kajimoto: we need to analyze the gap between security document and the issues we now have.
McCool: we still need to do
general discussion.
... Testing validation strategy is related too.
Kaz: We need to clarify requirements before analyzing the gap.
McCool: general discussion first,
then concrete discussion.
... for now, practice first, then generalize.
McCool presenting on Security metadata proposal...
McCool: Issues with current
assumptions, goals and requirements. We need disucission.
... I present strawman proposal
... I generated concrete examples.
... issues.
... different authorization schemes in one Thing.
... different entry points, roles, management styles. etc
... RAML, OpenAPI have this. different authorization scheme in
one thing.
... I made those assumptions.
... We need to discuss whether or not this is a
requirement.
... security interaction patters
Matthias: TD says how to get authorization. role is in token.
McCool: I try to describe
existing mechanism.
... We can validate assumptions llater.
... OpenAPI supports multiple strategies, multiple entry
points.
... we do not want to replicate configuration definition.
... we give a name. and use it elsewhere.
... we can share configuration between interactions.
<kaz> security pullrequest 86
McCool: AND-OR combination scheme.
Elena: we need use cases.
Matthias: When proxy is there, we do not see OCF device behind it.
Elena: OCF is in local network, and has its own authentization mechansm.
Matthias: one thing, how can it possible to support multiple security systems?
McCool: coap and https.
... OCF device with coaps and https.
... We can use OR operation.
McCool showing examples...
McCool: Security is an
array.
... each has @id and "scheme"
... each interaction has "security" field referencing id such
as "ocf-config".
... Proxies.
... proxy configuration and endpoint configuration. we can
define both in "security".
... OAuth is a bit complicated.
McCool showing OAuth metadata definition...
Matthias: we need to check what we really need.
McCool: We should not repeat
information here if it is processed somewhere else.
... i tried to make metadata definition consistent with
existing system such as OpenAPI.
... I will keep updating the proposal.
... There are open issues. compatibility with JSON-LD.
... list of supported security mechanisms. what's in and what's
out.
... validation issues. combination of parameters.
... there can be invalid combinations.
<kaz> security metadata document
<inserted> Kaz: wondering about the proxy/gateway use cases. Do we want to think about server capability within TD as well?
Matthias: We need to be careful what we define for gateway use cases.
McCool: we first should focus on what we need.
McCool is showing detailed specification section...
McCool showing various examples...
McCool: presentation is just a
summary.
... for now 5 schemes are listed.
... each scheme can specify relevant protocols.
... API key is a blob. Bearer tokens have structure.
... OpenID and inter-ledger are interesting.
... Please take a look at the proposal document, and provide
comments.
... I created issues in Github.
... for open issues.
... such as versions for security schemes.
Kaz: Do we really want to use "OCF Security Model" as a categor?
McCool: it is scheme="ocf"
... It is work in progress.
Kaz: given other entry names are technology-based, maybe "ACL-based security" or "SDO-specific security" which includes this (=OCF Security Model) as an example
Sebastian: should we keep discussion separate from TD vocabulary discussion?
McCool: whether common or specific to schemes. It depends on this.
Matthias: extension points need to be defined in TD.
Sebastian: common part needs to be discussed in TD call.
Matthias: binding should be discussed in security call.
Dave: abstract model can be
discussed in TD.
... we need a framework around TD.
<kaz> [break until 11:15am]
<ege> scribenick: ege
Kawaguchi-san: this presentaiton
will be about presenting examples of interaction sequences, not
a new standard
... no clear description of end to end sequence and
inconsistency among spec drafts, e.g., WoT Architecture, WoT
Thing Description and WoT Scripting API
... I only have HTTP prepared so my example will be based on
that.
... Describing an example of HTTP get request with scripting
api (sending the request, getting a promise as a
response)
... Similar example description with an HTTP PUT request
... Now some new stuff, especially for the plug fest: HTTP long
polling
... Sending a get request and getting the answer once the
server device detects a change and sensds a response
McCool: question on long polling
Matthias: What you asked is more about multi-XXXX and not actually long polling
McCool: ok. (to kawaguchi-san) what is a change , what is a previous state. What happens if you have a request during a change
Matthias: That would be more like a bad implementation
McCool: I would think of getting a previous state in order to understand if there is actually a change
Matthias: what is the actual problem
McCool: What if I have the value 0, it changes to 2, there I subscribe and then it changes to 1 and I get that value so I miss the change to 2
Matthias: If you implement it right there shouldnt be such problems
Zoltan: We are not interested in making precise time stamping problems etc.
Matthias: There is a way by using
cookies. First get you store a cookie as a server and the
second time it gets a GET request it blocks it
... I wanted to the client side of long polling in node-wot for
long polling during the plugfest but didnt have time
McCool: I wanted to implement both server and client side with node wot (SAID BEFORE THE 11:37 Matthias)
Matthias: There is also another pattern where even if you dont have a change you send something saying that hey Im still here
Koster: We can all agree that observable properties is event type
Ari: http, using different resources
Matthias: If a device is already existing, you cannot impose to put a timestamp
Zoltan: what about putting timestamps in responses
switch the order of 11:42 and 11:43
Zoltan: but the scripting should expect behaviour
Matthias: CoAP has the observe clock
Kawaguchi-san: Now simple web
socket that has been implemented by Siemens
... presented the slide
Matthias: this is simple
websocket so you need to define the underlying protocols
afterwards
... (After a question of McCool) we cannot think what is the
application use case
Dave: What about if I want to send 10000 property update a second
Matthias: Then you should events
McCool: My thinking is that simple things should be simple
Dave: yes but complex things should not be impossible
Matthias: but you can already do that
Zoltan: (explained how you can do it)
<ryo-k> Series Transfer Pattern: https://tools.ietf.org/html/draft-bormann-t2trg-stp-00
Koster: There is an IETF draft by bormann that can help about it
Kaz: What is the difference between slide 4 and 5 from the slide design point of view? the difference between the possible event handling mechanisms (and important points) should be described in addition to the diagrams themselves
Kawaguchi-san: I have found this action pattern and I have found this invokeAction method
McCool: return codes of actions
Matthias: there is no current XXX about having Hypermedia control kind of stuff
Zoltan_and_Matthias: It should be such that you get status or TD or whatever and from the information you learn what you can do with it
McCool: Scripting API should be protocol independent
Matthias: It might be good to
have something in the TD that says that I will do this
action
... Then it proceeds on doing the action. In the meantime you
can still access the server. In the example of a cleaner, the
action could take 2 hours and then respond and all this time is
sort of not used.
... you cannot have two different implementation of a request.
You cannot have one where it tell you that it will do the
action rightaway and another that starts doing the action and
then responds. It is possible but way simpler to pick one
McCool: (before Matthias' answer he asked something about having two version described in the TD)
Matthias and Sebastian: (in response the Koster's question) this type of flow should make it easier to people to understand the difference of action and properties
Kawaguchi-san: Now event
patterns
... There is a github issue on how to use property action
event
McCool: We need to see how MQTT works, maybe Michael has something to do with that
Sebastian: I would like to see
CoAP in the observe patterns
... I have a student working on MQTT for Web of Things, I can
provide input later on about it
Kawaguchi-san: This is mostly to illustrate and to say that everyone is ok with the action patterns
Matthias: we dont do discussions on "architecture", we do specific topics, e.g. terminology is a part of architecture
Matsukura-san: (a question on what about proxies that we have introduced in plugfests)
Kawaguchi-san: I think we should do another slide where we merge proxy and basic intereactions
RESOLUTION: both Panasonic diagram on the basic interaction and Fujitsu diagram including proxies can be included as part of the appendix (after some cleaning-up)
[break until 11:15am]
Matthias: Presenting property definition in the terminology. it is updated
Dave: What about the observable aspects, is it described somewhere
Ari: What about write only
Matthias: That would be modeled by actions
Barry: What if someone cant read it because of access rights
Matthias: That would come from the orthogonal security aspects, it shouldnt be mixed with property deifinition
Taki-san: What about previous states
Matthias: You can have it in the
application layer and model it by an array
... I understand this might be needed, can you bring a use case
to discuss
McCool: Or an action to get the history
Barry: or use blockchain!
Matthias: (After a question from Lagally) If you want to model something, start with property, if you cant model pass to action, if you cant model it, pass to events and only after that if you cannot model it then we can talk about having a 4th interaction pattern
McCool: What about state transitions ( EGE: didnt get the discussion about the state machine etc.)
<kaz> Kaz: wondering if all the "properties" (or rather members/fields of TD) need to be exposed, or only exposed ones are called "properties"
Dave: What about generating events in the client
McCool: You can do it with actions
Dave: yeah that is a workaround but what about the concept
McCool: an action with semantics
Dave: No that is a workaround. What if there is a usecase that we dont know that can be modeled only with a client raising an event. I am not saying that there is one and that we should add something but more like raising the a question
Matthias: You want a P2P network
that you can do with things being servient
... the initial definition of action had the idea of doing a
physical change
McCool: Maybe actions should be not only about internal state because maybe i dont care about the change of the internal state but the result of the action that is something about the physical world
Milan: I dont think you should call strong consistency in the event delivery. You should either say best effort or guaranteed delivery. Strong consistency is a bit ambigous
Public: people agree on what Milan says
Matthias: So what are the use cases of read only, writable and observable properties
<kaz> [lunch till 2pm]
Matthias: I didnt have time to explain the updates
<kaz> scribenick: kaz
<inserted> -> Victor's slides@@@
Victor: new features from JSON-LD
1.1
... for the sake of the following discussion by Sebastian and
Matthias
... syntax, etc.
... [Objective]
... define the transformation
... to RDF
... using only standardized procedure
... 3 possible steps
... set WoT context if not present
... default values
... transformation to RDF
... [changes]
... default values
... getting rid of arrays
... couple of other changes
... key-indexed interactions
... JSON Schema syntax for Data Schema objects
... relax of the constraint on arrays
... for @context and @type
... for easier implementations
... [Default values]
... [Key-indexed interactions]
... we use "name" to identify interactions
Matthias: what does "framing" mean?
Victor: several possible
representations
... compact one, nested one, etc.
... all the formats are expected to be equivalent
... based on the same RDF model
... TD is normalized format we're looking for
... framing algorithm for defaults
... second thing is key
... representing interaction
... where the key is the identifier
McCool: link to other places?
Victor: "name" here is not equivalent
with the one from RDF
... still some open issues
... provided use cases
Soumya: app servient wants to parse it?
Victor: easier for an object to use arrays...
Matthias: parsing problem and accessing
information
... software object identical with TD structure
... codes are iterating
Victor: this is what our JSON Schema
is defined
... open api also uses that
... [JSON Schema syntax]
... "fields" before "name" and "schema"
McCool: "prop" could be name of some property
Taki: @@@ prohibited?
Victor: reusing JSON Schema
... properties come from TD properties
... separate question
... another proposal for that
Matthias: let's focus on what JSON-LD 1.1 is like
Dan: W3C itself should make decision which to use
Matthias: if we go down to the path
(1.1), what is the requirements?
... complexity?
... key is nice applicable feature
... AC review for the proposed Charter
... JSON Schema is independent from JSON-LD
McCool: what are our use cases?
Victor: framing is the most important
feature
... there is no easy way without that
... on the other hand, many people have started to use JSON-LD
and found problems
Matthias: regarding dependency
... syntax and semantics
... discussion during TPAC2017
... adapt to new concept
... being clearer
Sebastian: like the change (e.g.,
framing)
... interested people could provide use cases
Matthias: we should go through the changes
Victor: [COnstraint on arrays]
<danbri> JSON-LD charter is before W3C AC for review (https://lists.w3.org/Archives/Member/w3c-ac-members/2018JanMar/0054.html - member only link). Draft charter is (public link), https://www.w3.org/2018/03/jsonld-wg-charter.html
Kaz: left side and right side?
Victor: possible usage here (not left as 1.0 and right as 1.1 here]
Matthias: TD directory should support
this
... how to deal with this convention?
Zoltan: array for "@type"?
Matthias: you can do that
... the parser would handle it
Victor: if you use other JSON-LD convention, other could have string, etc.
McCool: restriction for small devices?
Matthias: kind of education
needed
... could be an array
Victor: [Issues]
... a couple of issues
... identification
... WoT convention, JSON path, RDF normalization
... Base URI
... use of JSON-LD's "@base"
... use of TD identifier
... [Identification issue]
... in both JSON-LD and JSON Schema
... there are properties and actions
... using "id" is JSON-LD 1.1 convention
... having "uuid" for some id
... if there are 2 identifications, would have id conflicts
McCool: observe tag?
Victor: "id" is yet another URI
McCool: relative to where the TD
is
... may or may not be same
Victor: possibly other kind of
IDs
... #properties/example/schema/properties/id JSON Path
... not sure how they handle it
... this is not part of the JSON-LD spec itself
... 3rd alternative: hash://md5/9f86d081884c7d659a2feaa0 RDF
normalization (randomly generated)
... common with temperature, etc.
Kaz: who handles the hash
ID?
... possibly TD directory?
Victor: possible option
... also every agent may also expose the ID
Barry: new hash schema?
Victor: took from some proposal
... there are different ways there
Barry: talk about that later
Dan: RDF hash would make
sense
... ":hash"
Barry: talk about later
Victor: [Base URI issue]
... how to declare TD
... how JSON-LD is defined here
<danbri> discussion of http://json-ld.github.io/normalization/spec/
Victor: just add "@base":
"urn:wot:myThing"
... we could specify within the TD spec
... only has the space as the key
... in this case
... urn:wot:myThing/example WoT convention
... this is something we use
... might need access control
... submitted to the JSON-LD CG
... but pushed back
Matthias: why out of scope?
Victor: require some
preprocessing
... we could continue to use option with JSON-LD 1.0
Matthias: discussion on the
pre-processing stage?
... could also take the base id to fill the content
Victor: possible solution
Matthias: nice solution is
... this is TD-specific
Victor: this "@base"
"urn:wot:myThing" would be put on the array if used for
TD
... wanted to show this diagram...
McCool: we actually see them?
... or transformed results?
Victor: put into the TD as soon as the property is processed
McCool: how would a big ugly hash work?
Matthias: if you input extra document
which is located somewhere
... you don't need the hash itself
McCool: possible human-readable
id?
... in a form
... as alias
Kaz: possibly additional "display name" or "exposed name"?
McCool: within the document for the
developer, the id should have a human-readable alias
... most users don't handle that
Victor: could be possible
... [diagram of DataSchema]
-> @@@url of Victor's DataSchema diagram tbd
Dave: extended diagram for
DataSchema?
... used for multiple times?
... we can make it easy to use that so
Victor: all the data included in the DataSchema
Matthias: it's possible
Victor: we can reuse it once it's defined as part of DataSchema
Matthias: those are small
extensions
... basic building blocks
McCool: some use case on binary
data
... extend the Schema for that?
... media-type knows about that
Victor: anyway requires container
McCool: what if it's empty?
... leave it out?
Kaz: clarification on the colors
Victor: yellow upper nodes are JSON
Schema
... green lower nodes are TD extensions
... [another diagram on SenML]
... binding templates spec
... interaction for properties here
... (goes through the diagram)
... abstract model regardless of the serialization
Sebastian: comment on the current TD ant
this model
... for the future
Ari: just a future example?
Victor: yes
... [yet another example]
... provided by Matthias
... battery->schema->0.0.100.0
... we can input this into the doc
... I'm done
McCool: min/max?
Victor: wanted to explain that kind of detailed but couldn't due to network connection
Matthias: "rssi" property
Victor: (shows the TD draft)
... (rawgit version)
Matthias: (explains the example)
... example 2
Zoltan: multiple ranges?
Matthias: whatever complex types
... might want to talk with the JSON Schema guys
Dave: arrays in JS 1.1
... order or unorder
... maybe unordered one would be less costly
Victor: JSON-LD?
... already covered
McCool: 1.0 as well?
Victor: yes
... just RDF list is used regardless of whether ordered or
not
Matthias: what JSON-LD 1.1 could bring
to us?
... is this something we want?
... should follow 1.1 version?
... note that we could be delayed by using 1.1 version
... this could be raised within the AC Review for the proposed
JSON-LD 1.1 WG
Dave: would be good to join that group as well
Matthias: will look into this
Dan: some awkward characteristics
on JSON-LD
... you need @context
... a bit awkward
... not sure this group really should add anything to their
work
Victor: this work should be standardized
McCool: 2 comments
... our schemes fixed??
... any applications
... larger scope for IoT
Dan: when the RDF model group had
discussion
... still questionable for this group
Lagally: when the draft would be
published?
... we want to wait until JSON-LD 1.1 becoming a REC?
Matthias: no
... the roadmap I imagine
... 1.1 version is based on what they have been working
... may start around June
... figure out what the features to be fixed
... still loose end
... we have initial strawman for the next f2f if we start our
work for 1.1 now
Lagally: wondering about the risks
Matthias: it's a complicated
situation
... my expectation is JSON-LD 1.1 based version (of WoT specs)
could be stable
Lagally: wondering about actual product implementations...
Sebastian: wouldn't expect yet another big changes...
Lagally: should work with the stable version?
Matthias: you can new features if you
want
... same mediatype definition anyway
McCool: various possible issues
... if early enough, we might be able to resolve them
Soumya: hear 2 directions
... wondering about what oneM2M is doing
... they're using 0.a version for standardization
Matthias: the model would not
compatible...
... their style is spec first and then implementations
... on the other hand, we've been working on implementations
simultaneously
... another point is
... the model of TD itself didn't change drastically
... we have property, schema node there
... property could directly have type
Victor: not the way we should use JSON Schema
Matthias: meant small changes about the underlining model
Victor: possible solution might be using RDF itself :)
Matthias: possibly we can use pre-processing
McCool: as our plan b
Lagally: when we could expect
implementations?
... might be going to 2020
... note that I'm talking about device manufacturers
Kaz: wondering if we could think
about the core of JSON-LD vs 1.0 profile and 1.1 profile
... and work on both
... and then once the 1.1 version is fixed mainly work on
that
Matthias: would try a vote
... who would prefer 1.1?
... whould would do that?
McCool: what version would make sense?
Kaz: not the final decision but people's opinions at the moment
Kajimoto: difference between 1.0 and
1.1?
... if the changes are very small, we can assume 1.1
Matthias: the changes are stronger than
the ones they made previously
... positive feedback from Mozilla and EVRYTHNG as well
... would go for one specific solution
Taki: Victor explains the changes
Sebastian: more data side
Matthias: let's see what the JSON-LD 1.1-based TD would be like
-> slides tbd@@@
Sebastian: first change (example 4 from
TD)
... possibly semantics may not be decided
... JSON-LD 1.1 requires @context
... but it should not be necessary
... still based on the RDF model
... concrete triple
... at @context
... we need kind of post-processing as well
Matthias: possibly 3 processings?
Sebastian: we have to integrate the context
Matthias: in that case 3 processes?
McCool: user's perspective
... what 1.0 and 1.1 are like
... side-by-side examples?
Matthias: what about example 1?
<danbri> maybe typo on screen: Propertis (I think, fuzzy eyes :)
McCool: maybe we can generate an example?
Matthias: would like to look for that
(more discussions)
Sebastian: one big change is...
... (going back to the slides)
... [Downside of Current Workin Assumption]
... interaction container
... by the usage of "@type"
... class, type of the interaction model
... we use many "@type"s withing TD
... kind of interaction pattern
... semantic information like "iot:BinarySwitch"
... also we have to use container with JSON-LD 1.0
... because not allowed to use keys
... no restriction for that any more
... mandatory notations like "writeable", "observable"
... mediatype as "application/json" need to be defined
everytime?
Matthias: some more discussion on
"form" vs "link"
... we can ignore if "writeable" or "observable" is False
Sebastian: [Develoer Perspective]
... list of points
... usually HTTP/JSON is used on the Web
... why do I always have to write that down explicitly?
Matthias: may specify the default as HTTP, CBOR, etc.
McCool: mainly use CoAP
... OCF devices are CoAP-based
Matthias: actual commercial deployments use CoAP
McCool: default values always the
same?
... other values could be set?
... from security viewpoint, constant default would make
sense
Sebastian: [JSON-LD 1.1]
... [Pre-processing with JSON-LD 1.1 ...]
... [@context #103]
Matthias: let's take break now
[break until 4:10pm]
<inserted> scribenick: nimura
Sebastian: explaining about TD - W3C editors draft
Example4: Experimental TD example
<inserted> -> TD Example 4 based on JSON-LD 1.0 and 1.1
Matthias shows different
1.0: LD+JSON need @context
1.1: TD+JSON, we can do pre-processing
we still have name fields
ignore semantic markup @JSON-LD1.1@@@
Valid URI/(URN) is used for identify the TD
Sebastian: we already have a years ago the JSON-LD but gone after that
Matthias: property has JSON-LD 1.1 object.
McCool: the property is nice, but action and event are confusing
Matthias: programming language like JS restricts: name is identifier
link was singular but currently plural
we want re-use @id?
an object has single key: @id
"level": "name" work, but ambiguous.
when we starts use schema, this is one of the risk because there's nothing yet.
few solutions there and risk there. 5% of the case?
taki: can we be the pre-processing optional?
that's we are trying to do.
Matthias: we do this changes.
"integer" resolve URI in local, so no collision.
we are going to consistent to JSON schema.
RESOLUTION: we would like to go for the changes based on JSON-LD 1.1
major topic in TD call is explain about the issues at github.
link vs forms: it's like json schema
more natural from scriptingAPI point of view.
issue #88, #108
<inserted> TD issue 88
<inserted> TD issue 108
Protocol binding: for example OCF, non-standard implement implementation
It introduce bit complexly for property, but people continue to implement
Conclusion: exposing web resource, link to web resource is sufficient for get/put, you know what to do.
Property become less powerful but concept becomes simpler.
What happens for observe property?
How to differ get end pint and observe end point?
If you need to read OCF, need to have header.
stick to form there.
link gives relation to resources.
form gives interaction, but that's weird.
forms in html world have specific meaning providing data
Mm: stick to form, not automatically processing
Non standards interaction, we need to cover.
pre-processing has defaults, some kind of suggestion is needed.
"name" term there, @is becomes handle and unique.
human readable expression is favorable that's helps developers
about name, is it optional?
it's still working.
for the reference of object @id is necessary.
that's central of mandatory.
agreed on make "name" optional.
but name always require make sense.
we don'have "name" in some examples.
level can be used for expressing international language definition.
level and name are different.
level does not necessary like name
Name: {"en"]:"My Thing", "de":"Mein Ding"}
do we really needed?
that's internationalizable solution.
descriptions should be optional.
inside description maybe common markup can be defined.
description can be internationalizable.
about tags,
popular model among developers.
We have label, so not necessary tags?
Do not include TD vocabulary to tags.
about version,
is it optional?
it is useful for all of the application.
if we introduce change on TD version, runtime could handle it.
no version for TD, but JSON-LD version?
OCF has spec version.
<victor> candidate terms from standard vocabularies: owl:versionInfo, owl:priorVersion (not ideal), dc:hasVersion, spdx:versionInfo (best)
maybe instance version can be introduced?
thing should work like web. what's the purpose of version?
<kaz> (MLagally shows some examples on Java)
TD must be self contained: fetch all required web resources.
about author,
author=manufacturer
URL+manufacturer
It's not author.
however TD can have author.
minimum thing is support URI for fetching.
about domain,
as seen in iotschema.org
do we want to separate into domain?
In the plugfest, many integrations are provided by companies, so share the info and update the architecture document.
device servients were located in two place.
oracle provides solution in Praque.
proxy servients coordinate application and devices.
these app from Oracle or so could access remote proxy.
role of proxy servient is manage TDs and coordinate connection between apps and devices.
how to use proxy servient?
device connects to local network that connected to local proxy servient.
then app can search the device from TD directory.
in the future, proxy servient supports binding template.
Zoltan: what discovery mechanism is used?
proxy servient contains Thing directory.
Zoltan: only devices underneath can be controllable?
remote proxy that connected multiple local proxy servients handles devices underneaths.
Zoltan: what is the request?
Fujitsu specific approach is taken.
McCool: how do the devices discover?
TD directory is the implementation of core directory.
McCool: what protocol uses, standard way?
victor: look up is different from Siemens one.
McCool: how security handles? how do I translate?
<kaz> Kaz: if needed, we should ask Sano-san from Fujitsu for clarification on detailed protocols for discovery/registration
app never see local address.
security metadata to TDs would be added
Is discovery supported like query?
Still simple approach by search name is taken.
Assumption is names are unique that's not good assumption.
next time Fujitsu might support iotschema approach.
SSE and long polling are supported.
nobody implemented SSE in plugfest, but Fujitsu check that.
compact WoT core is developping, and next time we will show the device.
thing directory, proxy and the variations can be reflected to architecture doc.
<kaz> Kaz: just wanted a clarification
<inserted> ... the first point here (slide 7) means updating the preparation/guideline.md for the next plugfest and the second point means updating the WoT Architecture document, e.g., the Appendix section like the one from Kawaguchi-san
showing scalability experience for example 1 million devices will be useful.
kawa: register things at one time is convenient.
<kaz> [ Day 1 adjourned ]
<kaz> scribenick: mlagally
lifecycle section should live in the main document
McCool: we could not find a lifecycle
- only IETF spec has an example. This is a strawman
... maintenance could be intentional or unintentional
... we intentionally assume in security group provisioning has already happened
<yamada> https://rawgit.com/w3c/wot-security/working/index.html#lifecycle-of-a-wot-device
Barry: are you aware of ietf
security group? chartered in the last few weeks
... 2 groups: TEEP, SUIT
... SUIT = SW update for IoT
... TEEP = provisioning not limited to IoT
... you have trusted and untrusted parts
McCool: the entire device could be trusted
Dave: you might have trusted
services
... our descriptions should cover this
<ryo-k> suit (Software Updates for Internet of Things) - https://datatracker.ietf.org/group/suit/about/
Dave: OMA has merged with IPSO to found OMA Spec Works
<ryo-k> teep (Trusted Execution Environment Provisioning) - https://datatracker.ietf.org/wg/teep/about/
Dave: we should take into account
McCool: we should also work with the IETF groups
<dsr> My point is that the lifecycle also needs to take into account the provisiong of services in gateways and cloud platforms, i.e. provisioning in depth, and not just IoT devices at the edge
<dsr> My second point was the need to encourage coordination on provisioning and management across the many IoT alliances and SDOs. Let’s hope the IETF work helps with that
Elena: presents lifecycle of scripts
<inserted> scribes for today: Lagally, Dave, McCool, Victor
Elena: we have to discuss if script lifecycle is in scope
McCool: 3 cases
wot device with wot runtime
scribe: ocf device with a wot gateway
Dave: this is multi stakeholder
McCool: existing device, where target
device has own lifecycle and provisioning
... these are different configurations
Sebastian: same lifecycle for all things?
McCool: perhaps we need multiple
models
... different for consumer and industrial
... in industrial, devices may install their own software
stack
... having only one model is naive
... we assume only operational state - is this a valid
assumption
... script may be installed before operational state
Zoltan: we have 3 lifecycles here (scripting runtime and TD)
McCool: scripting lifecycle is within
operational state
... is scripting update in the operational state
Zoltan: this may be outside or may cause a cycle
Elena: we may have a small section on lifecycle
kajimoto: lifecycle diagram - we
may need decomissioned state
... ... lifecycle sometimes defined in operational state
... security items may be added by manufacturer
McCool: another state could be "engineering"
Dave: purpose of the diagram? best practice?
McCool: we want to define states to
clarify what state we are talking about
... where do the steps take place? depends on the situation
Zoltan: consequence of the diagram?
McCool: clarify scope of
standard
... if we can refer to an external standard
Lagally: look at osgi
... look into oracle IOT client documentation for
inspiration
Zoltan: OCF lifecycle has a purpose for certification
McCool: an OCF gateway still has to
onboard - go through provisioning process - we may need
liaison
... technical connection is possible - we may need a bridging
at org level
Dave: this is also related to
privacy: GDPR in Europe
... we are just defining interfaces
... we want to draw attention to the interfaces
Zoltan: we want to make these connections easy
Kawaguchi: state could be simplified from a SW stack perspective: device is accessible to wot servient, discoverable
Elena: this is just device
lifecycle - last slide is about software lifecycle
... please define SW lifecycle
McCool: scripting TF should define this
Zoltan: will discuss later
matthias: this is interwoven with
identity management
... we should look at Panasonic model - existing devices
McCool: we also have to worry about other authentication schemes
matthias: dan yesterday raised security question about JSON-LD
McCool: in NDSS we also looked into protecting access, securing against manipulation
Sebastian: how do we handle this topic? make it more convrete? Where do we discuss?
McCool: have not defined TD discovery
in the standard
... you could go to a base url and get a TD
Sebastian: where do we discuss this - github issue, f2f?
McCool: we discuss in security TF, but thing directory should be discussed in TD TF
matthias: no additional call - online interim meetings on Architecture
Zoltan: scripting API will refer back to this - we need sth. to be referencable
McCool: identity mgmt. is a lifecycle issue
Zoltan: one or multiple identities of a thing?
McCool: multiple access paths
matthias: multiple TDs from different places, multiple network interfaces, different addresses
Zoltan: in OCF you get an id via ownership
Matthias: different ids from different systems
Zoltan: if you get ocf id and from somewhere else
matthias: WoT shoud have urn mechanism to map uuid, imei etc.
McCool: we need a concrete written
proposal - one-pager
... decide in next group meeting where this is discussed
Dave: we should review against
best practices for linked data
... group needs to be aware of that
<dsr> see https://www.w3.org/TR/ld-bp/
McCool: we should not just have a string
matthias: @id in TDs mandatory -
there were name clashes during the plug fest
... should see how existing things are mapped into this - see
Panasonic's plugfest demo
kaz: issues are common with all TFs
McCool: we need a proposal first
kaz: we should also restart
architecture work
... lets start with a clear proposal
matthias: I'm updating architecture document anyway - will add a small section
McCool: security could be handled like this too
matthias: architecture needs full
lifecycle
... no difference between small device and web server - perhaps
just skip the commissioning step
McCool: there are various standards for services: cloud, open fog, ...
matthias: i write a markdown
proposal - how to map for existing services
... will integrate initial lifecycle version into architecture
document, generalize security TF model
... do longer calls on arch document - want to avoid just
another call
Sebastian: would be useful to be more concrete
McCool: diagram needs to be generic
enough
... use cases would be more concrete, e.g. consumer +
industrial
... existing diagram is svg
Sebastian: Siemens can contribute on industrial use cases
<Discussion on where document can be found>
Barry: please change color of the slide, black on white
Matthias: Let's talk about
terminology
... could WebThing be an alternative to different
terminology?
... corresponds to our abstraction in WoT
Barry: WoT server is an impelementation thing, not an abstraction
McCool: if we assume to get consensus with Mozilla/EVRYTHING, align terminology
Barry: pick something that's easy
searchable
... IETF does that
matthias: servient vs. WoT host?
servient was not familar to TPAC participants
scribe: Is WoT host less
confusing?
... servient is full SW stack
<brainstorming>
<strawman poll>
<pro's and con's of node vs. servient>
<inserted> [break until 11:10am]
<dsr> scribenick: dsr
Elena presenting remotely
She talks us through the main assumptions e.g. security must be transparent for scripts as much as possible
Will we cover security errors? Yes
We assume that the security configuration is handled independently of the scripting API
Diagram for “Flow 1” - in which a script discovers a new device
The script uses network discovery to find a thing
The required security credentials are identifed from the thing description
These credentials are obtained if not already present
The credentials are passed with an action request - the action response returns a result or an error
if the error is due to security, the script can refresh the secutity credentials and retry the action. This may be appropriate when the error indicates that the credentials have expired
McCool: the user may need to do something as part of the process for obtaining the credentials
In one scenario, the credentials are requested when retrieving the thing description
The permissions may be fine grained, e.g. allowing a script to read the status, but not to update it
McCool: the permissions may depend on the user’s role
Daniel: the credentials can declare what a script is permitted to do
Zoltan: this is all encapsulated by the WoT run-time
Matthias: the server sending the thing description cannot always detemine what the client is allowed to do or not ….
The client may be able to identify that the credentials are missing
I like the lazy acquisition of security credentials
Zoltan: when we do discovery, we are doing TD discovery not OCF discovery
MCool: We may want to expose the user’s role as part of the discovery process
Dave: can’t we we indeed handle authentication and authorization as part of the process for fetching a thing description, e.g. returning a bearer token for subsequent use in invoking thing actions etc.
Matthias: if you already had the thing description, you need another means to get the security credentials
Dave: indeed, and you need a means to request the credentials when a security token has expired
Matthias: we should like at how this is handled in RESTful systems
Zoltan: so we need to ensure that the Scripting API is able to report some set of security errors
McCool: we should look for guidance at existing practice
Elena: the general principle is to avoid providing additional information when this isn’t needed
If the information is already present, it can be propagated, but let’s keep things simple
Diagram for “Flow 2” in which a script exposes a new thing
A WoT script wants to specify security restrictions on the thing’s actions and properties
How does the script define and pass the security policy to the run-time
This may involve some protocol specific details, e.g. user id and password for HTTP Basic
Matthias: I would avoid this being set in the script. The run-time knows what security to apply
McCool: the thing description could declare user roles for each property or action, and the run-time could then expose this to an authorization mechanism
Matthias: we want to avoid putting security details in the TD
Zoltan: so are you saying that security policies are handle by a thing?
Matthias: the person who configured a script for exposing a thing, can also set the security policies at the same time
McCool: we can explain this in relation to the lifecycle
Matthias: script author’s shouldn’t need to know about the details of security schemes, and instead just needs to describe his/her intent
Elena: do we agree that we need a way for scripts to pass the intent (e.g. via roles)
Zoltan: no, this could be handled externally as part of the application context
Matthias and Michael talk about the use of identifiers that the run-time can use to map to the specific security mechanisms for the protocols in use
Matthias cites the use of named roles as such identifiers
Zoltan: do we need to standardise these?
McCool: no, they can be passed as opaque strings
Matthias: we should support arrays to allow for multiple roles
Daniel: we would like scripts to be able to run on different platforms
Zoltan: we could use the management interface for managing security policies
Elena: yes, we can manage this out of band and not expose it as part of the scripting API
Matthias: we could support hints …
McCool: we have extensibility through the means to add metadata
The lifecycle is important in that we need to talk about when information is provided and who provides it
<McCool> McCool: summary, we need to work on scripting lifecycle to determine who and when security data is defined.
Zoltan presents …
<McCool> ... normally, private information needs to be provided out of band, and within a script we should (at most) define the policies or roles that particular interactions use.
<McCool> ... these policies or roles should be selected from a list configured by the entity that set up the scripting runtime
We’ve summarised scripting issues in Issue #95
<McCool> ... however, to get consistency, it would be useful if these roles were defined using a common vocabulary. It is suggested that we defined a few such terms but using an extensible mechanism.
<McCool> ... a complex subject, but we can start just with "user" and "admin" and go from there
<McCool> ... it is also noted that security errors *should* be returned by the scripting API, with as much information that is available on the network interface, but no more
<McCool> ... this is based on the observation that a malicious attacker can look at the network traffic anyhow so there's no point making honest users' lives difficult by hiding information
<McCool> ... however, we should define more generic error codes or categories simply for ease of use
Zoltan uses OCF as an example
<McCool> ... there is also the question of defaults... if no policy or role is given, a "default" should be used
<McCool> ... this concept of default may (or may not...) be reflected in the TD... likewise, a "role" may use a SET of security configurations, and this may require a refinement of the current proposal to represent
OCF defines a specific sequence of steps for provisioning with onboarding/ownership transfer, and provisioning of security metadata
<McCool> ... also discussed was how to handle security during discovery, providing different TDs to different users to assist with privacy, and dealing with authorization errors
The WoT run-time needs to comply with the OCF requirements when it comes to exposing WoT things
OCF ownership transfer involves specifying device and owner ids
<McCool> ... points to note: secure delivery of differentiated TDs can be handled in a hierarchical fashion, eg. having a discovery service that needs authentication before it returns a thing
<McCool> ... this may/may not be out of scope; part of the lifecycle discussion
OCF is still refining its provisioning process details
The security metadata is covered by Issue #91
<McCool> ... finally, the scripting API should deal with authentication lazily so that (a) it does not waste time trying to do authentication it does not need (b) it has to do it anyways for certain schemes, eg refreshing expired tokens. SOME things, however, can be checked at startup (eg do I have an appropriate username and password for basic auth) but the more general case requires lazy eval
A WoT client needs to discover the thing, figure out the provisioning service and device info.
The WoT run-time needs to undergo OCF certification
Zoltan: the main use case is to expose OCF devices as WoT things
a secondary use case is to expose WoT things as virtual OCF devices
For the main use case, an application can expose multiple OCF device resources as a WoT thing
Matthias: we could include the full security details in the TD, but probably don’t want to expose all of that to WoT clients
McCool: for gateways, we need liaison with OCF to discuss the details
Zoltan: OCF controlls access to device resources via ACLs
A thing may represent multiple OCF resources
The WoT run-time needs to encapsulate:
- OCF discovery
- Claiming OCF client role
- Requesting access permission + validity period
- Making OCF resource requests (CRUDN)
- Processing replies and requests
McCool: we should use reflection for the run-time to discover the details
Talks about an OCF gateway
Dave: is OCF certification per gateway or per OCF device? In other words would an application hub for the web of things need certification separately for each app that exposes OCF resources.
Matthias talks about OCF work on a bridge and perhaps we can convince them to work with the web of things to simplify that?
McCool: right now OCF is specifiying bridges for each mapping separately
Matthias: I would like to figure out who to talk to the OCF people about their work on bridges
MCool: we need to push them to make this happen
Matthias: OCF won’t certify apps/gateways that bridge OCF devices to other ecosystems
MKoster: at the end of the day, OCF is member driven …
Dave: perhaps we should focus on
showing how security can be handled when bridging the web of
things to other ecosystems.
... perhaps we (WoT IG/WG) ought to show we know how to address
the complications of onboarding and transfer of ownership (e.g.
when people move home)
Zoltan: can’t we get some of the Microsoft and other companies to engage with the WoT activities?
Matthias: these companies are putting all of their resources into OCF and claim they don’t have any resources available to also engage with the W3C WoT work
McCool: OCF is making a lot of use of IETF specs, which will help with the WoT security discussion
Zoltan: OCF had a bad experience when merging in AllJoyn
Dave: we need to show that the security challenges can be addressed effectively, even though we won’t be standardising everything - i.e. some aspects are left to WoT application gateway platform providers
<kaz> [lunch until 2pm]
<McCool> test
<kaz> scribenick: McCool
<inserted> Scripting issue 90
Zoltan: issue 90 about
errors
... we already talked about security, but there are other
categories
... Matthias has requested a list of errors
... depends on algorithm
... all methods can fail for security reasons
... this morning we figured we need a WoT-specific error
... that has more information than the basic Node.js Error
object
Matthias: useful to have more
information
... there are still arguments to keep it consisitent with
normal errors
Zoltan: there is the issue of
writing scripts that deal with errors specific to certain
protocols
... then not portable
... we need a set of generic error codes
... suggest if you have a list, then add to issue
Matthias: agree don't want
protocol-specific codes
... but let's look at RESTful concepts and define a set of
generic errors
Dave: want a set of abstract errors
McCool: reporting information not a security issue (if available on the wire), but depending on how we do it, may be a portability issue
Dave: issue is avoiding information that is too specific to a platform
Matthias: for instance, token has expired, etc.
Dave: we can agree that scripts should be portable
McCool: we need a concrete proposal that we can evaluate
Zoltan: have some categories (see
the issue) already
... TypeError, NetworkError, SyntaxError, etc.
... there is the issue of the "message"... displaying it or not
is up to the application
... there is also a catch-all InternalError with a message
Matthias: should start with existing categories, see how far we get
Zoltan: should we have more than
just a message for the SecurityError
... or a symbolic code?
McCool: want symbolic tokens so we can handle certain categories consistently
Matthias: user needs to know how to deal with the error, i.e. they should know when retrying is useful or pointless
Zoltan: suggest people try to capture their opinion on the issue
https://github.com/w3c/wot-scripting-api/issues/96
Zoltan: tryed to come up with
webIDL to represent web API as a test
... came out a little bit different than the current API
... map-like DOM for instance
... can generate DOM that is consistent with (proposed new)
TD
Matthias: after McCool's question, we can use this to build a DOM consistent with JSON-LD 1.1 TD
Zoltan: do we want to expose the security section or not?
Matthias: might be useful for introspection
McCool: what about ID?
Zoltan: will have... point is, will expose everything in the TD
Matthias: there will be an issue
for things with @ in front... have to use ["@..."] not
.@...
... there are restrictions on identifiers we will have to look
into
... some we can map @context to context, but what about @type
and type? causes a conflict
... so need to extend the mapping somehow
... don't need to break interactions down into Properties, etc.
already broken up
McCool: also possible keyword conflicts
Matthias: but always have the fallback to [] notation
Zoltan: should the mapping be
direct?
... can be awkward for scripting
Matthias: changing the names is a problem, 1:1 mapping clearer
McCool: I agree a 1:1 mapping is better
Zoltan: we could just add methods for @types
Matthias: but why? this works
fine
... can access everything just with knowledge of the TD
... you just have to know that you have to use [] for
@-types
Zoltan: then we should probably not separately define these in the API...
Matthias: if you say we don't
specify this, then you just follow the TD implicitly
... we can just tell people what is happening
McCool: just tell people that if it's in the TD it will be in the DOM
Matthias: we can also autogenerate the scripting API DOM spec from the TD spec
Victor: we can take existing tools to generate the spec
Matthias: you said you don't want to track the TD spec...
Victor: can generate webIDL from ontology
Zoltan: could also generate JS object/implementation
Matthias: but we aren't talking
about the implementation, but about the spec
... and we already generate a lot of that from a formal
model
... so we can do the same thing for the Scripting API
Zoltan: but it's not really necessary since we can do introspection
Matthias: but we need to know where to attach handlers, etc.
McCool: we should distinguish
goals and means... goal is scripting API and TD are
consistent
... so just figure out how to get there efficiently
... I think that we can just give the rule and don't have to
redundantly list everything redundantly
Zoltan: we don't need to specify the structure, already given by the TD
Matthias: but still need
attachment points
... eg to add a property
... where do I call this?
Victor: so we should at least
have the skeletons for each class?
... but agree it's necessary to add extra entry points
Matthias: we do have to specify
skeleton so we can add entry points to it
... need context for function definition
... start doing it and you will hit the problem I'm talking
about...
Daniel: I think we can also just
try to prototype the generation of the WebIDL
... as a reader, I don't want to jump between two specs, SA and
TD
Zoltan: but how do we deal with variable @type syntax
Victor: well, in other cases have
similar issues, like $key in JSON-Schema
... so not an unusual problem
McCool: the issue is only that the webIDL generator needs to do the right thing
Matthias: issue is that you want to avoid the @type
Zoltan: can't define @type in webIDL
Matthias: so it's the webIDL spec that is the issue...
Victor: we also have methods like invokeAction...
Matthias: need to know where this goes in the class structure
Victor: the @ keys could be left
out of the webIDL spec... and inferred from TD spec
... but we include the "main" classes in the webIDL
Matthias: then we "metadefine" the other things...
Zoltan: that will give bad feedback from the AC
Matthias: it works, so...
McCool: can make ["..."] the main definition, then say the . notation works for things whose identifiers satisfy certain rules
Victor: at least three
representations of same JSON-LD object
... advantage of the webIDL is that it gives a canonical
representation
Matthias: make this deal
... then we will do another pass that deals with the
@types
... make an API, but ignore all @types
Zoltan: but we could infer some of the @type stuff?
Matthias: no... and the spec will be in flux due to the JSON-LD 1.1 transition
Daniel: will take the action to talk to webIDL people about this issue
Zoltan: moving on... examples,
how to set a Temperature, etc
... showing use of the different notations
Matthias: note that properties now have get and set
Zoltan: and then there is the observers pattern
Matthias: example does not quite follow the pattern we discussed
Zoltan: in this case, interface
implements observable
... alternative is there is an "on" method
... (refering to "temperaturechange" example in issue
tracker)
... might need options to pass to subscription
... so using "on" would be nicer if we want to pass options to
the subscription
... but we should stick to the known semantics
... also have "on" not only for events but also property
change
Matthias: confusion of multiple paradigms
Zoltan: we should probably
experiment with writing code with both
... Observable is an ECMAscript proposal, but may not fly
... often used for filtering infinite series, but we aren't
doing that
Daniel: what if it does not fly?
Zoltan: then we would have a
private definition
... OK... we have a few more issues
... but the intent is to get as close to the TD as
possible
... we should track the TD
... starting point for updating the scripting API work
Matthias: if there is an example, we should check that it works
McCool: what about extension keywords?
Zoltan: consuming works, but
exposing is a problem
... exposing is a security issues, need to check against known
strings
McCool: I would hope it works if the extended key is in the context I include
Victor: this is why framing is
important.. know in advance what object should look like
... will remove unknown keys, add prefixes if needed, etc.
Daniel: a good implementation would do that, but... can we enforce it
Zoltan: a risk of injection attacks
McCool: I suggest we break it up... what we can from the scripting API, then separately deal with security risk... and what checks we need to include to avoid problems
Matthias: agree separation of
concerns approach is useful
... may have separate validation tools, etc.
... but generally we need to deal with extensions
... maybe have a .validate API call... but in general, we have
to figure out how extension points work
Zoltan: ok. regarding other
points, will talk to some stakeholders and Javascript purists
what makes sense to them
... that all said... mostly we are talking about Consumed
things in this spec, need to look at how it works with Exposed
things
... also does not really discuss schemas
McCool: but may change anyways if we align with JSON-schema
Daniel: should be easy, simple recursive structure
Matthias: suggest for now do
everything except @-types
... we will look into it, later on we will patch in such
things
... should look at some other implementations to see how they
deal with such exceptions
Kaz: if we have some difficulties with webIDL... can give feedback to Web group
Matthias: proposal is deal with
basic things that work, then figure out how to add to the spec
how to deal with exceptions
... Daniel will reach out to Toby to see if there already is a
solution
... should coordinate with Kaz
... need to find the right person to talk to
Zoltan: Toby is only the latest guy to touch it
Daniel: one question:
future
... what are our plans for other languages... is webIDL the
right choice
... other languages can use our spec
... first ones that do a non-browser spec will need to do
something else
McCool: so why do we bother with webIDL at all?
Matthias: for one thing, it makes
adoption in a browser easier
... but we may want an informal guide for other languages
Zoltan: of course you can use the WoT and TDs without scripting at all...
Matthias: maybe move another
topic up...
... is an issue about "what is the web"
... read between the lines there that there might be some
misunderstanding
... for instance, we need at least some URI scheme
... and example there, we looked into MQTT, a counter-example
Mozilla brought up
... of course we need a URI scheme; we know how to do this, but
it should be pushed up to a standard
... another example that is counter-example, there are lots of
other protocols that are linkable that we probably don't want
to use, eg "file://"
Barry: don't even need an
RFC
... URI schemes are defined by "expert review"
... so much easier process
... can also just use the Oasis spec
Matthias: also mediaTypes, etc.
Barry: so maybe what we should
write is a definition of what protocols are useful with
WoT
... and if necessary, guidelines for how to define a URI
scheme
... what about Quic, etc.
... a google thing, follow-on to http that runs over UDP
... they will have a URI scheme for it, so that kind of thing
should work
... in most cases bad for implementation to worry about
protocol...
Matthias: one complication: coap
over UDP vs. coap over TCP
... semantics are a little different
Koster: application probably won't have to deal with this...
Matthias: reminder that the URI is just an opaque string...
McCool: Barry, will you take the action to write up a definition of "what it means to be compatible with WoT"?
Barry: sure, I can take a stab at it
Matthias: we should look at the
use cases to see what protocols are appropriate to use
... may have different requirements on northbound and
southbound interfaces
... may also have proprietary interfaces in various
places
... also specialized sub-protocols, eg. over websockets
... may be specialized protocols on both southbound and
northbound interfaces
... (CoAP over UDP may or may not be a good example of
that)
Koster: how about extensions, cross-exposure between ecosystems, etc
Matthias: may need specific
bindings for "proprietary" protocols
... in that case though while it might be accessed from inside
a servient, it would not be described with a TD
... could still use a TD...
... reusing mechanisms, but not direct access; feasible vs
allowed
Koster: even for generic web
interfaces, may want to have a protocol binding to give some
details
... there is a question of what is the "natural" mapping
... still want to write it down
Matthias: if you start from the TD, even the defaults define a binding
McCool: what about security? Protcol Binding or TD spec?
Matthias there is also DataSchema
scribe: currently only defined as examples
Matthias: are there another other
protocols we should include
... would be a good "check" with our list of requirements
... my understanding it was a proprietary binding
... will discuss tomorrow... but is http
McCool: regarding wot-security working vs master, I will create a PR tonight to get caught up, if the security TF members can be please review ASAP
[Day 2 adjourned]
<kaz> scribe for today: Mizushima, Koster, Kaz
<inserted> scribenick: Mizushima
McCool: agenda is context
... thing description validation
... security validation
... Out of scope
Kaz: we need check list of plugfest
Dave: rechartering oppotuniity
McCool: and Test Suite
Rewuirements
... Review of Specification and test suit design
<kaz> Web Platform Testing framework
Koster: i think we need recomennd.
<kaz> (McCool captures the discussion on his slides)
Kaz: We should integrated W3C
test tools
... frameworks
McCool: I start about to do
... We need list of test case under plugfest
... we should update from 2016
[Plan for Testing]
Kawaguchi: ECHONET update
... I take about collaboration with ECONET
... ECONET is mutivender home networking
McCool: is ECHONET Lite IP-based?
Matsuda: no. any kind of transfer is applicable if you want
McCool: Machketing?
Kawaguchi: 4 milions shiping
<mjkoster> Matsuda: Echonet lite can use non-IP networks
<inserted> scribenick: kaz
McCool: what is the data payload? binary or some specific format?
Kawaguchi: binary
... [What is ECHONET Device Object?]
... ECHONET spec itself doesn't specify the devices'
behavior
... it specifies just the data format
Kawaguchi: [Support for Legacy Protocols]
... shows concrete data format and frame payload
Dave: wondering about the
performance
... you can choose multiple interface
Kawaguchi: baed on the manufacturer's
preference
... but there is some guideline
McCool: 2 problems
... automatically generate the TD?
Kawaguchi: for each device?
... partially automatic generation
Koster: what kind of format to be
used?
... any kind of XML?
Kawaguchi: shows the object
model
... some 0x80, 0x81 kind of data
... property on=0x30, off=0x31
McCool: anybody working on web implementation for ECHONET?
Sebastian: the property names are
standardized by ECHONET
... how to extend?
Kajimoto: vendors can set unique name within the vendor-specific area
Kawaguchi: [Ongoing status]
... intended to be used on the cloud server
... talking with ECHONET guys about collaboration
... not open to the public yet
Matthias: it would be worth to define semantics from WoT viewpoint
Kawaguchi: q: when will the WoT specs be ready for practical use?
McCool: depends on the
requirements
... commercial purposes?
... stable enough for engineering?
Matthias: starting with the next plugfest in Korea, we should apply changes for JSON-LD 1.1
Lagally: what about the simplified TD
proposals?
... starting from when?
Matthias: asap
... new editor's draft should cover it
... end of April for the updated drafts?
... think after 3 more plugfests, spec and implementation would
be stable
... question about normative reference
... maybe JSON-LD 1.0 as a normative reference for a while
Lagally: any other significant changes?
McCool: don't think so
Lagally: what about Mozilla's proposal?
Matthias: getting consensus
Kawaguchi: (go backs to the
slides)
... interaction patters
... what would be the suitable use cases?
... property read/action
... property observe/event
... sending query parameter?
Matthias: discussion on
terminology
... clear understanding on property/action/event?
... examples are helpful
... why property should be suitable to which case, etc.
... [Initial feedbacks (2/2)]
... TD DataSchema
... what data types are actually allowed?
... Sebastian has already answered
Kawaguchi: can expect the TD spec will
be updated
... JSON Schema terms are re-mapped from time to time
Matthias: addressed by the simplified
TD
... top-level property and form field
... and sub property
... would fit lwM2M and IPSO, etc.
... hierarchical structure
... JSON hyperschema also would fit
Kawaguchi: recommended method for
discovery?
... any guideline?
... for unique ID/URL and versioning?
Matthias: some work by IRTF T2T
... on device identifier
... not sure about your own method, though
Kawaguchi: when will iotschema.org ready?
Koster: already ok for practical uses
Matthias: community-driven work
... if something missing, you should edit it
McCool: should define use cases for your "practical use"
Kajimoto: at a starting point with
them
... but many manufacturers support ECHONET standard
... so might make sense to invite some key people to the next
f2f
McCool: wondering about vendors from outside Japan
[break till 11:40; next topic on rechartering]
Matthias: have let the host know about hour preferred date and waiting for confirmation
<scribe> scribenick: mjkoster
Matthias: what are the building
blocks?
... synchronization of servients
... life cycle - design phase, semantic composition
... simple JSON TD
... unified TD
McCool: proxy synchronization
... standardized directory
Dave: how to use the IG to grow the ecosystem
McCool: TD templates
Matthias: concept of templates has been
around since the beginning and has been expected
... it's a TD without the instance information
... can be given the scripting API to create an exposed
thing
... it's already in the charter
McCool: it's not in the charter
... TD types like templates
... with a unique identifier
... to argue about later
... new ontologies for things like name
Dave: maybe we could charter another group
McCool: new interaction types like
screen
... hypermedia pattern when a thing returns a thing or a form
or an action
Dave: can a thing be a data type?
Koster: communication patterns like webhooks and pubsub (protocol bindings and sub-protocols)
Matthias: to explain better, for
examplee ws is only a transport; how do we use these for
interactions?
... there is CoAP over WS, etc.
... Mozilla also working on sub-protocols over web sockets
Dave: do we want to try to converge on a default binding?
McCool: also multipart chunked SSE
Matthias: we have weblinking in the TD
which can pull in external resources
... management things
McCool: security metadata and
bindings, e.g. roles
... test modes
Matthias: system thing to represent the
local runtime
... and things in the runtime to potentially expose
... has some internal URI scheme that can use I2C and other
local interfaces, like GPIO on a raspberry pi
... there is a local discovery mode
McCool: security configuration data
Matthias: can provision a new runtime
McCool: maybe it's 2 different things for system e.g. runtime provisioning and local things in the runtime context
Matthias: could have a servient
management thing for provisioning and installing scripts
... thing management vs. management things
McCool: gateways?
Dave: website using iotschema
annotation with UI controls
... also discovery
... make it easy for ppl to discover and install services using
web browsers
McCool: service things
... payments
... large can of worms
Matthias: this is exactly thing management
Dave: also make these things discoverable
McCool: basically a TD that describes the services
Matthias: there is a capability for a thing already defines
Dave: how do we orchestrate it end to end?
Matthias: script on the website can
call or invoke interactions of the management thing
... which operates on the runtime
Dave: browser vendors may need to do special things
Matthias: if they implement the scripting API it can be done without special integration
Dave: security and privacy are important
Lagally: we don't have a way to describe how an API works like interdependencies between interactions
McCool: we can use ontologies to apply constraints
Dave: sequences of API calls
Koster: there is a schema.org activity on describing web service APIs
McCool: prioritize now
Matthias: bubble sort by walking
through the list
... what can we identify that we already know we need
Dave: sort by WG vs. IG
Matthias: also some out of scope or
later
... system thing exploration can be done in the IG on the
management thing
... there is vocabulary, flow, and how to expose
McCool: suggestions for sorting items by venue IG vs. WG
Kaz: risk of doing some important standardization work within the IG side
Matthias: should team up with IETF on protocols and sub-protocols
Dave: is there any other work we want to collaborate with IETF on?
Matthias: mapping to web of things
protocols, e.g. defining URI schemes
... people need to participate in the plugfests to incubate
some of these ideas
McCool: well, actually
Dave: need to involve ppl not in
the room, do more outreach
... rechartering means re-joining and creating opportunities
for other companies to join
McCool: we could make it more attractive to browser vendors
Matthias: we need to be realistic about creating something worth marketing and something people can use
discussion about whether to use the charter to create interest and attract new members vs. using the charter to commit to delivering something useful
discussion about outreach
Dave: are there any thongs we should look at for outreach, e.g. cloud services, to get participation rather than competition
<inserted> scribenick: mjkoster_
Matthias: tool development and
playground
... will clarify some things and make a strawman proposal for
items for the new charter
... (walking through the list and making notes)
McCool: discussing class vs. template
Lagally: a place where we distinguish templates from instances
Matthias: there was a discussion IRTF about hard typing vs. flexibility in description
McCool: manufacturer has a template for a type of product
Matthias: hypermedia patterns;
constructed action, events for alerts, entity description
... a running action is not a thing but needs a description in
the TD
... management thing is low hanging fruit
... how do I manage a remote runtime or proxy
... WoT vocabularies are normative
McCool: security metadata also
Matthias: communication patterns go in
IG
... but the created action can be developed in WG, it is
already incubated
... who would build and specify a new sub-protocol over WS?
(dsr, mm, and expected to be Mozilla)
Matthias: this should be IG incubation
Dave: want to build a peer to peer protocol
Matthias: also the Panasonic WS
sub-protocol
... system thing is a candidate for IG incubation
... is there anything someone can't live with?
McCool: split developer outreach into
two categories
... liaisons and online events
Matthias: combine with plugfests
Sebastian: what about the WoT landing page?
[lunch till 1:30pm]
<kaz> scribenick: kaz
Zoltan: publication prep ongoing
... new api style for simplified TD
... feasible we agreed
... @context
... action point for Daniel to check with WebIDL people about
how to handle the changes
... PRs for simplified TD
Matthias: need to accelarate the
work
... how the JSON-LD 1.1 version would look like
... WebIDL only includes normal stuff
... Daniel to follow up
Zoltan: we can modify later if needed
Matthias: can you do it now?
Zoltan: not now
Matthias: maybe you can ignore the
semantic part for the moment
... and Daniel can handle it separately
Zoltan: we can add an Editor's note
Matthias: paper review next week
... can give you the 2nd week
... e.g., 13th
... scripting call on 15?
Zoltan: ok
... and make a PR
... start the work on the scripting spec for new version
... next plugfest will be end of June
... aim May for the iteration
... start algorithm discussion
... security consideration as well
... freezing date may be June 1
Matthias: in May iteration
Zoltan: main steps of the
algorithm
... will discuss how to do during the next script call in 2
weeks
... April 9th
... that's it
... btw, thanks for the good meeting!
(zoltan leaves)
Sebastian: restart our telco on April
6
... next f2f end of June
... around 13 weeks
... need stable version for plugfest
... by 10 weeks
... compile simplefied TD approach
... new vocabularies into TD deliverable
... ask for volunteers
McCool: will create PRs for security
metadata for TD
... aiming PR by end of May
Matthias: special build procedure for TD spec
Sebastian: not very complicated
McCool: also need ontology work
... 4 weeks to do that
Sebastian: rocedure on the
README.md
... ok to merge section 5 and 6?
... initial idea was only core model somewhere
... make sense to merge "5. vocabulary" and "6. JSON-LD
Serialization"?
Lagally: not a good idea
... pure model should be kept separately
Matthias: simplified TD doesn't have to be a second one
McCool: clean separation would be good
Sebastian: maybe possibly provided as a separate note?
Dave: self-contain style would be
good
... other serializations could be documented separately
Matthias: this will be fine
... media type can be registered
... maybe good to have a separate work with figures
... CBOR, etc., could be interesting
... depending on how much figures needed, though
... maybe would make sense to move out
... there is redundancy
Lagally: would like to keep it asis
Matthias: maybe clean-up is still needed
Lagally: right
Sebastian: done
Koster: still some work for
publication
... next item is actual action pattern
... more functionality
... target wold be May for stable one
... major refactoring base on simplified TD
Matthias: not much adaptation
Koster: simplified version of form, etc.
Matthias: one point is
... action item Barry picked up
... guideline for WoT Binding, e.g., MQTT
Koster: happy to prepare for
it
... stable version by May
... publish for plugfest
... binding mechanism
Matthias: similar issue to be documented for security part
McCool: lifecycle issue
... create instance, etc.
Koster: that's it
Matthias: when to publish the first
draft?
... maybe end of April?
Kaz: provides the clarification that the originally expected publication date was last week and would suggest we publish it next week asap
Matthias: Binding to be published asap
... TD also to be published asap
McCool: end of April
... security metadata for TD
... more imporatant thing is security review for scripting
api
... lifecycle and expansion for security
... more abstract ersion of lifecycle
... timeline
... 6 weeks from now
... NDSS paper also to be finished
... for the security note
... industry use cases
... try to update by the next plugfest
... another point
... testing validation
... every tf also should look into it
... accessibility
... work with Graeme
... OCF liaison
... Koster has views?
... WoT bridging project
... involving OCF Members
... OCF metadata-WoT metadata bridging
Matthias: they might think OCF as a
possible competiter to OCF
... but that's not true
... bridging vocabulary with OIC one, etc.
... should not feel WoT is a competeter
McCool: technical reviews for
feasibility
... so would ask Koster's opinion as well
... with reference to more stable version specs
... we'll have more discussion on that
Matthias: some binding for
WoT-OCF
... something does that UPnP
... knowledge about UPnP
McCool: ecosystem-ecosystem
bridge
... bidirectional bridge
Matthias: WoT for bridging
... you don't have automatic mechanism
... but more formal way using WoT
... get less bridging issues
McCool: thinking about OCF
bridging
... let's talk about that offline
Matthias: thank you everyone for
coming!
... quite good meeting
... simplified TD, etc.
... solves various issues
... fits better to existing ecosystems
... very good result from this meeting
McCool: rechartering timeline?
... 3 months extension enough?
... maybe actually 6 months
Kaz: will talk with PLH
... based on the results from this meeting
<scribe> ACTION: kaz to talk with PLH about rechartering
<trackbot> Created ACTION-130 - Talk with plh about rechartering [on Kazuyuki Ashimura - due 2018-04-05].
Matthias: 3 months for wrapping up the
current work
... and 3 months for generating new Charter
Kaz: repeats the basic plan on the flipchart
Dave: what to be done within the upcoming a few months?
Matthias: publication/plugfest by the
next f2f
... will summarize it by email
Kawaguchi: still not sure about the relationship
Matthias: explains
Kaz: this is similar case to HTML5 which depended on WebIDL
<scribe> ACTION: kaz to talk with PLH about if TD can refer to JSON-LD 1.1 if it's a WD
<trackbot> Created ACTION-131 - Talk with plh if td can refer to json-ld 1.1 if it's a wd [on Kazuyuki Ashimura - due 2018-04-05].
Matthias: will summarize the story and send it to the Membership
<scribe> ACTION: matthias to summarize the plan for publication and rechartering and send a message to the group list
Lagally: first and good meeting
Matthias: thank you, all!
[f2f meeting adjourned]