<dsr> scribenick: dsr
mm: reads out Elena’s slide
There’s multiple places where security matters, internal and external
When we are using security mechanisms for particular protocols we need to reflect this in the thing description
For external security mechanisms, yesterday we decided to create a separate security github repository
<elena> guys the line has no audio
We need to work with external organisations to document their security mechanisms
mm: any volunteers …
... I can work with Zoltan and Elena for OCF.
Dave: any IETF experts?
mk: Panasonic could document what they’ve done with HTTPS
mm: we want to describe existing security mechanisms
<soumya> i can look at oneM2M
mk: Siemens can contribute, I can’t say exactly and need to talk with Oliver. It is likely to focus on IETF work
mm: We should review what the IETF recommend
Soumya: I can look at what oneM2M are doing on security and also OMA’s security for LwM2M
mm: for HTTPS, I also want to consider OAuth, and to see what Amazon IoT is doing.
Michael asks Elena for guidance
Elena presents
<kaz> i/reads out Elena's slide/topic: Review of Existing/Proposed Security Architecture [WG]/
<inserted> Privacy questionnaire
mk: unique identifiers, e.g. for a device may be important for some use cases, but not for others
The challenge is how to restrict access to this
mk: so far we haven’t define any vocabulary terms for this. Panasonic’s work on lifecycle is relevant, but nothing is set in stone as yet
Sebastian: the JSON-LD @id feature is relevant
Dave thinks that the RDF node for a thing description for a specific instance of a device is such an identifier
mm: the issue is to whom the id’s are exposed
This gets us back to the question of whether you can control what you get back when requesting a thing description, e.g. based upon an authentication and access control mechanism
OCF has a device identifier (“di”). We can look at the OCF approach, and I believe that the device identifier is only available after you’ve being authenticated with the relevant credentials
Elena: you’re describing the OCF perspective, but we need to look at the WoT layer
mm: the OCF device id is freshly coined each time the device boots
mk: we want to provide core building
blocks, e.g. the life cycle management
... we have a tight schedule in our charter
so we can’t expect to solve everything in that time frame
Elena: we need to ensure that we (WoT WG) don’t make matters worse …
mm: we shouldn’t propagate publicly information that is supposed to be private, we need some privacy principles, we need to consider bridges and what information should/shouldn’t pass over it
mk summaries
<kaz> dsr: maybe we have to introduce mechanism to identify sessions
Dave: RDF relies of URIs for naming things for describing them and their relationships. This implies a degree of persistance. We should introduce the notion of session so that the descriptions are only valid for that session.
mk: RDF is about knowledge management, and typically for longer lived descriptions
We need a way to provide shorter lived information subject to access control
mm: IPSO have struggled with this, we could talk with them
Dave: we need to consider access control to RDF graphs and the life cycle for such graphs
mm: RDF id’s for people are privacy threating
Dave: only if shared, so we need to
deal with restricting sharing such ids
... this brings back to discovery and ensuring that the URI for a
thing description is only shared with entities that are authorised
to see it
mm: we could look at proxies with temporary ids (personae) with persistent ids hidden behind them
Victor: RDF blank nodes could be relevant as they are restricted to a given context
Elena: we need a small group of us to brainstorm on the principles
mm: any volunteers?
Michael McCool, Elena, Dave put themselves forward
<inserted> scribenick: kaz
kaz: wanted to mention 2 points
... 1. it seems to me that
there is a need to handle several levels of lifecycle, e.g.,
static/eternal lifecycle, hardware-dependent lifecycle,
software-dependent lifecycle, session-dependent lifecycle. so we
might want to think about those possible levels of lifecycle based
on concrete usecases from our plugfests/
... 2. there had been similar discussion on identification within
the Web&TV IG's GGIE TF, and now they're working with some IETF
group, so we might want to refer to their work as well
<inserted> scribenick: dsr
Taki-san: to whom you provide an id is a means to protect privacy
<victor> I can also participate in this discussion about IDs
mm: what over standards groups have Ids we need to consider, LwM2M. for instance
Michael_Koster: the IETF work on resource directories is relevant (CoAP)
<mjkoster> in IETF, it is the resource directory specification that describes the persistent endpoint identifier ("ep")
<mjkoster> This mechanism is reused by LWM2M
mk: we shouldn’t attempt to standardise identifiers, but rather to work with what vendors and SDOs already support
Elena reitterates the principle of being careful not to make thing worse
<mjkoster> The other identifiers in LWM2M, i.e. object IDs and resource IDs are just number codes for the same class ID as e.g. OCF resource types
Private information shouldn’t be made public, for instance
mm: the privacy work should be part of the IG
We need to work with existing approaches, and we can work on guidelines
<mjkoster> mccool: "privacy proxy" is an example pattern
mm: we need to explore use cases to mature our understanding
<inserted> [There is a question on use cases on the page 5 of the questionnaire.]
Elena: we need to provide clear guidance to implementers
mm: we need to consider what capabilities are required by legal constraints
This merits a further question for the questionnaire
mm: the EU GDPR is one thing we need to look at
Elena: this could be hard to answer in a questionnaire
Different countries’ law will vary considerably
mm: I care more about the implications of legal requirements on the technical requirements
Kaz: I was worrying about the regulations in different countries
mm: there is a lot of variation, so the challenge is to boil these down to a set of technical requirements, this may have already been done, so we should look for that
Kaz: I would suggest moving this use case question from page 5 to page 1
mm: we should make a stab at trying to answer the questionnaire ourselves
<kaz> [so far McCool, Elena, Dave, Victor, Kaz]
<kaz> [possibly start the initial call the week after, and will hold a doodle poll for that]
<inserted> -> @@@ McCool's note
<kaz> [ break ]
<elena> The privacy form is updated with the changes discussed
<kaz> scribenick: kaz
link tbd
dsr: will talk about general
things
... Darko will give details on recipe
... [Benefits of Semantic Models]
... interaction models describe the properties, actions,
events
... interaction model provide what the property means
... semantic models describe the meaning and relationships between
things
... allows providers/consumers to agree on the meaning
... idscovery based on the purpose of things
... designing compositions of services with the confidence that
they will work as intended
... adapting the UI and service logic to deal with variations in
capabilities from one device vendor/sdo to another
... [Semantic Models]
... thing as an instance of the class of things
... things may be declared as instances of other more specific
kinds of things using rdf:type predicate (or subclass with
rdfs:subClassOf)
... for properties, actions and events
... number of possibility about the solutions
... there is a scaling issue
... OCF, oneM2M, Echonet (etc.) cover smart home area
... how to relate with different standards?
... [Bridging Communities]
... OCF ontology-bridging ontology-oneM2M ontology
mccool: might want to talk with Alan
from Qualcomm as well
... OCF looking at oneM2M as well
dsr: how about you, Soumya?
soumya: Yongjing would be the best
person
... can talk with Orange guys as well
mm: Alan is working on bridging between OCF and oneM2M
dsr: great
... [Exploring the Design Space]
... generated linked data interaction models for OCF and
oneM2M
... in the process of doing this for ECHONET
... plan to follow on with Bluetooth and LwM2M
... next step will be to craft the corresponding semantic models
for each IoT standard suite
mm: should consider not bridging between SDOs but bridging up to some standard/common concept
dsr: proposing we try some experimental work
kaz: we've been doing PlugFests as
interactive experiments
... so this sounds like an improvement of PlugFest and think about
how to connect/bridge some std-based device and another std-based
device
seb: seems good idea but think it's
very difficult
... we're working on TD ontology and we could upload information
there
dsr: bridging ontology would be
enough
... we don't have to standardize everything
<McCool> in fact, we just want to standardize the hooks to support semantic models, not (necessarily) (all) the semantic models themselves
darko: part of the LD TF work
... [Thing Description Recipes]
... problem statement: how to easily enable thing interactions,
thereby creating WoT applications?
... proposal: interop client creates a WoT application based on a
Recipe.
... discovery of Things is automated thanks to the semantic
specification of TD and the recipe
... recipe interactions are implemented with WoT API
... propose a recipe format base don TD and capabilities from
iot.schema
... [Current Situation: Discovery with TD Repository]
... 1. WoT Servient (on the left side) register/update/delete
TD
... 2. WoT Servient (on the right side)
search/querying/lookup
... 3. and gets TD/subset of TD content from the TD repo
... [Recipe Example 1]
... simple example
... turn a light on when motion is detected in a room
... recipe consists of ingredients and interactions
... e.g., MotionStatus Property - SUBSCRIBE MotionStatus
... could also graphically represent this
... Motion Sensor (including MotionStatus property)
<-status-> LightSwitch(including TurnOn Action/TurnOff
Action)
... Ingredients are TD Interaction patterns & iot.schema.org
capability
... Interactions implemented by Scripting API
... (shows some UI on this idea)
... (and TD example)
mm: you have multiple different roles
for an action
... success/failure kind of status
... multiple links linked to multiple roles
<mjkoster> ...could use multiple links in TD using link relations for which "role" e.g. invoke, cancel
darko: (shows TD example again)
... metadata kind of recipe here
... first Ingredient, second Ingredient
... motion detecting for turning on or off
... one more slide
... [Recipe Example II]
... search for a think on some repo or marketplace
... if there is not the expected Thing available, there is a recipe
(temp sensor, air temp controller)
<inserted> discover things that implement the recipe
darko: discover things that implement
that recipe
... temperature sensor TD, air temp controller TD
mm: recipe could be a hook
<mjkoster> ... the recipe could contain a hook to the application logic
darko: [Benefits of Recipes]
... recipes offer the following
... discovery of recipes for various applications
... easy implementation of applications with recipes
<McCool> to clarify: my thought is that the "process" part could be another component, referenced by URL, that implements the "algorithm" part of the recipe.. but the ingredients are found as described, separate from the process
darko: efficient discovery of things
required for recipe apps
... easy creation of recipes based on existing apps
... easy sharing of recipes on a marketplace/repository
... easy extensions of existing recipes on a
marketplace/repository
... Web links of an app in TD
... sematnic dosumentation easies maintenance of application
lifecycle
dsr: recipe is declarative
mechanism
... doesn't have to be a code
darko: maybe a good idea to build
procedural part on the top of recipe
... e.g., control the switch for lights
dsr: also security aspects
mm: how the actual processing
happens?
... linking to urls
... similar procedure like the one built in the recipe
... can imagine some simple tags
... nice to separate discovery from process
... don't have to install scripts
darko: interaction between ingredients
<Zakim> kaz, you wanted to mention the need for thinking about states corresponding to the ingredient and to ask about the relationship between recipe and management thing
[discussion based on "Current Situation: Discovery with TD Repository"]
kaz: given your clarification, I think the main purpose of this "recipe" proposal is providing syntactic sugar kind of help for developers so that developers can generate WoT apps easily. on the other hand, the capabilities mentioned here are quite related to ManagementThing, so I'd suggest you collaborate with TD guys (esp. ManagementThings guy).
dsr: trying discovery on the semantic layer would be complicated
<McCool> mccool: the way I see this: recipes are an application layer that uses wot. you find a recipe you want in a marketplace and want to instantiate it using your devices. One step of that is the discovery of local things that match the necessary ingredients for the recipe. but in addition to discovery of local services, you may also have to instantiate (a thing), install (a script), or find (eg on the cloud) processing services
dsr: and maybe should be done on the application layer
darko: how to know what devices are
online, etc.
... would be good to provide this kind of "recipe"
dsr: would continue the
discussion
... how to handle change of the things
mm: regarding collaboration
... what's the plan of the prototype?
darko: continue to work on open source
mm: on the thingweb
mk: we can have some more local chats before lunch (if you want)
[ lunch and chat ]
(naomi joins)
mk: generated some rough sketch
here
... landing page is the overall information
... it's a lot of work to maintain this
... (shows several examples)
... also updated the whitepaper page
... link for developers
dsr: should put as an agenda item for the Chairs meeting
koster: calendar!
mm: 2 large categories
... f2f meeting
... presentations
mk: so much to do
<naomi_> kaz: there is a specific calendar page
<naomi_> ... we might be able to pick up wot events to link here
mk: need for calendar: easy for
people to get information and easy maintenance
... and then Charter, ML, participants, join the group
dsr: maybe could start with some intermediate page
mk: would update step by step
... that is the starting point
... for www.w3.org/WoT
dsr: outreach point of view?
mk: we should make better
impression
... but don't have enough time for blogging
dape: thre should be something up-to-date
dsr: blog post is some story on each
event
... could add a link to the blog page
dape: missing community group
dsr: trying to reboot the CG
... need a link to the CG
mk: what's the status?
koster: IoT vocabulary?
... probably as related work?
mk: should clarify the purpose,
etc.
... we have too many MLs, etc.
dsr: could simply add a link
(some more discussion)
mk: would add icon for vocabulary work?
<naomi_> kaz: we need to specify what kind of page should be linked
<img>
mk: will update the initial draft pages
mm: [Messaging]
... [Key Message Components]
... [Existing Key Value Message]
... What is the WoT and What is its value?
... need to sharpen the Charter text up
... essential difference between WoT and OCF
... [Proposed Key Value Messages]
... longer version
... 1. The Web of Things extends Web technologies to the IoT. It
enhances interoperability by providing a standardized descripton of
IoT network interfaces so that everyone can use everything
easily.
dsr: how to fit people's business?
mm: related to the #3
... The Web of Things approach enables a larger ecosystem of
things. IoT devices can use Web of Things standardized descriptions
to adapt to and communicate with devices from multiple IoT
ecosystems
... #2
... These standardized descriptions are based on standard web
technologies in common use such as JSON. An extension point to
support W3C semantic technologies provides powerful tools for
semantic interoperability.
... avoid using tech term, "protocol binding", etc.
... #4. Horizontal building blocks that span ...
... [Proposed Differentiation Messages]
... How is the WoT different from otehr IoT standards?
<mjkoster> (comment) need to focus more on delivered value in the value points page
mm: powerful
... 1. The Web of Things describes how to interact with things. It
does not prescribe specific network interfaces for things. Because
it can describe how to interact with many different standards it
can be used as a basis for a common ecosystem of things without
mandating how those things operate or communicate.
... 2. The W3C standards process is open and royalty-free. W3C
standards can be used by anyone and all specifications are
public.
... 3, 4, ...
... [Planning]
... online presence
... other collateral
... presentation material
... images and diagrams
... datasheet/brocure
... webex
... white papers
... tutorials
... executive summary
... online demos
... books
... executive summary for business people
kaz: proposals for the landing page?
mm: mostly
koster: 2 things
... historical stuff
... best practice
mk: meaning current practice?
koster: no, what we have doing
mk: working group lists drafts
... IG also lists notes
mm: use cases are important
... references for security as well
... links as kind of footnotes
dsr: sometimes better to describe
keywords?
... should work with the BusDev Team
kaz: already working with the MarComm
Team
... and Coralie Mercier, the MarComm head agrees
mm: should have joint calls with
them
... maybe in 2 weeks or so
<scribe> ACTION: kaz to talk with MarComm/BusDev Teams about the expected joint calls [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action01]
<trackbot> Created ACTION-108 - Talk with marcomm/busdev teams about the expected joint calls [on Kazuyuki Ashimura - due 2017-07-20].
matsu: we had some missing functions
during the PlugFest on Monday...
... so would propose something
... [DONE until Dusseldorf meeting]
... [Next step of plugfest]
... consider more practical use cases for the next plugfest
... cooperation of two/more WoT Servients
... entegraton of scripting apps and WoT devices
... e.g., the diagram at "5.4.2 Smart home" from the Architecture
draft
... [Some requirements for the next step]
... how to exchange TD between WoT servients
... how to manage TD among WoT servients
... how to connect WoT servients via firewall
... how to manage data of the devices to cache on the
Internet/Cloud
... should refine the Architecture draft and make spec!
kaz: you want to define "WoT interface" as the inter-servient interface. right?
matsu: yes.
mm: next plugfest would include
bridge between wot and ocf
... and possibly use recipe for automatic bridging
kaz: what do you mean by "recipe"?
mm: some kind of additional semantics
mk: we can look into the "WoT
interface" here
... e.g., oneM2M ones
... and wondering if it's possible to have yet another servient
matsu: possible
mk: local servient's capability mirrored by firewall gateway
mm: have to sort out how it
works
... with untrusted network
mk: part of other proposal on
security mechanism
... in addition to that viewpoint, various interfaces to be
connected
... HTTPS can be something related to authentication
soumya: @@@
mk: specific scenario or technical scenario?
soumya: technical scenario
mk: everybody doesn't have to do
everything
... we can share
mm: consider expected technical
infrastructure
... cloud, local network, firewall, etc.
mk: can provide cloud side in Munich, etc.
matsu: [Overview of our demonstration
in Osaka]
... smarthouse demo
... in Kanazawa far from Osaka
... also Nagoya
... HTTPS is one of the possible secure connections
kaz: so you want to try some other security mechanisms?
mk: e.g., CoAPS
... and proxying
mm: patterns we discussed regarding
node-wot
... single servient as a proxy
... can take on and make it work
kaz: will generate a wiki for TPAC
f2f
... so please put your scenario on the wiki asap :)
mk: need to talk about the next
f2f
... will be held during TPAC
... update on the preparation?
kaz: to be confirmed
mk: need confirmation for
Sunday
... and Wednesday demo
(like we did in Lisbon)
soumya: what for Sunday?
mk: preparation for plugfest
... need more preparation for smooth plugfest
... maybe full weekend (=2 days)?
mm: happy with 2 days during
weekend
... we could split plugfest into 2 pieces
... demo and presentation
mk: we don't really have "openday"
during TPAC
... Wed is the plenary day
... with several breakouts
... last week we talked with the Eclipse Foundation
mm: do we want to talk with others, e.g., Amazon?
mk: maybe weekend or maybe
Wednesday
... Mon/Tue we have our meeting
... because some people need to leave on Wed
mm: maybe some others of us can make
presentation, etc.
... Amazon has a (separate) hackathon place (Amazon Lab26)
... maybe kind of open
... in downtown SF area
... great way to get an engaged venue for plugfest prep
mk: Koster, could you please reach out them?
kaz: please let me check within the W3C Team about that as well
[note: we mean Nov. 4-5 by "during weekend"]
mk: PlugFest possibly on Nov.
4-5
... and WoT demo on Wednesday
<scribe> ACTION: kaz to talk with mtgplanner about WoT demo on Wed, Nov. 8 [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action02]
<trackbot> Created ACTION-109 - Talk with mtgplanner about wot demo on wed, nov. 8 [on Kazuyuki Ashimura - due 2017-07-20].
koster: possible a WoT hackathon?
mk: maybe too ambitious
kaz: do we want to invite non-Members to this PlugFest during the weekend?
mk: that's my expectation
... then
... after TPAC
... collocated with the Security Conf
... Spring 2018, USA?
... we should outreach them
mm: IEEE conference may be more appropriate
mk: waiting until May for the IEEE
one?
... you can discuss this internally
... not sure about CfP about this one (IEEE)
... also collocating with IETF
... same week?
... goes through the lists
... USA in spring, China and Lyon?
... regarding the spring one, not sure about the logistics
mm: was thinking mainly about San
Jose
... maybe Qualcomm is active on the February one
mk: we're still quite flexible
... spring and summer
... collocation with related conferences would guarantee people for
longer stay
... possibility in Princeton?
dsr: maybe MIT in Boston
mm: OCF has no information yet (for summer)
mk: TPAC in Lyon, France in
Oct.
... would continue discussion on spring in US/summer in Asia
... WG roadmap
... this is the original one
... the red part is where we are
... Architecture is high priority
... we have nice picture on the building block
... Kaz's figure as well
... device directly vs on cloud
... also Matsukura-san's work
... design patterns on proxy, etc.
mm: we can split design pattern from the Architecture spec
mk: regarding security review
... the questionnaire is not really appropriate tool for "security
review"
mm: architecture definition is not
yet completed
... we have to move faster
... the questionnaire is rather information gathering
... limited scope for security review
... still gathering requirements
mk: and something after Dussedorf
kaz: wonders about the concrete
publication date for the deliverables
... we could publish the Architecture document as a FPWD shortly, for
example
mm: need to define the minimal requirements for security review here
mk: would ask all the Editors for opinions
kaz: could ask the security tf to review the documents as an initial review
mk: Zoltan is one of the key persons
for scripting
... Kajimoto-san, Nimura-san for Architecture?
... Koster for binding
dape: we should keep the exploratory parts as well
mk: need to distinguish them from stable parts
kaz: we can distinguish unstable parts using, e.g., "Editor's Note"
zkis: regarding scripting, please
right an email or issue
... and let myself, Johannes and Nimura-san know
mk: would like to talk with Editors
kaz: tx
mm: we need test suites as well
kaz: would be better to have a table of progress on our deliverables
<img>
<scribe> ACTION: kaz to generate table of deliverable status to manage the progress [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action03]
<trackbot> Created ACTION-110 - Generate table of deliverable status to manage the progress [on Kazuyuki Ashimura - due 2017-07-20].
<scribe> ACTION: kaz to generate a doodle for the Chairs/Editors call to see the updated publication plan [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action04]
<trackbot> Created ACTION-111 - Generate a doodle for the chairs/editors call to see the updated publication plan [on Kazuyuki Ashimura - due 2017-07-20].
<scribe> ACTION: kaz to create a GitHub repo for the Security TF [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action05]
<trackbot> Created ACTION-112 - Create a github repo for the security tf [on Kazuyuki Ashimura - due 2017-07-20].
[break]
mk: possibility in Asia at Keio or Beihang
<scribe> ACTION: kaz to ask Keio and Beihang about possible WoT meeting in Asia in spring or summer [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action06]
<trackbot> Created ACTION-113 - Ask keio and beihang about possible wot meeting in asia in spring or summer [on Kazuyuki Ashimura - due 2017-07-20].
mk: we have so many calls
... (shows slides)
... [Binding Templates TF]
mm: OCF Liaison TF might be able to shutdown at the moment given we're doing discussion on binding
mk: WG (delivery deadline 2018)
... vocabulary proposals for TD TF (under "link")
... targets: HTTP, CoAP, OCF, oneM2M
... [Scripting API TF]
... [Security TF]
... have to change some hybrid approach, top-down and
bottom-up
... for security review
mm: review Editor's drafts
... creating a new GH repo for the TF
... security sections for other deliverables
... need coordination
mk: is that all?
dsr: semantic part of the LD TF would
go for part of TD
... there is an overlap
mk: let's do a doodle for the binding
template tf call
... TD TF
... WG: TD core model and JSON-LD serialization
... IG (validation): JSON serialization
... Binding Templates TF
... default interactions
mm: secure connection, e.g., HTTPS, CoAPS
mk: IG (validation): WebSockets
... IG (explorative): MQTT
... Panasonic is using WebSocket for event handling
... what's the difference with Mozilla's proposal?
... (WebSockets goes to WG)
... OMA LwM2M goes to IG (validation)
... SSE added to IG (explorative)
(discussion on how to deal with ECHONET, BACnet, etc.)
(binding template implementations)
mk: have an implementation in node-wot
mm: mentions web storage kind of mechanism
mk: have local communication in
node-wot
... local communication added to IG (explorative)
... check with Web APIs
... Scripting API TF
zk: we made a decision for a device
expose capability as service rather than api
... WG: scriptin gAPI, servient architecture
dsr: semantic annotation
mk: how semantic annotation would
appear within scripting api
... (adds "support for semantic annotations and other TD
customization")
... [LD and Semantics TF]
... (asks Zoltan to review the Scripting API part)
zk: ok
mk: [Security TF]
... WG: review all the Editor's drafts
mm: who is in charge of which?
... can we securely connected with WoT?
mk: possibility in Asia at Keio or Beihang
<scribe> ACTION: kaz to ask Keio and Beihang about possible WoT meeting in Asia in spring or summer [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action07]
<trackbot> Created ACTION-113 - Ask keio and beihang about possible wot meeting in asia in spring or summer [on Kazuyuki Ashimura - due 2017-07-20].
mk: we have so many calls
... (shows slides)
... [Binding Templates TF]
mm: OCF Liaison TF might be able to shutdown at the moment given we're doing discussion on binding
mk: WG (delivery deadline 2018)
... vocabulary proposals for TD TF (under "link")
... targets: HTTP, CoAP, OCF, oneM2M
... [Scripting API TF]
... [Security TF]
... have to change some hybrid approach, top-down and
bottom-up
... for security review
mm: review Editor's drafts
... creating a new GH repo for the TF
... security sections for other deliverables
... need coordination
mk: is that all?
dsr: semantic part of the LD TF would
go for part of TD
... there is an overlap
mk: let's do a doodle for the binding
template tf call
... TD TF
... WG: TD core model and JSON-LD serialization
... IG (validation): JSON serialization
... Binding Templates TF
... default interactions
mm: secure connection, e.g., HTTPS, CoAPS
mk: IG (validation): WebSockets
... IG (explorative): MQTT
... Panasonic is using WebSocket for event handling
... what's the difference with Mozilla's proposal?
... (WebSockets goes to WG)
... OMA LwM2M goes to IG (validation)
... SSE added to IG (explorative)
(discussion on how to deal with ECHONET, BACnet, etc.)
(binding template implementations)
mk: have an implementation in node-wot
mm: mentions web storage kind of mechanism
mk: have local communication in
node-wot
... local communication added to IG (explorative)
... check with Web APIs
... Scripting API TF
zk: we made a decision for a device
expose capability as service rather than api
... WG: scriptin gAPI, servient architecture
dsr: semantic annotation
mk: how semantic annotation would
appear within scripting api
... (adds "support for semantic annotations and other TD
customization")
... [LD and Semantics TF]
... (asks Zoltan to review the Scripting API part)
zk: ok
mk: [Security TF]
... WG: review all the Editor's drafts
mm: who is in charge of which?
... can we securely connected with WoT?
[ network disconnected ]
[ some more discussion based on Matthias's slides ]
[ Dusseldorf F2F adjourned ]