- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 17 Feb 2020 18:03:46 +0900
- 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