<scribe> scribenick: kaz
Lagally: any objections for approving them?
(no objections)
Lagally: minutes approved
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
Lagally: end-to-end security
... will talk with McCool during the second call today
Lagally: thing authentication
... will talk with McCool about this as well
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
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: 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
Lagally: any objections?
(none)
Lagally: approved
McCool: can volunteer
Lagally: assign McCool to Issue 427
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)
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
Kaz: wondering if Web Authentication could be helpful
McCool: possibly
... but Web Authn is client/server-specific
Koster: WoT model is based on servient
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
McCool: need use cases
Koster: will make comments
Lagally: ok
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
McCool: more media use cases also should come
Lagally: MEIG guys could provide
it
... (merge PR 424)
Lagally: would suggest we review this
a bit more
... and merge it next week
McCool: can give comments
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?
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
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]