Agenda

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)

Scribes

DID: Kaz

CHIP/ODM: David

SOFIE/eCl@ss: Ege

Conexxus/EdgeX: Sebastian

Testing: Sebastian

DID

Slides

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

CHIP and ODM (Michael Koster)

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

SOFIE

<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

edgex

<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

eCl@ss

<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

Call plans

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

Tomorrow

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]