W3C home > Mailing lists > Public > public-wot-wg@w3.org > February 2020

[wot-architecture] minutes - 6 February 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 17 Feb 2020 18:03:46 +0900
Message-ID: <874kvpshzh.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/02/06-wot-arch-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                            WoT-Architecture

06 Feb 2020

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda

Attendees

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

   Regrets

   Chair
          Lagally

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]Call1
              1. [5]Review of mintues
              2. [6]Issues
              3. [7]PRs
              4. [8]Lifecycle
         2. [9]Call2
              1. [10]Agenda
              2. [11]Prev minutes
              3. [12]Issues
              4. [13]PRs
              5. [14]Device Lifecycle survey
     * [15]Summary of Action Items
     * [16]Summary of Resolutions
     __________________________________________________________

Call1

   <scribe> scribenick: kaz

Review of mintues

   [17]Jan-23 minutes

     [17] https://www.w3.org/2020/01/23-wot-arch-minutes.html

   Lagally: any objections for approving them?

   (no objections)

   Lagally: minutes approved

Issues

   [18]Issue 432

     [18] https://github.com/w3c/wot-architecture/issues/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

   [19]Issue 430

     [19] https://github.com/w3c/wot-architecture/issues/430

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

   [20]Issue 429

     [20] https://github.com/w3c/wot-architecture/issues/429

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

   [21]Issue 427

     [21] https://github.com/w3c/wot-architecture/issues/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

PRs

   [22]PR 424

     [22] https://github.com/w3c/wot-architecture/pull/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

Lifecycle

   [23]Zoltan's slides

     [23] https://github.com/w3c/wot-architecture/blob/master/proposals/Device-lifecycle-comparisons.pdf

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

Call2

   <scribe> scribenick: kaz

Agenda

   [24]Agenda

     [24] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda

   Lagally: goes through the agenda for today

Prev minutes

   [25]Jan-23 minutes

     [25] https://www.w3.org/2020/01/23-wot-arch-minutes.html

   Lagally: any objections?

   (none)

   Lagally: approved

Issues

   [26]Issue 427

     [26] https://github.com/w3c/wot-architecture/issues/427

   McCool: can volunteer

   Lagally: assign McCool to Issue 427

   [27]Issue 429

     [27] https://github.com/w3c/wot-architecture/issues/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> [28]https://www.lexico.com/en/definition/authentication

     [28] https://www.lexico.com/en/definition/authentication

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

   <zkis>
   [29]https://www.globalknowledge.com/ca-en/resources/resource-li
   brary/articles/the-three-types-of-multi-factor-authentication-m
   fa/

     [29] https://www.globalknowledge.com/ca-en/resources/resource-library/articles/the-three-types-of-multi-factor-authentication-mfa/

   [30]Issue 148 from wot-security

     [30] https://github.com/w3c/wot-security/issues/148

   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

   [31]Web Authentication API

     [31] https://www.w3.org/TR/webauthn/

   Kaz: wondering if Web Authentication could be helpful

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

   Koster: WoT model is based on servient

   [32]WebAuthn guide

     [32] https://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

   [33]Issue 430

     [33] https://github.com/w3c/wot-architecture/issues/430

   McCool: need use cases

   Koster: will make comments

   Lagally: ok

   [34]Issue 432

     [34] https://github.com/w3c/wot-architecture/issues/432

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

PRs

   [35]PRs

     [35] https://github.com/w3c/wot-architecture/pulls

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

   [36]PR 424

     [36] https://github.com/w3c/wot-architecture/pull/424

   McCool: more media use cases also should come

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

   [37]PR 428

     [37] https://github.com/w3c/wot-architecture/pull/428

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

   McCool: can give comments

   [38]PR 431

     [38] https://github.com/w3c/wot-architecture/pull/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

   [39]Zoltan's slides

     [39] https://github.com/w3c/wot-architecture/blob/master/proposals/Device-lifecycle-comparisons.pdf

   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

   [40]DID Core spec (FPWD)

     [40] https://www.w3.org/TR/2020/WD-did-core-20200206/

   [41]DID use cases

     [41] https://www.w3.org/TR/2020/WD-did-use-cases-20200130/

   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?

   (none)

   [Call2 adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


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

     [42] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [43] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 17 February 2020 09:04:47 UTC

This archive was generated by hypermail 2.4.0 : Monday, 17 February 2020 09:04:48 UTC