<kaz> Agenda: www.w3.org/WoT/IG/wiki/F2F_meeting,_16-19_March_2020,_Online
<kaz> scripting: Christian
<kaz> architecture: Daniel
<kaz> security: Kaz
<kaz> Discovery: Zoltan
<kaz> scribenick: kaz
McCool: if any problem, please speak up immediately
[Kaz explains the W3C Patent Policy quickly to the invited guests. He also added resoureces on the W3C Patent Policy to the "Preliminaries" section of the agenda. All the participants should be aware of the W3C Patent Policy and possible Royalty-Free commitment on the technical discussions during this virtual f2f meeting.]
Notes on the W3C Patent Policy
Sebastian: looking forward to the
discussion this week :)
... any comments, questions?
(none)
Sebastian: let's start then!
<scribe> scribenick: glomb
<zkis> Link to Scripting agenda: https://docs.google.com/presentation/d/1GvBcikn7j1qqZ6uC1YBw88AA6J6sYwvyIGeL5-eddzA/edit?usp=sharing
Start Scripting API session - lead Zoltan
ExposedThing implementation -> scripting related questions
Error handling -> how to report to scripting?
Discovery to be harmonized w/ scripting
Semantic API proposal from Michael Koster
Script deployment & management -> also to be covered in architecture
<inserted> Issue 156
Exposed thing #156 issue
how to implement exposed thing
Dictionary -> TD template, create protocol bindings
How to adapt data to run time?
Handling of different content types?
Daniel: node-wot handling
TD snippet provided, than create exposed thing
node-wot does not look into forms
forms highly depend on run-time
e.g. if only support for http, doesn't make sense to address different protocol
content type to be interpreted correctly -> todo in node-wot
forms handling not fully specified
proposal: skip not implemented protocols, so you could specify protocol in TD forms snippet
runtime implementation might report its protocol support
content type vs data schema #201
algorithm to match type <-> schema
forms might have different protocol, encodings -> how does consumer pick one
McCool: implement content negotiation
protocol tag?
which then defines endpoint
TD spec or scripting?
zoltan: also define algorithms to handle user input (TD templates)
kaebisch: concrete content type for the producer
IETF standard for URL patterns?
https://tools.ietf.org/html/rfc6570
<McCool> mccool: agree on use of URI templates, makes sense
<Ari_Keranen> URI templates: https://tools.ietf.org/html/rfc6570
lagally: be clear about requirements
zoltan: as a solution developer i want to create exposed things, not want to create a TD for every platform, insure interop
lagally: TD template used in a specific way in TD spec
zoltan: maybe "init dictionary"
in scripting "TD template" is constrained on the protocols
<scribe> New term?
in Scripting
TD template: w/ or wo/ protocol definition?
Wording and concepts different in Scripting and TD
Clear terminology!
Scripting -> rather a dictionary
TD template as input for "dictionary"
"Partial TD" ?
Security info is fine to be in Partial TD
no keys, etc. inside
but has to match with additional sec. info
if available elsewhere -> to be filled in automatically
multiple scopes might be in forms
Daniel: mixture "global" sec and interaction affordance specific sec
possible according to TD spec
zoltan: after produce query TD
then see how device it set up
node-wot pull #187
content types other then json
than
<McCool> mccool: summary of what I said: TD supports both global security scheme and per-form schemes; scripting API needs to allow specification of both; also, per-form information like scopes and per-form security schemes should be interpreted and used
<kaz> TD Pullrequest 869
<kaz> Ege's comment
CBOR currently not supported in node-wot
Jennifer: need example how to use
handle binary content according to content-type
two cases: json w/ binary vs. entire binary
<kaz> Scripting Issue 201
e.g. image inside json structure
media related use cases -> architecture TF
have appropriate mechanisms to create / consume (binary) content
video streams -> delegate to (outband) protocol
Kaz: we should remember to consider concrete use cases like video streaming from the MEIG as well when we think about binary data within the context of WoT: how to handle data wo/ mime type?
McCool: quite complex, first stick to mime-typed data
POC might help to identify real issues
and gaps
Daniel: semantic api proposed by m. koster
e.g. readproperty wo/ property name but based on semantic annotation
layered approached
extend core Scripting API
e.g. tooling / convience layer above Scripting API
Core API KISS
still an issue...
McCool: semantic API for interface -> manage name conflicts
<kaz> Scripting issue 204
deployment w/ scripting -> older proposal
constrained device vs. more powerful nodes
needs POC work
e.g. WASM+WASI
solves multiple languages problem and (partly) security
WoT inside web browsers :-)
COFFEE BREAK
<kaz> [session 1 adjourned; 5min break; then Architecture session]
scribenick: dape
<inserted> Agenda
a>Lagally: talk about TF agenda and
goals
... consolidate use cases
... WoT profile (use cases & requirements, strawman
proposal)
... today we will cover maybe sync arch status and parts of
consolidate use cases
... On Sync
... looked into life cycle
... have life cycle model
... we have been collecting use cases
... on GitHub
... e.g., define "partial TD" and "Thing Template"
... in WoT repo we have USE_CASES folder
... use template to collect use cases
Sebastian: Collecting technical use cases?
Lagally: Try to get everthing (full
overview)
... try to identify gaps (functional vs non-functional
requirements)
<kaz> Use Cases
Lagally: Why use-cases:
... - determine target areas and scenarios
... - identify business-relevant work
... - identify gaps of existing specs
... - define common terminology
... - define scoep of spec work
... - collct requirements
... Architecture Process
... use-cases --> shortlist --> gaps/building blocks
--> requirements --> address specifications
... Stakeholders:
... - device owners
... - device user
... - cloud provider
... - service provider
... - device manufacturer
... - gateway manufacturer
McCool: overlaps in stakeholders
Lagally: Agree, can be overlap
McCool: directory service provider should go away... discovery only
Ege: "Service" means client side?
Lagally: "Service" is offering something to customer
Ege: combination of multiple other roles?
Lagally: integrated service across
devices
... not application specific
... Domains
... - smart cities
... - industrial
... - transportation
... - manufacturing
... Is there a domain missing?
McCool: vagueness ... manufacturing
vs industrial
... however, list looks complete
Sebastian: I miss agriculture
Lagally: It is a domain, miss use case though
Ege: In Princeton we had agriculture use cases
McCool: also smart building
Sebastian: also airports et cetera
McCool: right, public spaces, hotels, ..
Kaz: w.r.t. agriculture. There is a community group. can ask them
Lagally: Do they have use case document?
Kaz: Not sure. Have been thinking about terms & terminology. Can try to check with them
McCool: Park management, out-side space management, nature park, ..
Ege: smart home vs home automation?
<Zakim> kaz, you wanted to mention the agriculture cg
Lagally: probably need to align that
<kaz> i|Do thy have|Agriculture CG|
Zoltan: emergengy infrastructure ? Defence?
McCool: Military is important but suggest post-poning it for now
Lagally: Reviewed use cases
... - big data
... - device lifycycle
... - digital twin
... - GPS module
McCool: use case can address multiple domains
<kaz> +1
Jennifer: problem indoor to outdoor. need to figure that out ourselves
Sebastian: interesting use-cases
McCool: precision is also of interest... can change over time
Ege: w.r.t. accuracy topic:
different terms people use (accuracy, precision, resolution,
...)
... w.r.t. digital twin use case: can be general use case
Lagally: help w.r.t. requirements
would be good
... ... - retail use case
... - x-protocol interworking
McCool: does it include proxies?
Lagally: Not yet described but
yes
... MMI use cases
... coming from MultiModalInteraction group
... WoT use cases (UCR)
... lacking some reviews
... e.g, smart grids, health care
McCool: recall distributed energy system use case (Siemens)
Christian: both, smart grid and energy automation
Jennifer: we might have use case for healthcare
Lagally: miss reviewer for healthcare (see https://cdn.statically.io/gh/w3c/wot/aa90b2b8/ucr-doc/index.html)
Sebastian: I do recall Dave Ragett was
providing this use case. Could ping him
... can contact him
Kaz: can work on this topic also, if Dave is busy
Lagally: Use cases in work
... - semantic interop
... - smart home interworking
... - media streaming
... - onboarding
... - edge device
... Use case at risk (no owner yet)
... - fleet managament
... - data streaming
... - video/audio treatment
... - agriculture
... Backlog
... home networking scenarios (MEIG use cases)
... verifiable credential use cases
... Shortlist of use cases - selection criteria
... 1. business relevance
... 2. WoT member relevance
... 3. active contributor
Kaz: logistical question: create place on Github to put slides
Sebastian: suggest adding presentations
to agenda
... (Kaz's suggestion is putting slides on GitHub, and then add
links from the agenda wiki to those slides on GitHub :)
use-cases: Do you ML expect big impact on architecture
document
Lagally: stomach feeling: for discovery some more requirements, for TD some extensions, ...
<kaz> [Architecture session adjourned; 3min break; then Security session]
<McCool> mccool: singapore health care use case https://www.straitstimes.com/singapore/health/coronavirus-new-ai-driven-temperature-screening-device-to-save-time-and-manpower
<kaz> scribenick: kaz
McCool: a lot of topics here
... including IETF Anima and OPC-UA
... would like to go over onboarding as well
... my hope was capture some discussion and input about what
"onboarding" would be
[slides]
McCool: Requirements Gathering
... provisioning levels
... different keys for different services
... what is "onboarding"?
... and what is the scope of WoT for onboarding?
... managing large number of devices
... we should discuss it
... Provisioning vs Registration
... 2 separate things for the lifecycle
... easier to separate them
... provisioning
... generate unique identity for a device
... assign keys and access right to a device
... registration
... more discovery topic
... separate things
... directory and registry
... make discovery easier
... nneds to register identity
... provisioning comes first
Lagally: keys...
... what kind of keys do we need?
McCool: 2 problems...
Lagally: this kind of onboarding
definition is abstract
... identify devices automatically
McCool: the issue with "key" is key
and lock
... keys also use signiture
... what access right would you get?
... onboarding has 2 phases
... assign the right and establishing the trust
Lagally: who would do that?
McCool: there is a separate
tool
... user makes the decision for the permission
... could also imagine the other approaches like Mozilla
WebThing
... it varies
Lagally: would like to recap the
stakeholders
... the "user" here might be identity provider or something
else
... maybe we need one or two more
... who is the stakeholder here?
... who is defining the rights
Zoltan: for example, the terminology is defined by somebody like OCF, and we can describe that
Sebastian: make some technical decision
here
... and based on some specific technology
... what would be the major context?
... is there any firm framework we should follow?
Lagally: what is the use case?
... and how to solve it?
Sebastian: do we make some concrete
mechanism for onboarding?
... just reuse some existing one?
Ege: how can we describe
onboarding mechanisms?
... in a way like MQTT
... connect to some broker and get information
McCool: good point
... do I have relationship to TD or directory service?
... once we have onboarding process, we can describe that
Lagally: metadata field with well-know name?
McCool: more than that
... (add notes to the "Discussion" slide)
... in DID there is a proof section
... even referring a public key, it would be dangerous
Kaz: how about looking at the
stakeholder diagram from the DID doc and the VC doc again to
see the basic architecture for onboarding/discovery?
... and also we should think about some concrete use cases
McCool: we'll talk about DID with Manu on Wednesday
https://www.w3.org/TR/did-core/ DID Core
https://www.w3.org/TR/2020/WD-did-use-cases-20200130/ DID use cases
https://www.w3.org/TR/vc-data-model/ VC data model
https://www.w3.org/TR/vc-use-cases/ VC use cases
Zoltan: onboarding mode vs operation
mode
... would like to take the easiest way
... e.g., looking into OCF way
McCool: related to the issue on our
scope
... how to handle the onboarding topic
... where we start
... discussion on lifecycle?
Lagally: should not discuss lifecycle at the moment
Philip: we're still at the very early
stage
... how we can deploy this is my question
... security within the browsers
McCool: requirements should be
documented
... we should also have guidelines for security
recommendations
Philip: agree
... maybe up to the implementations
... whether OAuth2 or anything to be documented
... need clear understanding for onboarding, access controls
and authentication
McCool: how to handle the roles,
scope
... we should look at OAuth2 as one of the best practices
... we'll look into node-wot for that purpose on Thursday
Philip: tx
McCool: (create a section of "Need
recommended best practices" section to his slides)
... Oliver, can you take over the discussion for your
lsides?
Oliver: IETF Anima and OPC-UA
... 2 slides for introduction
... and 5 slides for the description
... the Challenge
... prepare for security
... there are many specification camps
... manufacturing, bootstrapping, operational, maintenance,
off-boarding
... we want IoT/OG components to interact securely for the
operational phase
... so something to be done at the bootstrapping phase
... and maybe the manufacturing phase too
... the following slides outline the IETF Anima and
OPC-UA
... some cryptonite
... terminology from IEEE
... LDevIDs/IDevIDs are triplets
... private key as the starting point
... certificate containing a public key
... root CA certificate
... there is no one-fits-all
... when you think of components
... there are multiple stacks
... we're looking at tools
... IETF Anima
... mostly focused on IoT/OT component
... timeline starts with manufacturing
... manufacture credential: IDevID EE, EDevID CA
... then bootstrapping: site credential(s): LDevID EE, LDevID
CA
... IETF Anima: Which Patterns are covered?
... IETF Anima: What are the main ingredients?
... actors: site and manufacturer
... 4 technical components
... pledge including IDevID, Join Proxy, Registrar including
IDevID CA certificate
... and MASA (manufacturer authorized signing authority)
... (data transfer sequence)
... discover
... .1a. voucher
... 1b. voucher status
... IETF Anima: How does the protocol stack look like?
... 7-layer diagram (OSI diagram)
... physical, data link, network, transport, session,
presentation, application
... IETF Anima: Takeaways
... covers the credentialing of IoT components
... limited to X.509 certificate form-factor
... uses HTTP-over-TLS
... OPC-UA: What does happen inside IoT/OT components?
... OPC-UA: Which patterns are covered
... internally-triggered pull, externally-triggered pull
... ...
... OPC-UA: What are the main ingredients? for pull
... transfer sequence
... OPC-UA: How does the protocol stack look like
... protocol stacks similar to IETF Anima
... OPC-UA: Takeaways
... also covers the credentialing of IoT components
... difference from IETF Anima
... site-controlled
... limited to X.509 certificate form-factor
... arbitrary PKI hierarchies, CRL-based revocation
... uses the native OPC-UA stack for the credentialing
interactions
Philip: question about key lifecycle
management
... how does the OPC-UA manage recycling the keys?
... any provision about key lifecycle managment?
Oliver: just have the yellow
portions
... all of the period is defined by OPC
... can be automated
... and the answer for IETF domain
... it has black portions
... for manufacturer credential management
... the recommendation for this black portion depends on each
algorythm
<McCool> ACTION: mccool to capture lifecycle stages for key renewal
Philip: if we don't have automated management mechanism, it would be a nightmare...
McCool: would like to capture the key
lifecycle managmeent
... would like to look into OCF model as well
... OPC-UA uses a credential management mechanism for
registerer
... would like to suggest we thank Oliver for his explanation
first
... put the slides somewhere
Oliver: will do
McCool: on the GH repo?
<zkis> This OPC-UA mechanism is similar to the manufacturer certificate onboarding in OCF (one of the 4 main OCF onboarding mechanisms)
McCool: you can create a pullrequest
for that purpose
... now would like to wrap-up the session
... and start the next session in 6 mins
[security session adjourned; 6min bread; then discovery session]
McCool: guests from GoDaddy
Sebastian: and Kevin from Bosch
<zkis> scribe:zkis
<kaz> mm: do you have any resource to be referred to?
<kaz> ko: can show some slides
KO presenting Eclipse Vorto
Kevin: open source, vendor neutral
semantic IoT device modeling
... describe, integrate, share
... share in device repository
... different implementations, for Bosch and others
... our interest in WoT is TD and TD Template
... they are quite aligned with Vorto
... we could generate a TD template based on a Vorto
model
... need more experimenting
... next step is to manage TDs in Vorto repository
... third level to turn Vorto into a TD template
repository
... and deliver more value on top of TD
... questions?
McCool: suggest to continue this
discussion in next week's Discovery call
... there are couple of questions: directory, discovery, TD
template etc
Lagally: what is the definition of a Vorto template?
Kevin: Vorto has an info model
(types of digital twins) and then there are Function
Blocks
... in WoT Property, Action, Events and in Vorto there are
similar notions
... for interactions
... TD template term was used from TD spec
Koster: looks like there are a lot in
common
... need specific examples for both Vorto and TD
Kevin: agree, it's a good idea
<kaz> +1
McCool: let's continue the discussion on next Monday, Discovery call
<McCool> https://github.com/w3c/wot-discovery/blob/master/requirements.md
McCool: we have local, global and
directory discovery
... means getting TDs that meet certain criteria
... we have proposals that include directories and ones that
don't
... privacy is an issue
... we cannot just broadcast TDs
... there could be a context for that but not by default
... we should be aligned with existing work and standards
... need a mechanism to accommodate various brown field
solutions
<kaz> (two-phase discovery)
scribe: the general idea is to have an intro phase and exploration phase
McCool: we need a first contact
protocol
... with minimal info to bootstrap the next stage
... which is an active session that requires authentication and
authorization
... the first stage supports brown field protocols like QR
codes and NFC etc
... the second phase is to be standardized in WoT and might be
based on directories
... for first phase anything returning a link would be a
candidate
... in existing solutions a list of tped links is used, e.g. in
CoRE resource directory
s'tped/typed
scribe: may point to a
directory
... or a Thing (a very simple directory)
... semantic search could be supported
... in exploration phase (2nd phase) we could have a queryable
directory servcie
... then, we could have gateway functionality e.g. for
onboarding or management of id's
... to break fingerprinting
... mutable id's need a mechanism to notify the users
McCool: privacy issues
... 2-phase approach not enough to preserve privacy in all
cases
... for instance location fingerprinting or triangulation
... which can be inferred by various other information
... another issue is that even if 1st phase returns a list of
directories, even from that list location could be
inferred
... without having the authority to access that
information
... Scripting Discovery API doesn't mention directories
Zoltan: they do :)
McCool: question is how to handle
the 2-phase with that API
... we might break down the Scripting API Discovery from the
rest
Zoltan: it's already separated in separate conformance classes
McCool: one problem, how to discover
directories
... it may be an internal mechanism
... next, we have left some time to discuss
McCool: there is an IETC WG looking
into this
... DNS is a distributed DB to look things up
... include additional data into this
... typed links
... another extension is location based data
... right now the query is (name, address)
... this could be extended with new attributes like
location
... for spatial queries
... this would fit in the 1st phase
... then we'd have a second phase based on directory
... directory for a certain region
... one question in general: there is a tension including other
metadata in the first contact protocols
... certain devices have private information, the type of
device for instance
... question: which data goes into the first contact protocol
and which data into the rest
... there is a CoRE RD for this
... but there are other ways of doing it, too
... so Chris' presentation will be covered later
... questions on the DNS material?
<Zakim> kaz, you wanted to ask Christer Holmberg's affiliation
Christer Holmberg joins as a guest from Ericsson.
Working with Ari in Finland on IoT.
McCool: we will follow up on
semantics and semantic search
... previous work on Thin Directories supporting semantic
queries / SPARQL queries / template based search
... we need to consolidate prior work on this
Sebastian: this 2-phase discovery approach is protocol specific?
McCool: no, it's a pure
framework
... need to figure out what is descriptive and what is
normative
... being only descriptive will not work (with
Discovery?)
... we can manage security better this way
... we can implement multiple discovery services running on the
same device that can be run in parallel
... with other forms of discovery (like OCF, WoT, etc)
... the framework needs validating now
Victor: prepared some slides
Christian: made a PR for use cases
... in WoT Discovery github
<kaz> PR 4
McCool: first we were meant to
collect use cases and then brainstorm
... we meant to merge discovery use cases into Architecture
spec
... we could sanitize the use cases but they are just a first
step for providing new use cases for Architecture
Christian: still, it would help using
more structure
... we can discuss it later
McCool: OK, we can discuss
later
... the use cases here is more like background work
... it needs to be updated
... we need to capture existing work
... not all of that has been done
... need a volunteer to dig up historical work and create an md
file
... first, find all relevant info in the IG repo and list it in
the md file
... everyone who has done prior work could add a link to their
contribution
<kaz> Issue 6 on previous work assigned to Koster, McCool, Victor and Daniel
<kaz> Tuesday agenda
Sebastian: thanks for the first day, it has worked very well
Sebastian outlines Tuesday's agenda
<kaz> kaz: please let me know about the email addresses of the possible guests
<kaz> [Day 1 adjourned]
scribenick: kaz
<inserted> Cristiano Aguzzi from Univ. Bologna
<kaz> W3C Patent Policy
<kaz> Patent Policy FAQ
<kaz> Architecture: Zoltan and Sebastian
<kaz> TD: McCool
scribenick: zkis
Lagally: summarizing yesterday's presentation about use cases
[ML pres link]
Lagally: use case management
... use cases in the github repo, organized in domains
... we have assigned people to care about use cases in each
domain
... Healthcare domain needs an owner
McCool: could take that up with Jennifer
Lin
... but this is only one use case so far
... it might have regulatory issues
Lagally: TD could be still used
McCool: health has 2 categories, regulated and non-regulated, the latter is a problem
Lagally: ok, we keep it open
Taki: could also volunteer for Medical
Lagally: use cases in work
McCool: these are more like technologies
than use cases
... we should look at existing use cases that match with these
Lagally: right, we want to detect the
dependencies
... some use cases don't have an owner, like fleet management, data
streaming, audio/video, agriculture
McCool, Jennifer, Philip volunteer for Fleet Management
For data streaming, Dave Raggett with question mark
For Audio/Video "treatment", issue-8 in architecture github
McCool: we can merge this
Kaz: we can combine this with other media-related use cases and close this one
Lagally: combined with issue-442 in architecture
McCool: we need to ask Dave whether could take Video/Audio domain
Lagally: Kaz, please ask Dave
<kaz> ACTION: kaz to ask Dave about his issue on data streaming use case
Lagally: finally about Agriculture domain
Taki: take it with Matsukura-san
<kaz> (Kaz will also ask the Agriculture CG guys as well)
Lagally: use cases are grouped based on
business relevance, WoT member relevance and by number of active
contributors
... that was recap from yesterday, now we move on to today's
topics
McCool: presenting uses cases from architecture github
[link to USE-CASES]
<kaz> retails use case
McCool: presenting the retail use
case
... related to the PoC to be presented tomorrow
Lagally: we have separate md files in WoT architecture github
https://github.com/w3c/wot-architecture/tree/master/USE-CASES
McCool: in each use case we need to make
a list with related components
... so that we could relate these across use cases
... also for dependencies such as security related things
Kaz: what do we mean by
"dependency" here?
... for instance "WoT Profiles" is listed
... maybe use a different name, like "dependent topics"
McCool: we should add description for each section in the template
Lagally: right, they are not very complete
McCool: what about "Target Users"
<kaz> ACTION: Lagally to improve the description on what the "Dependencies" section means in the use case template
Lagally: let's pick a realistic date and
complete the use case consolidation
... for instance in 2 weeks time
Lagally: for Q1, completing requirements and use cases should be realistic
McCool: Jennifer was asking if we can go
through the Singapore use cases
... will coordinate off-line
Lagally: we have quite a list of use cases
and requirements from the new WG charter
... these require architectural input
McCool: which version of the charter was that?
Lagally: last year Oct-Nov
McCool: the descriptions should be updated based on latest charter version
Lagally: OK
... presenting requirements
<mlagally> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/requirements-template.md
<McCool> mm: regarding my comments regarding thing templates, never mind, I looked it up, and the current one-liner does mention classes, etc.
<McCool> mm: https://www.w3.org/2020/01/wot-wg-charter.html
<mlagally> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md
McCool: is security included here?
... in each use case we need to consider dependency on security,
discovery, etc
Lagally: McCool, please update the text
... with the security checklist
... and others may add others checklist
McCool: will create an issue and follow up
<McCool> mm: issue to add deliverables checklist to requirements template: https://github.com/w3c/wot-architecture/issues/457
<Zakim> kaz, you wanted to provide some resource on ISO 19116 "Geographic information"
Kaz: I was involved in the Geolocation
WG, so thanks for including the Geolocation API.
... My suggestion is adding ISO 19116:2019 as well. There was discussion about the
basic mechanisms and also accuracy of geolocation information
<kaz> ISO 19116:2019
McCool: also add OGC and ETSI to "related standards"
Lagally: affects almost all specs
... this is a substantial change
McCool: yesterday we discussed the role
of Scripting and protocol constraints
... we could capture that as a note or TODO
https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md
McCool: we should define Thing interface
vs template
... for me template means "partial"
... it also shows up in discovery
Sebastian: we should be careful to not
introduce so many TD related terms
... this would be confusing
... the concepts are not that different
... we can discuss that in the next session
... to avoid complexity
Lagally: agree, this just tries to capture eventual differences
Sebastian: we need a definition for "template"
Lagally: we can discuss this either this
week or in architecture calls
... we need to keep terminology clear
McCool: we need to identify who needs
templates
... for instance scripting, discovery, etc
... and then we can decide if they are the same thing or not
Zoltan: agree with McCool
Lagally: agreed
McCool: we need to investigate 3 things:
interface, scripting, search template
... and see if they are the same or not
Ege: template is anything that does
not have instance information
... for instance href with specific URI
... this is a requirement for Wotify
<McCool> mm: by the way, time check
Lagally: well, something like a stripped-down TD, or subset of a TD
Ege: everything that changes is not a template
Sebastian: this is a very old topic, we
discuss this from the beginning
... I think we don't need more time on this, but work on technical
realizations
<McCool> mm: I don't think we need to "collect" requirements, but we do need to write them down
Lagally: we anyway need to document what we mean by the terms
Sebastian: we also have plenty of issues in
the TD repo related to this
... and I'd like to discuss that in the TD session
Kaz: technical details in TD session should be ok but it should be discussed based on how templates are used in use cases
[Architecture session adjourned; 3min break; and then TD session]
<McCool> scribenick: McCool
<kaz> Agenda for today
guest: Ben Francis, Cristiano Aguzzi
Sebastian: reviews agenda, notes many
issues for templates, efficient TD encodings, security aspects (esp
OAuth2)
... (sharing presentation)
... reviews what we have done and its motivations
...started with basic idea of affordances, now have a good data model and experience via plugfest
... we need to celebrate this accomplishment, unfortunately not
together
... of course much work yet to do; right now we are like HTML1.0;
lots of things, but basic functionality is there
Sebastian: we have discussed requirements
in the previous call
... also interesting to hear from Bosch that they are using
something like templates in their system
... there are multiple reasons why we need templates
... there are different phases during development, and during some
of these phases the information will be incomplete
... in the planning phase, may have some rough templates to decide
on basic affordances, then look at data schemas, etc.
... we should consider the requirements for TDs in these early
stages and applications
... we also want templates to describe "classes" of devices
McCool: comment, not just classes, but "sub-interfaces"
Sebastian: and in scripting we also see a need for a partial TDs
Lagally: we do have two use cases that apply; digital twin and big data
Sebastian: think there are many more use
cases
... also, in digital twin, also represent classes of devices
... this topic is actually very old, we have lots of use cases
Lagally: we have been discussing this for
a long time, is existing text
... we should be careful not to miss any requirements
... simulation
... we need to cross-check against what we have; if something is
missing, we need to document it
Ben: two points
... looking at the use cases that relate to templates
... would argue that every TD is a digital twin
... when do we pass a TD?
... vs a template? why not just always compose on the server?
Lagally: there are uses when we are composing TDs from components, etc.
Ben: other question is difference
between templates and capability schemas
... capability schemas describe classes of devices, and can be
inherited that way
... seem to be some overlap between these
Lagally: we don't yet have capability schemas as a formal component of WoT
Koster: ODM does provide capabilty schemas
Ben: if think of templates as classes
and objects
... TDs are instances, capability templates are classes
Koster: ODM do define an object and
capability model, can b e composed
... see capabilities as a way to pregenerate metadata, but not at
the level of specific instances
Ben: don't quite understand where and
when the composition into instances happens, on the server or
client
... do TDTs belong in the TD specification?
Koster: good question; do we need a spec
for "partial TDs"; what parts you need depend on the workflow
... as noted, there are multiple applications
... for template-based search; for hypermedia forms (eg actions);
and for classes as noted
Ben: makes sense you need templates
"internally" on the server side
... one use case that is client-side is discovery templates
Sebastian: comment on why we need in
spec
... right now we describe what is a valid TD
... need to clarify what is the difference between a full TD and a
template
... example is a bulb, that has everything but the specific IP
address it is at
Lagally: we mixing the notions of templates and partial TDs
... let me show you what the current spec says
<mlagally> A Thing Description Template is a description for a class of Things. It describes the properties, actions, events and common metadata that are shared for an entire group of Things, to enable the common handling of thousands of devices by a cloud server, which is not practical on a per-Thing basis. The Thing Description Template uses the same core vocabulary and information model from ยง 5. TD Information Model.
Lagally: is from the appendix, so is
informative, but it is a definition
... more than just a partial TD, has specific required information,
namely affordances
Koster: partial TD may not be consumed by
the client, but may be used in other places
... hypermedia controls and search templates
... and then there is the process of creation
... library of things to compose things is useful
<inserted> scribenick: zkis
McCool: categorize use cases to client vs
server side
... search templates is client side
... but first we capture requirements
<inserted> scribenick: McCool
McCool: I think we need to step back here
and list use cases and requirements here
... also note that hypermedia controls are client-side use
cases
Zoltan: would say that scripting use case isn't exactly a partial TD, but a dictionary
Sebastian: problem is we need a concrete definition; to my understanding, everything mentioned so far would be a template
Kaz: discussion reminds me that we
should look at classes and interfaces
... we should open up the discussion to additional use cases
Sebastian: how complex do we want to make this?
Kaz: we have to consider what use cases we really need
Lagally: complexity will depend on what we need
Sebastian: in the slides I tried to come up
with a minimal definition
... it is clear that TDT <= TD
... but how minimal? is {} a TDT?
... do we want to add an @type to identify a TDT?
Lagally: there are identifiers in
TDs
... we need to have two things; unique identifier for templates so
they can be referred to (eg as interfaces), e.g. templateID
... we may need an extension
Zoltan: why do we need ids for templates?
<benfrancis> How about a separate context for TDTs vs. TDs which could have different validation requirements...
<benfrancis> {
<benfrancis> "@context": "https://www.w3.org/2020/wot/tdt/v1"
<benfrancis> }
<benfrancis> (note "tdt" vs. "td")
Lagally: so we can manage them and refer to them
Sebastian: why not just put them in a database?
Lagally: need to find them
Ege: agree that we need an id, but it should be a new field to avoid conflict with existing spec
<benfrancis> The URI of the template resource could be used to identify a template, no need for an ID inside the JSON payload
Koster: we may not always need an id if it is something like a hypermedia control
Ben: should we have a separate context
URI for TDTs? And maybe a different specification?
... do you need an ID, or just a url?
<Zakim> dape, you wanted to if we introduce a *new* ID for template... -> TDT is not a subset of TD anymore?
Daniel: comment on ids vs. contexts
... if we add a separate context, then the subset relationship might get broken
... new id, or new context, then we won't have TDT subset of TDs
... won't be the case if TDTs have extensions
Lagally: comment on bf's comment about
URIs
... because URI is a way to look something up where it is stored,
but for databases we need the ID independent of location
McCool: note that ids are currently URIs, but if we want to decouple IDs from location we should use something like DIDs
Sebastian: we are looking for what is the minimal definition that fits the use case we want to target
McCool: we should define the use cases first, then...
Lagally: we have a working definition...
Sebastian: but it is just informative; not binding
Lagally: let's take this offline, let's
work on the issues to create definitions for TDTs and partial
TDs
... once we have definitions, we can discuss details
... we each have a different definition in our heads; let's discuss
using a concrete text
Zoltan: for the id, is use case for
databases, etc.
... suggest we take it use case by use case, identify universal
requirements
... still need to understand a few of them, eg management use
case
Lagally: I understand at least three: hypermedia, discovery, interfaces
Kaz: agree that we should go back to
use cases to clarify this discussion
... we should not think about concrete notation just yet, but about
requirements
Taki: one use case I have seen is
interface management; have been assuming each has an ID
... since it is a "definition", and we want to relate instances to
the interfaces they implement
Sebastian: seems we still need to clarify
the motivations and requirements, especially for IDs
... as proposed, we have to continue discussion based on use cases
and issues
Lagally: (put issues here in minutes)
<mlagally> https://github.com/w3c/wot-architecture/issues/453
<mlagally> https://github.com/w3c/wot-architecture/issues/454
Sebastian: another TDT related topic is
whether we have relationships between TDTs, e.g. components,
inheritance, etc.
... what if we want to override something in an instance?
... do we want to do this?
... is this desirable?
McCool: I would like to see this, and support it with a link and a specific relation type
Lagally: not just for TDTs, but motivates
link relation types in general
... so maybe we pool those requirements together when we talk about
relation types
... for example, component relationships include TDTs but also
other concepts
Sebastian: what do we want on the
end?
... considering the TDT context... when we exchange it with
someone, should it be self-contained
... or do we have a feature where we have links to refer to other
documents that then have to be fetched?
McCool: I think we should realize that
links to well-known concepts don't necessarily have to be
fetched
... and other standards use links much more extensively; it avoids
redundancy
<mjk> @mccool yes
Kaz: links would be useful in many applications, eg. automotive, CE devices
Ben: requiring the client to resolve relationships is a problem; consider the situation of HTML templates
Sebastian: I do think TDTs need to be
self-contained
... then don't need inheritance etc. in my opinion
Lagally: problem on this slide;
"overwrites the name" is a problem described in requirements
document; needs to be a way to manage name scopes, etc.
... need to look into namespaces, etc.
... second, think it is premature to make design decisions without
understanding requirements
McCool: first, we may still want to know
what TDT a TD is and instance of even if we don't fetch it
... second, if we use semantic annotations the namespace issue
already has a solution; but that is an implementation choice we
should look at later
Kaz: we should see actual need from the vendors and service providers based on concrete use cases
... there is a possibility we could live with some preprocessing mechanism which provides resulted self-contained TD to the clients for this purpose (=referencing outside TDTs)
Sebastian: we still need a lot more
discussion, use cases, and motivation
... on slides, did make a proposal for next steps
... but based on the discussion, maybe have to reconsider; but this
slide does point to various issues
... we definitely do need a formal definition
... and we still need to keep the complexity at an appropriate
level
... ml has proposed that ml and seb collaborate on a proposed
definition, then bring back to group to discuss
Lagally: sounds like a plan. Let's do
it
... stakeholders who are interested, please take a look at what we
already have and please bring up additional use cases and
requirements
Sebastian: (put link here...)
... base term is currently used to define the base URI for
affordances
... but may need more information, for example, default
contentTypes, subprotocols, protocol settings shared by all
interactions, etc
<kaz> Issue 878
Sebastian: this would be useful to avoid
redundancy
... (links to issues 878 and 803)
<kaz> Issue 803
McCool: is this specifically a TDT issue?
Sebastian: for a class of devices, want to say that this class of devices uses coap
<kaz> Sebastian's comment on Issue 803
<kaz> [[
<kaz> In the past, we had a base that could be used as an array for multiple protocols. However, this was criticized because of the arithmetic that you have to take care of (as TD designers and implementations).
<kaz> ]]
<kaz> https://github.com/w3c/wot-thing-description/issues/803#issuecomment-532986494
Sebastian: but we need a way to identify a
protocol but not a full URL
... suggest that we use URL patterns/templates to do that
<zkis> https://url.spec.whatwg.org/
Kaz: mentioning TDT here (=Improves the design of TDTs) is a bit confusing though there is a possibility TDT could be a solution
... it's not specifically related to TDTs, but is a general issue for TDs
... so maybe should change the title of this bullet point from "Improve the design of TDTs" to something generic based on the issue 803 itself
McCool: I see the issue of identifing a protocol without a URI is TDT-specific; but other things are TD improvements
Ben: interesting since still chair of
subprotocol websocket CG
... current design is that we use use a link, and would be a
subprotocol member of that link
... but what if a web thing has multiple protocols or
subprotocal
McCool: maybe we could reuse the "definitions" structure used for security
<inserted> scribenick: mjk
Ben: the wss scheme has a single URI
<inserted> scribenick: McCool
McCool: although we need to simplify it for the common case
Ege: using links like bf describes would useful; common case is only one
Sebastian: slides have some examples based
on github discussion
... would expand base with an object
... in addition to an href, would have other information for the
protocol binding
Ben: example on the left, however, is
not how Mozilla's approach works
... instead we provide a top-level link
Lagally: where are we going to spec this, how do we test?
Sebastian: not decided yet; subprotocols
still a large list, many in the market
... sse, webthings protocol, etc
<benfrancis> Correct example of link to WebSocket endpoint in Mozilla implementation (see wss:// URI) https://iot.mozilla.org/wot/#example-6-example-links-member
Lagally: could define various payload formats for a single protocol, so we may not want an exclusive list, just some examples, informative, leave it open
<Zakim> dape, you wanted to breaking change of base, maybe use other term
Daniel: need to be careful about
changing meaning of base term; may result in breaking changes
... better to define a new term
Koster: just naming a subprotocol may not be sufficient; we have to describe in some detail how it is used
Ben: webthings is defined explicitly for web of things, though
Ege: relation type "alternate" used in example; rel may not be appropriate here
<mjk> @ege agree
Ege: what is in base is what ALL forms should use
Ben: don't think "rel" makes sense in the base... would put it in a "link" instead, if using websocket alternative
Sebastian: a related topic, should base be
both a string and as an array?
... might be a breaking change (?)
... can introduce same feature as for @context
... may also want objects, as in previous example (to include
protocols settings, etc)
... propose that object should follow the Form class
Zoltan: is getting very complex
... what is the benefit we are after?
Sebastian: as discussed in the beginning,
have all protocol settings in a single place
... of course we currently do it per-form, but it gets
redundant
Ege: and actually, in mqtt, not
actually very clear
... current system implies we open a socket to the broker for each
interaction
<mjk> establish a persistent connection
Ege: but actually we want to open a
connection to the broker first, and leave it open...
... also applies to websocket connections
<mjk> don't we have a discussion point scheduled later for this topic?
<Ege> https://github.com/w3c/wot-binding-templates/issues/14
McCool: time check
Ege: in case of mqtt of node-wot, I
need to configure, out of band, the URI of the broker
... it's not in the TD...
<Zakim> dape, you wanted to extending base to array causes issues in deployed applications
Daniel: proposal does not consider existing implementation; proposal may be a breaking change
Lagally: how many TDs would benefit from
this feature?
... how is appropriate base being selected if there is more than
one?
... which base would be used for which context?
Sebastian: need to explain in more
detail
... would use multiple bases when there are multiple endpoints
<kaz> scribenick: kaz
Kaz: we should clarify our actual
need for this capability
... maybe we want to have a sub-manager which bundles multiple
things for a mashed-up service
... but we should clarify that to continue the discussion
Sebastian: would like to continue the
discussion
... also we should discuss the remaining topics
... e.g., efficient formats by Taki and Daniel
McCool: let's quickly skim the
agenda
... joint calls
... me and David Ezell working on Conexxus/EdgeX topic
... Koster, can still do the topic on CHIP/ODM?
Koster: yes
... mind if move to earlier?
Sebastian: what about swapping with eCl@ss topic?
Koster: that would be fine
McCool: should create my slides
... the agenda looks OK to me
Sebastian: ok
... thanks for joining, all!
[Day 2 adjourned]
scribenick: kaz
Sebastian: Manu from the DID WG
... CHIP updates
... SOFIE, an EU funded project - Dmitrij Lagutin
... also looking forward a joint project Conexxus/EdgeX
... and update on eCl@ss
... we're using IRC for the discussion
... will share the URL for that on WebEx
McCool: the minutes will be publicly published
... also be aware of the W3C Patent Policy as put on the agenda wiki
Preliminaries for the agenda (including the resources on the W3C Patent Policy)
DID: Kaz
CHIP/ODM: David
SOFIE/eCl@ss: Ege
Conexxus/EdgeX: Sebastian
Testing: Sebastian
Manu: thanks for inviting
... would like to highlight IoT and WoT
... as the most important use case for DID
... really excited to be here :)
... background of me
... DID, VC and JSON-LD
... Anatomy of a VC
... (analogy with a driver's license)
... digital credential from authorities
... government, large companies, insurance companies,
etc.
... cryptographycally protected identity
... e.g., some state agency asking you to show your driver
license
... number of different attributes on the license
... Which identifiers to we use today?
... in our physical world
... email as well
... phone number, URL, social media, ...
... social security card
... never intended to be used for usual purposes
... Why is this a problem?
... we don't know if it's intended subject, owner, etc.
... possibly got from some black markets
... list of security breach on the right side
... What is missing?
... DID work is based on people are the owners of the personal
information
... protected by cryptography
... data portability is important
... Decentralized Identifiers
... new type of URL
... globally unique, highly available, cryptographically verifiable, with no
required central authority
... you can have a central authority, though
... What does a DID look like?
... did:example:13456789abcdefghijk
... Scheme:DID-Method:DID-Method-Specific-String
... DID Method is how to use the DID
... e.g., v1 is a DID Method
... pretty simple looking identifier
... Web of Things and DIDs
... a number of entities for WoT/IoT ecosystem
... to identify themselves
... you could have DID on the manufacture side
... who the manufacture is
... also IoT Gateway can identify themselves
... legal controller also can control the legal structure by
seeing if drone is permitted or who is using it
... WoT service providers also can identify themselves
... in a cryptographic way
... cryptographically signed
... very broad possibilities
... DIDs Resolve to DID Documents
... when you get a URL on a browser
... the domain name is resolved
... DID is also resolved like that
... resulting a DID document
... IoT device says "this is my DID"
... authenticate it
... there is some kind of CoAP message
... can be published through the DID document
... there are 2 things
... DID document contains public keys
... cryptography intereact with DID
... and higher level protocol communicate with each other
... We use DIDs in Verifiable Credentials
... VC statement also uses DID
... sensor with a DID sends sensor value
... idea here is that we would use TD for that purpose
... you can also identify manufactures
... checksum for the latest firmware, etc.
... Web Identifiers Today
... DID WG is not doing the entire DNS
... DID should not be views as a DNS system
... rather something in addition to DNS
... Decentralized Identifiers
... we use a lot of public/private cryptography
... translate the key into your ID
... one of the interesting ways
... companies/people sometimes would like to control it
... people talk about blockchanes frequently
... but that is not the only one
... one possible framework
... DIDs v1.0
... heavy implementations/modifications
... Decentralized Identifiers Status
... a log of implementations
... weekly CG participants: 15-28 form 345
... spec/issue contributors: 32
... Other WoT - DID Related Specs
... Verifiable Credentials
... Encrypted Data Vaults
... LInked Data Proofs
... Authorization Capabilities
... HTTP Message Signatures
... encrypted data vaults is protected data in transit and at
rest
... Linked Data Proofs is mathematical proof mechanism
... not digital signature but equally interesting when you use
IoT systems
... Authorization Capabilities is cryptographic authorization
and delegation to protected services
... very specific data stream or services
... don't want to encrypt
... we can spend the rest of the time to talk about the
collaboration between DID and WoT
McCool: tx for your
presentation!
... we've been talking about proofs
... refer to public keys
... TD can be messed up
... and
... the other topic is discovery
... what is the bootstrap approach?
... we don't have authorized repository for TD
... we're also talking about template for TD
... the other thing is HTTPS just work with external
network
... issue with isolated networks
... not with internet connection
... and
Manu: digital signature
... can express as JSON-LD
... linked data proofs is a generalized approach
... always conflicts there
... there are 3 different kinds of digital signature
approaches
... JWT (JSON Web Token), CWT (CBOR Web Token), ...
... because you have some level of JSON-LD support already
... so linked data proofs approach might make sense
... further resources within the best practices document and
use cases document
... the way that the DID/VC work is additive things
... there are perfectly good reasons for the existing
mechanisms
... you could use URLs to identify resources for VC, etc.
... you can use the best part of the existing mechanisms
... the most important DID method for the IoT/WoT community is did:key
... translating into the DID Documents
... you can drive anything else
... you can handle it without internet connection
... using purely did:key
... one of the best level of operations
<Zakim> dape, you wanted to can a DID document change over time? Is there a way to know whether a DID document changed? Lifetime in general...
Daniel: life time of DID
documents?
... you can be sure did:key can't change?
Manu: benefit of did:key is
directly identify the document
... downside is can't change it
... if you need to rotate keys, you need to use a different DID
document
... you can do that with bitcoin, etc.
... did:key expected to be short live
... with other DID documents might last for human lifetime
Daniel: tx
Sebastian: DID is globally unique
... possible issue from privacy viewpoint?
... can be used to identify the user
Manu: absolutely
Sebastian: JSON-LD context file?
... cool if it could rely on TD
Manu: the privacy question
first
... always constant interest in tracking concerns
... active area for discussion
... there is a massive privacy consideration section within the
spec
... if this is not a gasmeter that's taking measurement, that's
ok
... but if the devices is somebody's watch
... probably problematic
... tend to depend on use cases
... cookies and tracking mechanisms also to be considered
... possibly really scary surveillance system
... DID document can be expressed as JSON-LD
... but some discussion the other day and now pure JSON
... VC is JSON-LD
... if you use pure JSON-LD, that's totally fine
... but if combination of JSON and JSON-LD, would be
difficult
... some conversion required
... we could have a good story
Lagally: do you have typical use cases?
Manu: there is a use case document
Lagally: any mechanism for DID document revocation?
Manu: if you're not connected with
the internet at all, possibly purely gossip-based
... purely localized hash table is possible
... some are OK with localized one
... or at some point, make connection with the Internet for key
rotation
<manu> Here's use cases document for DIDs: https://w3c.github.io/did-use-cases/
Koster: where the DID methods come from?
<manu> DID Method registry: https://w3c-ccg.github.io/did-method-registry/
Manu: DID method registry
above
... first come, first serve
Koster: like the IANA registry?
Manu: right
Kaz: interest in the evergreen registry approach?
Manu: definitely
McCool: will move on
... try to reach out you again
Manu: we'd love to that
<dezell> scribenick: dezell
<mjk> https://github.com/one-data-model
<mjk> https://www.connectedhomeip.com/
Koster: we're using One Data Model,
with iotschema
... One Data Model is attempting to harmonize the semantic side
of IoT models
... Originally lots of participation from the connected home
group.
... current work is on a common language for IoT semantics,
useful to domain experts.
... goal is to converge semantic definitions for common device
types
... things, objects, actions, properties, events, and
data.
... some items (like object) aid in composition of other
things
... ended up with "simple definition format."
... Status: language and metamodel repository is started,
translation of some legacy models is underway.
... BT SIG is important (BLE Mesh Sensor)
... driving toward standardization of the language with other
groups (IETF, for instance)
... schema.org - IoT extensions, trying to blend in RDF
semantic descriptions
... Information Meta-Model - uses "properties, actions, events"
as the central precepts.
... we've integrated iotschema definitions with TDs, strawman
definitions, investigation in discovery.
... use has begun for semantic annotation.
... CG - Schema Extensions for IoT has begun
... currently working on Hands-on evaluation.
... Project CHIP (Zigbee Alliance) - major smart-home platform
companies.
... effort to take existing technologies and integrate
... expect to have a converged ecosystem for IoT (for connected
homes) by the end of the year (2020).
Sebastian: regarding CHIP, I
think we need to pay more attention. How can W3C be more
engaged in collaboration?
... maybe joint plug-fests?
Koster: if we (W3C) don't contribute
code it will be hard to gain traction in the initial
phases.
... what we want to do is attract the >interest< of the
companies involved in CHIP and get them to come to our
plug-fests.
... I've actively been looking for "entry points" - as a board
member of Zigbee and CHIP I'll work for that.
<McCool> mccool: although using plugfest to build interest may not work out with the travel issues right now... virtual plugfests using VPNs?
Kaz: does this kind of web meeting appeal to your members?
Koster: higher priority activities are eclipsing the ability to do lots of different kinds of outreach, but after the initial work this situation may relax.
Sebastian: Siemens is also a member, and we're interested in seeing things move forward.
Taki: are there websites that could help in understanding and learning?
Koster: I'll revise the presentation to include references.
<kaz> scribenick: Ege
Dmitrij: (introduces SOFIE european
project)
... it has 4 pilots to show how the project is
implemented
... uses TDs to describe IoT devices and also DIDs
... (a use case for a guest trying to use the printer of a
university)
... the printer is a legacy device
... the university gives access token and the user uses this to
print the documents he wants, by passing through the Auth.
Server
... Auth server does not know the user but trusts the auth.
given by the university
... client receives credentials, gets access token and then
contacts the resource server (printer in this case) to obtain
the resource
... (another use case with an IoT hub, one side connected to
the owner and possible users/guests, one side multiple gateways
from different manufacturers)
... DIDs can be used between the hub and the user/guest
... then can use the the authorization to interact with the
devices
... we also have evaluated on RPis and key pair and signature
gneration take 126ms on the first gen. of RPi
... links to our projects are available ->
sofie-iot.eu
... questions?
McCool: short question: are you using the DID key method?
Dmitrij: yes
McCool: about oauth2: we removed it
but want to put it back in
... we would like to engage you in the discussion as a use
case
... would you be willing to join a security call
Dmitrij: sure
Sebastian: do you have a WoT runtime?
Dmitrij: no we have our own runtime to
send the appopriate requests
... but we don't develop the devices, the goal is to not touch
them
<kaz> scribenick: sebastian
showing slide presentation about EdgeX / Conexxus Retail PoC
McCool: outline: goals, about
EdgeX Foundry, Intel's ORI, PoC
... showing use case about retail modernization via AI /
IoT
... there are many sub-use cases there
... e.g., Edge computing and AI
... about EdgeX foundry: open source project, provides a micro
service sofrware framework
... there are dozen micro services in multiple languages (Go,
C, ...)
... EdgeX is quite similar to Mozilla Hub
... it has rule engines
... showing the EdgeX Architecture
... showing an example how the rule engine works
... simiar to Mozilla WebThing structure
... the layers of EdgeX constitue a dual transfromation
engine
... about the open retail initiative
... promote open source collaboration at the edge
... participating in the EdgeX WG "Commerce Project"
... there is a meeting in October
... today there is a silo situation in retail
... ORI goal is to consolidate and enable integration
... MC showing a computer vision use case
... and data fusion use case
... summary of EdgeX
... sevice API have OpenAPI definition
... JSON and CBOR is used
... can be simple integrated in Thing Description
... MC further investigating on this
... proposed WoT / EdgeX Integration
... generate TDs metadata for all devie services
... and for select analytics services
... need a prototype a Thin directory service supporting
semantic search
... genearte template for a 'orchestration service'
... define retail use case that integrates IoT and
analytics
... MC shows a PoC definition
... setup demo based on node-red with EdgeX usage
... also show how to write rules
... what is the timeline
... March: def. and planning
... April: first prototype
... July: release candidate
... Sept: demo finaliziation
... Oct: Show @NACS 2020 and @TPAC 2020
questions?
Christian: you showed ZeroMQ
... there must be some extension in the TD, why is that?
McCool: Is not sure yet. EdgeX uses ZeroMQ
Christian: have some experiences with ZeroMQ and there was no need of TD extensions
McCool: should have a joint discussion about this
David: thanks to MC for the presentation
Toumura: if there are some functions needed for node-red, please let me know
<kaz> scribenick: Ege
<kaz> Slides
Sebastian: I want to give a summary on
the collaboration that was going on with eCl@ss
... it classifies devices, it is used heavily in industrial environments
... here is an example of an electrical screwdriver, with the
hiearchy on the left
... it supports many languages (21 at the moment)
... goal is to enable implementers to use eCl@ss knowledge in
the TD
... eCl@ss exists since 20 years
... we want to represent the eCl@ss in RDF
... after having the context file for eCl@ss, we can add
annotations to the TD that uses eCl@ss
... two weekly calls, you can join.
... We had the first F2F in Feb 2020
... We want to test it WoT plugfests as well
Ege: why integrating into TD?
scribenick: McCool
McCool: how do we
combine descriptions in TD with eCl@ss semantics?
... eg for a dashboard display
scribenick: Ege
Sebastian: The representation of eCl@ss is not standardized, this way we can use the eCl@ss information in a more interoperable way
(missed mccool's question)
Taki: in which form are you
planning to publish the vocabulary
... and is there any public information?
Sebastian: not sure, I have to look into
the page of eCl@ss
... I know that they have press releases and some members of
eCl@ss in the Munich Workshop
... definitions of eCl@ss is public already
<sebastian> https://www.eclasscontent.com/index.php?id=21050804&action=det&searchtxt=&options=&version=11.0&language=en
Sebastian: not sure how the vocabulary is published
Kaz: Don't companies use their own vocabularies? How to integrate them
scribenick: McCool
Kaz: how do we apply this to different domains, e.g., automotives, trains and airplanes?
scribenick: Ege
Sebastian: in TD we can integrate multiple vocabularies
scribenick: McCool
Koster: vss schemas - automotive industry example
scribenick: Ege
Sebastian: so we can integrate the vocabulary used in the automative industry into any TD
scribenick: McCool
Koster: VSSschema, BRICKschema are some domain specific ontologies
scribenick: kaz
Kaz: still not sure about the relationship among (1) eCl@ss-based categorization tree, (2) schemas/ontologies (for automotive, etc.) and (3) TDs, and wondring how to put them together. However, we could continue further discussion during our future calls
scribenick: McCool
Ege: for plc example, have a motion controller... what if it is more generic
... in the base you'd describe the PLC, but what if it is connected to a thermocouple
... how do we describe things that in WoT are one thing and in eCl@ss are multiple things
Sebastian: depends on how you want to offer the td
... do you want to represent the sensor or the controller?
Ege: what if I want to do both? might want to know plc cycle time AND temperature?
Sebastian: would use a container mechanism; is a good question, will have to think about
... but it does depend on the use case
scribenick: kaz
McCool: would suggest we have our main call and test call on March 25 as usual to talk about the topics on Planning and Testing (which we couldn't discuss today)
Sebastian: what about the TD call?
... ok to skip the call on 20th?
Taki: fine
Daniel: ok
McCool: and start regular calls on Monday, 23rd
Kaz: do you mean starting with scripting, security and discovery on March 23rd?
McCool: right
... also we should have discussion on liaisons during the Chairs call on Wednesday, March 25th
Sebastian: (mentions the topics for tomorrow)
Architecture (3am PDT / 6am EDT / 11am CET / noon EET / 7pm JST; 1h)
node-wot tutorial (4am PDT / 7am EDT / noon CET / 1pm EET / 8pm JST; 1-2h)
Marketing call: (7am PDT / 10am EDT / 3pm CET / 4pm EET / 11pm JST; 1-2h)
McCool: note there is one-hour gap between node-wot tutorial and marketing discussion
[Wednesday call adjourned]
scribenick: kaz
Sebastian: Agenda for today
... Note on the W3C Patent Policy for guests
<kaz> Architecture: Taki
<kaz> node-wot tutorial: Kaz, Zoltan
<taki> scribeNick: taki
Lagally: I cannot join marketing
call today.
... I already made all inputs.
... I would like to wrap up Arch discussion today.
... We discussed use cases for templates and geolocation,
etc.
... There is a document that is a working draft such as device
lifecycle comparisons.
... also there is lifecycle diagram.
<mlagally> https://github.com/w3c/wot-architecture/blob/master/proposals/Device-lifecycle-comparisons.pdf
McCool: there is also lifecycle content from Oliver wrt OPC-UA etc.
Lagally: can you provide URL?
<McCool> also pres by Oliver Pfaff is relevant to lifecycle discussion:https://github.com/w3c/wot-security/blob/master/presentations/2020-03-16-Bootstrapping%20IoT%20Security%20-%20The%20IETF%20Anima%20and%20OPC-UA%20Recipes.pdf
Lagally: We would like to discuss
WoT profile.
... after that, roadmap and action items.
Lagally: We can discuss 30
minutes maximum.
... Motivation is WoT adoption. Some companies had concern
about interoperability.
... We have interoperability using limited features in
PlugFests.
... across different companies.
... so we would like to formalize the agreements.
... wrt. properties, actions, events, links and security.
... Profile will select meaningful WoT core profiles.
<McCool> McCool: good point that we need to define minimum security support, too...
Sebastian: I have a question about diagram. Do we select a subset of properties, actions, events?
Lagally: Subset means adding
additional constraints.
... resursive levels, for example.
... for interactions, we need to these additional constraints.
Subset means you cannot use this and that.
... you cannot use 6000 characters name for example.
Sebastian: It is about data model, it sounds like. It is more about data model issue.
Lagally: Data model is important.
<McCool> McCool: I think sebastian's comment is just about the figure, might want to change the top-level categories to something like interactions, names, data models, links, and security
<McCool> ... for example
Lagally: It is filling gap for
device developers.
... so they understand how/what to implement properties, events
better.
... Meaningful constraints on data model is important.
McCool: Different categories. Costraints on names, properties, etc.
<kaz> profile definition within the charter
Kaz: I suggest to remove this diagram itself from this slide for now. We should go back to charter first to discuss.
Lagally: I would not remove this diagram, but we should discuss, I agree.
McCool: Charter says "subset",
but it does not say how.
... diagram is about what we need to think about when we
subset.
Lagally: we have 5 building blocks in specs now.
<McCool> McCool: suggest replacing this diagram with a simple list of the things we need to subset; may be more than five
<McCool> ... this will map to sections in the profile spec, most likely
Lagally: This figure is just
illustrative of what we need to discuss.
... Goals. I am concerned about out-of-the box
interoperability.
... between devices.
... including onboarding. This is important.
McCool: Self-documenting TD should not be part of the list. It can be discussed as part of TD discussion.
Lagally: We need to discuss that, too.
<McCool> McCool: for now just mark as "needs discussion"
<inserted> (Kaz agrees with McCool and thinks the 4th point "self-documenting TD" should be discussed but separately from this discussion on profiles today.)
Sebastian: Out-of-the-box
interoperability is valid for TD template. TD template is
missing protocol binding and security. But it has other
metadata.
... So it enables simulation. It needs to be out-of-the-box
processable for templates.
Lagally: Templates have not been used in PlugFests. But I agree TDT needs to be useful itself.
McCool: TDT, we need to define use cases for out-of-the-box TDT.
Lagally: This list is about published spec.
<McCool> McCool: so I suggest we table the TDT discussion for now, and return to it once we have a complete definition of the various (and multiple...) use cases for them
Kaz: I agree with McCool. This slide is about goals. Some are related points. For example, self-documenting TDs can be discussed somewhere else, I think.
Lagally: OK. self-documenting TDs. Some people suggested this point before.
<Zakim> dape, you wanted to interoperability *highly* depends on domain
Daniel: We need to make sure we
are not to define a "single" profile.
... There can be profiles for domains.
... I expect there are domains each has different
requirements.
Lagally: Is it protocol domains?
Daniel: Even within protocols, I expect different need for profiles.
Lagally: We can discuss meaningful constraints. There are common practices. Implementation details are different.
McCool: Human-readability is a
use case. We can discuss use cases.
... Some say we should have one profile. We can discuss union
of all domain requirements.
... One can make further subset later, also.
... we should have a single loose profile that describes what a
consumer needs to support to cover all domains first.
Lagally: We can go that details
later.
... Next, conformance tesing.
... With profile, simplified device validator and compliance
testing can be defined.
... Device can be certified.
... Also, validation tool. We have Ege's playground for
now.
... Next, Implementation complexity.
<McCool> McCool: by "loose" I mean "generous", i.e. fairly large limits on things, assuming a relatively powerful consumer
Lagally: 65,000 characters on string, for example.
Sebastian: We can be more precise here. I agree with your aspects of Consumers. I also want to stress on Producer aspects. Producer needs to describe its protocols, etc.
<McCool> McCool: diff between producer and consumer, +1
<McCool> ... limits are mostly relevant to the consumer, since the producer can state limits on what it can accept in the TD already
Lagally: Consumer's problem is
also producer's problem.
... You cannot sell products, for example.
Sebastian: You need to think about future, as well. There are multiple usages.
McCool: Consumers are in general powerful. But we can list protocols that consumers can use.
Lagally: POST or PUT for updating property, we need to make clear.
Sebastian: It is clear in TD spec.
McCool: TD is open-ended now, it may be problem for consumers.
Lagally: 4 use cases so far.
... high level use cases.
... Consumer needs to know if a device can work in the consumer's place before buying.
<McCool> McCool: needs vs wants; we NEED to make things finitely implementable; we WANT to limit complexity
<McCool> ... maybe should use
<McCool> ... "need" in certain use cases, "want" in others...
<McCool> ... an example; slide actually says "want"
Lagally: developer wants TDs to
be as simple as simple so development work is efficient.
... As a developer, I want to validate whether a device is
compatible with a consumer.
... as a service provider, integration of devices from many
vendors using TDT.
Zoltan: certification process.
How are we going to make it for WoT interoperability?
... What's our position on certification?
Lagally: It should be discussed with wider group(s).
McCool: we can discuss ourselves first on how. On the other hand, we need to discuss W3C, etc.
Ege: Isn't W3C against conformance testing?
McCool: We can start with which
implementation implements which features, and posting
results.
... legal limitation, we need to discuss with W3C.
... ...
<McCool> McCool: profiles should at least make it possible to have conformance testing for interoperability
Kaz: We should clarify our purpose here.
... As you remember, we invited several people working on testing to our F2F during TPAC 2018 in Lyon.
... We might want to provide a framework for WoT testing purposes publicly like the Web Platform Tests repo
Kaz: We need to discuss our requirements first.
Lagally: We started to clarify
requirements.
... We need to continue this discussion in Arch calls.
<McCool> McCool: ... and use cases, and stakeholders...
Lagally shows profile requirements...
Lagally: We need to work further
on this requirements. Please read them first.
... Recap of status.
... We have a GitHub repo. Issues are already there. Strawman
proposal is available.
... Next step, consolidate requirements, review strawman,
implement issues.
... questions?
McCool: We can list specs, how peofiles may impact.
Sebastian: I want to clarify further what profiles are.
<McCool> McCool: suggest we deal with this when we build overall use cases; each should identify deliverables they impact... including profiles (but also discovery, TDs, security, etc)
Sebastian: We need to be clear on intention of profile.
Lagally: We discuss them in architecture call. I agree with the point.
Lagally is showing architecture process diagram.
Lagally: Use cases leads to gaps
and building blocks, which makes requirements.
... There is draft roadmaps.
... Use case in march. Shortlist in April with requirements. We
have document drafted in May.
... We discuss profile strawman in March. Gather use cases and
issues. In May we want to have FPWD.
... This is rough schedule, though it is ambitious.
... We have new issues in architecture repo.
<inserted> virtual+F2F Issues on use cases created during the Virtual F2F
Lagally: We created them during
this Virtual F2F.
... Please check the list.
Lagally is iterating Use case assignments...
<inserted> Issue 456
Lagally: Ege, are you OK?
Ege: It is more about descrbing sensor accuracy property in general. Not limited to geolocation.
Lagally: OK.
... DID stakeholder terminology.
Sebastian: McCool or Oliver?
McCool: I can take a look at it as an input.
<kaz> Issue 455
McCool: We need alignment there.
Lagally: Can Sebastian check with Oliver on this?
Sebastian: Please keep me in there as a reminder.
Lagally: TDT terminlogy. We need to discuss.
McCool: also use cases for TDT.
Lagally: We have a issue for that.
McCool: We need to capture use cases we discussed.
Lagally showing issue #458...
<kaz> Issue 458
Lagally: OK
Lagally edited #458...
Lagally: We have use cases
documents in GitHub.
... MEIG can help some of them.
... Now we have owners for all of the issues.
... It is important to describe those use cases.
... We need lots of discussion for architecture.
... We have split call morning and evening hours in
Europe.
... any other businesses?
Sebastian: Thank you for all the origanization of Architecture work. It is not an easy work.
<McCool> McCool: I will have to drop for a few minutes to reboot my machine and try to fix my audio
Lagally: Thank you. Talk to you next week!
<kaz> scribenick: kaz
[Before starting this session, Sebastian asks everybody if it's OK to record the session and everybody agreed. So Kaz has started to record the session. We need to confirm how to publish the recorded video.]
<Ege> https://docs.google.com/presentation/d/1svxKEwCVoI_b1uyw_1zDOinkcCazz5Xzb5I4g2dpRUQ/edit?usp=sharing
Ege: starts to share the slides
above
... node-wot as an Eclipse project
... why "node-wot"?
... would like to hide the details of implementation
... what we do?
... how to write device implementation?
... possible without node-wot
... choose a protocol
... HTTP, MQTT, CoAP
... that's a pain
... then choose a library/framework
... e.g., mosquitto, flask
... that's also painful
... then program the backend
... and you need to write a TD
... make sure no mistake for the backend
... again
... programs interact with WoT devices without node-wot
... coose a protocol, library/framework
... then programming
... even more complicated
... parse a TD, program the app logic
... then send correct requests
... be sure no mistakes there
<McCool> McCool: well... or the developer should read, which is a "documentation" use case we should capture, actually
<McCool> ... the implementation may not actually parse the TD, and I think this is reasonable, IF the TD will not change
Ege: hopefully you support the
protocol of all TDs
... then
... with node-wot
... just program the app logic
... could focus on your projects/apps
... what is node-wot?
<McCool> McCool: although... yeah, we might do minimal parsing to find the concrete URLs; may be more relevant to say dev reads the TDT, so maybe "documentation" is a TDT use case
Ege: open-source node.js
library
... under Eclipse THingweb project
Ege: designed for WoT
apps
... highly modular
... features
... protocols: HTTP, CoAP, MATT, Websockets, OPC-UA
... media types: application/json, text/plain, images
... WoT operation supports
... security: basic auth, bearer tokens, API key, PSK
... note that node-wot is not an end-to-end framework
... questions?
(none)
Ege: let's see some action!
... start with simplified concepts
... then go into more advanced uses
... installation
... node.js 10.13.0 or later
... 1. clone the repo
... 2. change into the directory
... 3. install dependencies
... 4. build the source code
... 5. link the packages to enable the wot-servient
command
... all public in npm
... let's use it!
... WoT Scripting API is good document for the API
description
... how to write a Thing implementation
... start with describing the interactions
... first write a TD
... script for that
... describe properties
... like temperature including type, description, observable,
readOnly and unit
... then actions
<McCool> McCool: in example, Celcius should be Celsius
Ege: then events
... e.g., for overheat
... looks like a TD but no form section
... then we have to program
<McCool> McCool: also, "temperature of the room" should be "set-point of the thermostat"
Ege: how to read the temperature
from the internal sensor
... dummy functions here
... getTepmerature, changeTemperature
... thing.setPropertyReadHandler
... thing.setActionHandler
... thing.setActionHandler
... for the events
... setInterval for 5 seconds
... if the curTemp is more than 45 then thing.emitEvent
... at the bottom
... thing.expose
... we didn't have any protocol information so far
... all of that is done within node-wot
<McCool> McCool: although we probably should include protocol information... under discussion
<Ege> https://gist.github.com/egekorkan/ddf2e03f40fb976d9d4b925fbbb9d381
Ege: full code available above
<McCool> McCool: I do want to note that we are missing a step in this tutorial
<McCool> McCool: thanks, kaz; good point for comments
<Zakim> dape, you wanted to client side in Website also
Daniel: if you want the client side, you don't need to use node-wot
McCool: missing one step
... configure the servient
... how to setup security, config file, etc.
... very important documentation needed
Ege: exactly
... would like to show something
... there is a slide for that purpose
McCool: great
Ege: would like to go into
configuration as well
... (shares his editor screen)
... myTemperatureThings.js
... properties, actions and events
... this is proposed as specified
... property handler like this here
... myTemperatureThing.js
... running the code
... would like to explain how it works
<McCool> McCool: example needs to be cleaned up a bit to update SetPoint, not Temperature
Ege: changeTemperature
... connected to the MQTT broker
<McCool> McCool: otherwise it is technically inaccurate; a theromstat has a temperature sensor and then a set point at which it *tries* to control the temperature to meet
<McCool> ... but these are two separate properties, logically
Ege: TemperatureController
... http://localhost:8080/TemperatureController
... the name of the thing at the title field here
... read the temperature value based on the request
... increment/decrement
... also subscribe overheated one
<McCool> McCool: maybe I'm being pedantic but I find not being careful about this in a "controller" a bit jarring
Ege: http://localhost:8080/TemperatureController/events/overheat
... (has trouble with screen share)
McCool: good starting point
... but need improvement
... would like to hear fro the user side
... any opinions?
Zoltan: you can provide some
security-related setting
... installation for node-wot
Ege: (back)
<McCool> McCool: good point, but we have to make sure we also cover and document things not in the Scripting API, for instance, setting up certs for private keys, which (intentionally, for security reasons) is done "outside" the scope of the Scripting API
<Ege_> https://gist.github.com/egekorkan/ddf2e03f40fb976d9d4b925fbbb9d381
Ege: code available above
... how to use wot-servient command?
... WoT object is unknown for node.js
... wot-servient command builds the necessary infrastructure
and creates the WoT object for our scripts to use
<McCool> McCool: not quite sure why we have wot-servient; why don't we just require a package and manage it with npm etc?
Ege: command line interface for
node-wot
... we can specify the information for "servient"
<McCool> McCool: would be nicer to follow normal practice here for node scripts, imo
Ege: staticAddress for the
servient
... sections for protocols: http, coap, mqtt
... then credentials
... specify them within a configuration file
... and then run wot-servient -f conf-file
... get help by wot-servient -h
<McCool> McCool: although I guess we do need to discuss how and when the configuration file is read and the execution scope for node-wot is set up; it seems that is one of the motivations for the current structure
Ege: you can use any browser or
REST client
... as long as they use the expected protocols
... but you can do this easier/faster with node-wot
... and the code would be protocol-independent
McCool: nodeRED also should be included as a possible REST client?
Ege: right
... (shows example again)
... slide 30
... TemperatureThingAddress
<McCool> McCool: in general, we should document node-gen and the use of nodeRED with a similar set of tutorials
Ege: actual interaction by WoT.consume
<McCool> McCool: and these tutorials should point to each other...
Ege: we can create a thing
interact with
... slide 31
... setInterval
... if curTemp is less than 20
... await temperatureThing.invokeAction("increment", 4)
... send a request
... slide 32
... specify what the event does
... temperatureThing.subscribeEvent
... in case of overheat
<Ege_> https://gist.github.com/egekorkan/dfd0f999c22396a997eb10994e11aed6
Ege: display error message on the
console
... how to write code to interact with a Thing above
... would like to share the code again
... myTemperatureThing.js
... WoT.produce here
... WoTHelpers.fetch
... create temperatureThing
... to expose the methods
... (run wot-servient command)
... if specify "-c" option, it invoke the client
... any questions?
Zoltan: from the code, we need to add
cancelRequest, etc.
... to avoid infinite loop
... no way to cancel the request
... possibly some optional value for timeout
... will raise an issue
Ege: any other questions?
Cristiano: node-wot script uses the option to break?
Ege: yes
McCool: because this is node.js
... btw, wondering about typescript
(audio issue)
<McCool> McCool: just wondering about typescript vs node proper
<McCool> ... not mentioned, seems you are just using node
<McCool> ... but is there a way I can use typescript instead?
<McCool> ... not critical to go into detail here, McCool: but would like to understand
<McCool> ... eventually
Ege: coming into how to use
typescript
... not runable by default
... advanced feature for node-wot
... the minimum you should do so far
<McCool> McCool: ok, so there is an option to do it, but you don't have to worry about it if you don't want to
Daniel: right
Ege: let's get more advanced
... how to use as an npm dependency
<McCool> McCool: ok, use as npm dependencies answers one of my earlier questions ;)
Ege: recommend you use npm
dependency for more complex ones
... project code via require statements
... download the required packages from npm
... and run
... npm install @node-wot/core
... npm install @node-wot/binding-coap (optional binding)
... example
... slide 37
... upper part with [[Servient =
require("@node-wot/core").Servient
<McCool> McCool: question: can you also specify the configuration file programmatically?
<McCool> ... as a js object?
Ege: and start the servient
... servient.start().then((WoT) => {
... all the configuration as you wish within the upper
side
... lower part same as before
... slide 38
... client side
... build servient properly
... start it
... and same as before
... slide 39
... advantages
... better version control for node-wot
... installing on more constrained devices
... install only what your project needs
... better compatibility
... self-contained
... possibility to use Typescript and Intellisense
<zkis> scribenick: zkis
Ege: node-wot enables building
bigger apps for WoT
... for instance, WADE, Shadow-Thing, WoT-Testbench, WAM (WoT
Application Manager)
... how to contribute: add new protocol bindings (e.g. MODBUS
over TCP)
... or XMPP
<McCool> McCool: would add under "things to contribute": security schemes
Ege: bugfixes are welcome
Zoltan: should we standardize servient-specific APIs
Ege: the danger is to expose the protocol side of things
McCool: we could add an appendix for node-wot
Cristiano: about Shadow-Thing
<McCool> McCool: would be very helpful imo for adoption to fully document the "reference implementation" (node-wot) in one place
Cristiano: we have a use case about this automatic reverse proxy
Ege: you give a TD as an input, consume it with node-wot or shadow-thing and then expose it (after changing it)
Cristiano: but I can not consume the thing behind a firewall
Ege: the IP address is not visible in the TD until port forwarding is not configured in the firewall - it could be handled in the firewall
Christian: node-wot welcomes new
protocol bindings, but people should prefer existing ones with
the help of a proper TD
... and then send that to wotify
... one should use the base protocols and define a good TD
<McCool> McCool: another example would be OCF, which uses CoAP but with some special header options, security settings, etc
Ege: right, we might have too many bindings that way
Christian: e.g. Fujitsu vs Oracle bindings
Jennifer: 2 quick questions, came
up during a pilot
... would be nice to have a tutorial on how to set it up on
production
McCool: also, how to set up in docker, for production use as well
Jennifer: then, slides are shared?
Ege: yes
<Ege_> https://docs.google.com/presentation/d/1svxKEwCVoI_b1uyw_1zDOinkcCazz5Xzb5I4g2dpRUQ/edit?usp=sharing
Kaz: save the pdf version in the repo
<McCool> McCool: but also how to run as a daemon, using systemd, upstart, pm2, etc.
<McCool> ... also there is also a way to set up a daemon using docker
Jennifer: what is the difference between wot servient and cli.js?
Ege: no difference
... it's like a shortcut
... for pros, suggest using as npm dependency
<McCool> McCool: this is an example of something that is trying to make things easier that ends up just being confusing...
Daniel: the wot-servient command might be indeed confusing with the optional things
<McCool> McCool: and wot-servient is also limited; might be better for some people to just start with the npm approach first
Sebastian: thanks Ege for the presentation
Kaz: suggest updating node-wot documentation based on this presentation
Ege: right, we could even have a tutorials folder with various recipes
<McCool> McCool: I'd like to see a written tutorial, not just a video
<McCool> ... with similar content
<McCool> ... but I also want to say this is very valuable material
Kaz: you can use the minutes as a basis for that documentation refactoring
<Philip> Philip: I have a question on the support for Bearer token
<Philip> Philip: is it fully supported and do we have any example on using Bearer token with WoT?
Ege: yes, it's fully
supported
... in the plugfest, Panasonic used them
<Philip> Philip: it would be helpful to have an example on that
<McCool> McCool: need to add documentation, an example, and a tutorial on how to set up bearer tokens (and other security schemes, once we implement them)
Jennifer: in general, more examples to cover security
Sebastian: adjourning the tutorial
session
... now we will have a break
... will have the marketing session later
Marketing call starts in one hour
[adjourned]
