<kaz> Agenda: www.w3.org/WoT/IG/wiki/F2F_meeting,_16-19_March_2020,_Online

Scribes

<kaz> scripting: Christian

<kaz> architecture: Daniel

<kaz> security: Kaz

<kaz> Discovery: Zoltan

Agenda

<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

Getting started!

Sebastian: looking forward to the discussion this week :)
... any comments, questions?

(none)

Sebastian: let's start then!

<scribe> scribenick: glomb

Scripting API

<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]

WoT Architecture

scribenick: dape

<inserted> Agenda

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

Security

<kaz> scribenick: kaz

Agenda

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?

Bootstrapping IoT Security

[slides]

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]

Discovery

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

[Vorto link]

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

Requirements document for Discovery

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

two-phase discovery proposal

[2pd link]

<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

DNS based discovery

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

Next day's agenda

<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]