06 Feb 2020



Call1: Kaz_Ashimura, Michael_Lagally, Elena_Reshetova, Zoltan_Kis
Call2: Kaz_Ashimura, Michael_Koster, Michael_Lagally, Michael_McCool, Ege_Korkan, Zoltan_Kis



<scribe> scribenick: kaz

Review of mintues

Jan-23 minutes

Lagally: any objections for approving them?

(no objections)

Lagally: minutes approved


Issue 432

Zoltan: onboarding usually happen on a different network (from the operational one)
... so should think about this separately
... can make a comment to this issue 432 directly

Lagally: ok
... note that we should not create a separate onboardig/offboarding spec, though

Zoltan: we should clarify vocabulary for onboarding/offloading

Lagally: do you mean TD vocabulary?

Zoltan: right

Lagally: (adds a comment to Issue 432 about that)
... we need TD vocabulary to describe onboarding/offboarding mechanisms
... however not specify new onboarding protocols/mechanisms

Zoltan: we should describe why it's important from WoT's viewpoint

Lagally: ok. that should be part of the use case description

Zoltan: there have been similar considerations (by others) for years about onboarding/offboarding

Lagally: we should have actual use case description first
... who would be interested in writing the use case description for this topic?

Zoltan: related to discovery

Lagally: we got decision about the date/time during the WoT call yesterday

Kaz: 4pm CET, 5pm EET, midnight JST on Monday

Issue 430

Lagally: end-to-end security
... will talk with McCool during the second call today

Issue 429

Lagally: thing authentication
... will talk with McCool about this as well

Issue 427

Lagally: need to describe a use case with edge devices containing built in intelligence, preprocessing analytics, etc.
... then we have some more issues for use cases


PR 424

Lagally: McCool has created this
... addressing requirements as well
... audiovisual devices acting as smartphone extensions
... unified smart home control and status interface
... then
... smart car configuration management
... including movable devices with GPS
... then
... interactive public spaces
... and
... meeting room event assistance
... kind of related to dynamic onboarding
... then
... health notifiers
... aggregated data on the smartphone
... possibly front-end for sensor data
... then
... multimodal recognition support
... and
... enhancement of synergistic interactions
... this is an accessibility use case
... would like to go ahead and merge this pullrequest
... two more use cases to be discussed later


Zoltan's slides

Zoltan: OCF, oneM2M, LwM2M, T2TRG
... [OCF]
... how onboarding is handled
... there are 3 stages: onboarding, security provisioning and security configuration
... 1. onboarding, there are multiple types
... the outcome is device identity and owner credentials
... 2. security provisioning
... discovery is a service for this stage
... provision credentials and ACLs
... 3. security configuration
... configure apps and access management
... from OCF point of view, WoT is just an application
... one more step for providing bridging
... for BLE, oneM2M, AllJoyn, UPlus, ZigBee and Z-Wave

Lagally: specific entity?

Zoltan: software running on OCF devices
... WoT runtime is an application from OCF's viewpoint

Lagally: something like bridge?

Zoltan: yes
... [oneM2M]
... kind of complicated
... Generic Bootstrapping Architecture (GBA)
... Trust Enabling Architecture
... M2M Initial Provisioning
... pre-provisioning, remote provisioning and service provisioning
... and then application enrolment
... oneM2M specs is a pretty lengthy document
... [Lightweight M2M]
... 4 bootstrap modes
... factory, smartcard, client initiated, server initiated
... bootstrap discovery is also supported
... not the same as operational discovery
... [T2GRG lifecycle]
... most complete figure here
... lower side: bootstrapping, operational, maintenance & rebootstrapping, operational, maintenance & rebootstrapping
... software update between the first operational and the second operational
... [Possible Mapping to WoT device lifecycle model]
... manufactured, bootstrapping, operational, decommissioned
... 1. Manufactured | factory defaults
... 2. bootstrapping | provisioning with sub-states
... 3. operational | with sub states
... - normal operation
... - reconfiguration by user/provider
... - maintenance / software updates
... 4. decommissioned
... - all data and trust chain removed (=reset to the factory defaults)

Lagally: Elena, do you see any gaps with this proposed mapping?
... (shows Elena's original state transition diagram)

Elena: some of the sub-states may be optional
... wouldn't add any more states but would add description within each state

Zoltan: let's elaborate it during the next call

Elena: probably we have different understandings for each term

Zoltan: let's continue the discussion

Lagally: ok
... note that we should have "Destroyed" as a separate state from "Decommissioned"

Zoltan: we need to split Destroyed from Decommissioned
... let's have discussion offline, Elena

Lagally: and also during the 2nd call as well

[Call1 adjourned]


<scribe> scribenick: kaz



Lagally: goes through the agenda for today

Prev minutes

Jan-23 minutes

Lagally: any objections?


Lagally: approved


Issue 427

McCool: can volunteer

Lagally: assign McCool to Issue 427

Issue 429

Lagally: McCool, do you have some definition already?

McCool: not really
... we need to clearly define the term

Lagally: ok

McCool: thing authentication is used from multiple times
... so should be defined within the WoT Architecture document

Lagally: could be different types of authentication
... depending on use caess
... also relates to onboarding and discovery

Koster: need to clarify the workflow

Lagally: can we start with some simple definition?

McCool: working definition is ok

<zkis> authentication definition: the process or action of verifying the identity of a user or process.

<zkis> https://www.lexico.com/en/definition/authentication

McCool: there was an issue from wot-security (issue 148)

<zkis> https://www.globalknowledge.com/ca-en/resources/resource-library/articles/the-three-types-of-multi-factor-authentication-mfa/

Issue 148 from wot-security

Zoltan: there are multiple views for the definition

McCool: would suggest we talk about the procedure
... maybe would task the Security TF for that
... just create a PR
... work on use cases
... and create a draft section to talk about authentication

Web Authentication API

Kaz: wondering if Web Authentication could be helpful

McCool: possibly
... but Web Authn is client/server-specific

Koster: WoT model is based on servient

WebAuthn guide

Lagally: we could look into WebAuthn as well
... also IETF work
... proposals from the security tf as well

McCool: let's move forward
... would create a pullrequest for some draft
... need to reference existing definitions
... the Security TF should start some initial work
... and then we can repeat iteration

Lagally: sounds good

Issue 430

McCool: need use cases

Koster: will make comments

Lagally: ok

Issue 432

Lagally: need TD vocabulary to describe onboarding/offboarding
... use cases to be described



Lagally: we have several PRs for use case proposals
... would propose merge PR 424

PR 424

McCool: more media use cases also should come

Lagally: MEIG guys could provide it
... (merge PR 424)

PR 428

Lagally: would suggest we review this a bit more
... and merge it next week

McCool: can give comments

PR 431

Lagally: tx for review, Ege

McCool: X-Protocol interworking is a use case for WoT
... interesting discussion to have

Koster: we're trying to standardize the binding procedure

McCool: maybe direct mapping is not feasible
... need to think about emulation as well

Lagally: will take an action to initiate email discussion because there are not enough people today
... next, Zoltan's presentation?

Device Lifecycle survey

Zoltan's slides

Zoltan: [References]
... OCF: OCF onboarding tool spec, OCF security spec
... oneM2M: technical report sercurity, security solutions
... LwM2M: technical specification: Core/Bootstrap
... T2TRG: Security (RFC8576), Thing Lifecycle
... [OCF]
... 3 main stages
... 1. onboarding, 2. security provisioning, 3. security configuration
... at stage1. onboarding: provision device identity and owner credentials
... at stage 2. security provisioning: provision credentials and ACLs to access other devices/services
... at stage 3. security configuration: configure applications and acess management policies
... on an OCF device, WoT servient is an application that acts as a bridge

McCool: there is an onboarding tool

Koster: what device to be used as a hub?

McCool: need to think about other way around
... hub and device separately

Koster: we don't define hub, though

Lagally: we have directory

McCool: multicast within a local network
... devices have to alive to get discovered

Zoltan: let's look at how OCF handles onboarding
... [oneM2M]
... Generic Bootstrapping Architecture (GBA)
... initial provisioning
... - pre-provisioning, remote provisioning and then service provisioning

Koster: enrolement here
... what corresponds to it?
... serial, BLE, etc.

Zoltan: [Lighweight M2M]
... 4 bootstrap modes
... 1. factory, 2. smartcard, 3. client initiated and 4. server initiated
... next [T2TRG lifecycle]
... main state transition and sub state transition

McCool: this is not state transition but sequence

Zoltan: [Possible Mapping to WoT device lifecycle model]
... my idea about possible mappings
... manufactured: factory defaults
... then bootstrapping state
... multiple types there
... sub-states: onboardking/bootstrapping?, service provisioning, app provisioning
... operational: with sub-dates
... normal operation, (re)configuration by user/provider, maintenance/software updates
... decommissioned:
... same state as the factory defaults state

McCool: like "destroyed" here separate from "decommissioned"
... any timeout for operational state?
... also possible separate maintenance state?
... state machine should cover all the possible states

Lagally: note that we don't have to have all the transitions for all the implementations
... onboarded could mean another state

McCool: maybe we could think about sub-state machine under operational?
... maybe we need to reboot the machine to reflect the update

Lagally: we should separate states if they're really different
... have two different labels at the top of the "WoT lifecycle diagram.drawio" diagram

Zoltan: if we look at the lifecycle diagrams from OCF and oneM2M, they're quite complicated

Lagally: we don't want to make people confused

Koster: possible binding with what OCF, etc., actually does
... these are not only device states but system states

McCool: why don't we define system data as well?

Lagally: but that would be a different level of diagram

Zoltan: would keep those points separate
... abstract transition vs detailed transition

Koster: what are the basic transition for an application, etc.

Zoltan: we could have another diagram to describe the detail

Lagally: we need use cases for the discussion
... why don't we keep this current diagram, and then continue the discussion?

Kaz: we can review the DID FPWD as another resource for further use case discussions

McCool: why don't we review it during the next call?

Lagally: several introduction slides?

McCool: can volunteer

DID Core spec (FPWD)

DID use cases

McCool: can look into them

Zoltan: can also generate a PDF version of my slides and put it on the GitHub repo

Lagally: let's continue the discussion on use cases for onboarding/offboarding, etc.
... any other points for today?


[Call2 adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/02/17 09:02:50 $