Call 1

scribenick: kaz

Review minutes

<mlagally> If you have a few mins and want to have fun: https://youtu.be/DYu_bGbZiiQ

Mar-26

Lagally: (goes through the minutes)
... discussion with Chris as well
... any objections to approve the minutes?

(none)

Lagally: approved

Use cases

Lagally: split into 2 pieces
... call 1: agriculture and transportation
... call 2: lifecicle (including Zoltan and Elena) and health monitoring

Pullrequests

475

Lagally: (goes through the changes)

gitio draft

Lagally: 8.2 WoT RUntime
... (go back to the changes within pullrequest 475)
... references to docs
... lifecycle diagram
... comparison
... bootstrapping
... would like to merge this

Elena's diagram

Lagally's diagram on unified device

Lagally: sequence diagrams are useful here
... bootstrap, onboard, activate, offboard, decommission, destroy
... 2nd diagram: bootstrap, register, discover, onboard, activate, use, deactivate, offboard, deregister, decommission, destroy
... don't want to go into the detail
... but just wanted to show the reource for call 2

Terminology

Pullrequest 454

Lagally: proposed term definition from the architecture call last week:

[[

Proposal:

A Thing Description Template (TDT) is a description for a class of Things that have the same capabilities.

It describes the properties, actions, events and common metadata that are shared for an entire group of Things. A TDT does not contain enough information to identify or interact with a Thing instance.

(potentially add the following: Note: A TD is an instance of one or more TDTs.)

]]

Zoltan: scripting-specific

Lagally: we have a couple of proposed teminology definitions

Zoltan: subest of TD?

Lagally: yes
... should have discussion during the TD call as well

Zoltan: TD fragments should be also valid TDs

Lagally: right that's not arbitrary string
... going to write another proposal
... (proposal based on the discussion today, April 2)
... Partial TD = subset of TD that is valid JSON-LD. It uses

Taki: what would be the whole set given a "subset"?
... not sure about the concept of "set" here

Zoltan: a document is a set
... should have discussion during the TD call
... we should keep the use case descriptions here, though

SSML 1.1

Kaz: we might want to look at the definition of "fragment" from XML-based specs like SSML above
... that implies we might want to have some clear schema definition for "TD fragment" as well

Zoltan: there is no concrete definition within the spec text, though

Lagally: how about "subse of a TD data model" which doesn't require all mandatory keywords

Kaz: do you mean "all the mandatory keywords of the TD"?

Lagally: right
... (adds clarification for that)
... and "a partil TD is used as a search pattern for discovery"

Zoltan: maybe we should discuss this during the TD call
... but OK with this for now

Lagally: ok
... (and save the defitnion as a comment

Transportation use case

Pullrequest 470

<mlagally> Zoltan, we cannot hear you

Zoltan: this is just a first draft
... not sure how to split this up
... a lot of concrete use cases are included here
... public transport by bus, flight cargo, etc.

Lagally: this use case does include good points
... what would be the expected data model?

Zoltan: this is just a use case
... needs reviewers to improve it
... help from you all would be helpful

Kaz: we can consider this use case as a meta business-oriented use case which inspire us to generate several concrete use cases deribed from this

Lagally: right
... this is a use case on some vertical

Kaz: "vertical" could be a possible term for this purpose :)

Lagally: (adds comments on the discussion so far to the pullrequest)

Zoltan: would like to get a second round for this

Lagally: cargo is ship, airroad, rail and last mile
... stakeholders are very different companies, however, hared identifiers for packages, source and target location are desirable
... shipping options like dangerous goods, priority

Zoltan: would somebody to review this use case once
... to get better understanding for this
... can mention that within the pullrequest itself

Lagally: ok
... just wanted to capture our points during this call
... assign a reviewer?
... Benjamin for vehicle use case?

Zoltan: sounds good

Lagally: and people on this call?
... Singapore govtech guys are also expected
... (assigns people from the WoT WG to the pullrequest as reviewers)

Kaz: note that we're already at the end of the hour

Lagally: ok
... let's talk about the agriculture use case next week

Taki: would like to make contribution to another use case on healthcare

Lagally: great
... aob?

(none)

Lagally: let's continue the discusion during call 2

call 2 time

[call 1 adjourned]

---

Call 2

scribenick: zkis

Past minutes

Lagally: past minutes presented in call 1, no objections

[past minutes approved]

<kaz> Mar-26 minutes

Lagally: presenting issues discussed during call 1

Lagally: presenting PRs
... added links to https://github.com/w3c/wot-architecture/pull/475

lifecycle discussion

Elena: have done some fixes to the diagram
... there was a discussion of it in the Security call as well
... got input from Oliver, form OPC-UA provisioning angle
... tried to merge OPC-UA lifecycle into the diagram
... Anima focuses on the link between Manufacturing and Operational state
... Anima also defines the Destroyed state
... maintenance state is not really defined well

Lagally: so it is bootstrapping and achieving operational state
... any other stakeholder?

Elena: Anima defines bootstrapping via joint proxy, registrar, and MASA
... Manufactured state has the manufacturer key set
... botstrapping will set Site keys
... also, there are Application keys

Lagally: so it solves the question how to provision the keys during bootstrapping

Elena: it is zero-touch mechanism
... but you have to have some keys on the device

McCool: not all devices have manufacturer keys

Elena: will get there
... for OPC-UA, the picture is similar
... there is no zero-touch provisioning, the device needs connected to a network, credentials provisioned
... different requirements for pre-state

Lagally: is there an OPC-UA device without any keys?

Elena: Manufactured state can lack the keys
... should ask Oliver

Lagally: should we have a security bootstrap state?

Elena: going back to the WoT device lifecycle picture, we have a separate state for Bootstrapped/Onboarded
... which is optional
... it is possible some devices are already in bootstrapped state when leaving manufacturing

McCool: when is the SW installed (behavior)? when application keys are installed?

Elena: will go through the diagram
... some devices might have manufacturer keys, but no service provider key or application keys
... then we transition to Bootstrapped state
... configures the device with identity, keys and certs needed for that
... service provider key is set
... but no application keys at this point
... next, transition to Operational is when app keys are provisioned and configured
... Maintenance state can update the app keys, but not change identity etc

McCool: Anima assumes the device is operational when it has the site keys
... first transition is for service provider bootstrapping, second transition for app bootstrapping

Lagally: so they have a certain model for key management
... what is an app key

Elena: from WoT pov, there is a set of credentials provisioned into the WoT runtime
... this is the application key

Lagally: why ACL?

Elena: the purpose is identification and authentication
... then ACLs can be set up

McCool: we should separate device provisioning from service provisioning

<kaz> regrets2: Koster

Zoltan: setting up ACLs is needed in OCF for instance, otherwise won't be operational

McCool: we could make a note about device vs service provisioning

Lagally: is there a new state when a device is registered with a service?
... tried to do some sequence diagrams and had questions like this

McCool: registering to services is not a state of the device

Zoltan: there are 2 levels of services: protocol native and WoT

Kaz: we need to figure out which state is linked to which device
... most states can be linked to specific devices

McCool: it might be confusing to include all possible states
... we can deal with other systems in operational state
... we need to explain what configuration data we are including

Lagally: that goes to the text, keep it abstract

Kaz: we should think about service layer and device layer separately

Zoltan: operational means the underlying protocol is fully operational, and in addition WoT also works

Lagally: would present own work, then return to the diagram
... presenting sequence diagrams, 2 flows
... one for the security provider, the other for the consumer

[link to diagram]

https://github.com/w3c/wot-architecture/blob/master/proposals/unified%20device%20lifecycle.svg

McCool: simple and clean diagrams, some details to be discussed
... single words should describe states, verbs describe transitions
... some details like discovery need to be checked

Zoltan: there is discovery for bootstrapping and during operational mode

McCool: words like introduction and exploration could tell them apart

Lagally: this diagram is deliberately not detailed

McCool: we can add details as text

Zoltan: what is the diff between Bootstrapped and Onboarded?

Elena: if we forget about security, define the sequence from operational pov, then we can complete security details

Zoltan: isn't the purpose of the lifecycle diagram to provide input to Security?

Elena: it has its meaning even without security

Lagally: I agree. Even if we have a secure environment, this diagram should work

McCool: I like that each state represents a new relationship
... we could start there and look it from the actors point of view
... we should define things from the perspective of relationships

Lagally: we could make a table with state and description and relationship

McCool: depends on what relationships we aim for

Kaz: identify the actors explicitly and a group of states would be useful.
... we could use the colors to idetify them. also possibly assign soe of the states as a meta state linked to oprational state.
... anyway, thinking about the relationship (or mapping) between Michael Lagally's simpler diagram and Elena's detailed diagram would make sense

Lagally: about next steps: will create a table, will update the diagram, Elena can take it from there

Elena: would not like to take it from an empty table; for security need to have the states and relationships, capabilities etc defined
... everything that is not security related

Lagally: OK, let's work on the table first

McCool: in github, preferably, e.g. in an issue

Lagally: created https://github.com/w3c/wot-architecture/issues/476

any other topic?

<mlagally> Just a little bit of fun: https://youtu.be/DYu_bGbZiiQ

AOB?

[call 2 adjourned]