Call 1

<kaz_> scribenick: kaz_

Prev minutes

Jan-16 minutes

Lagally: (goes through the mintues
... any concerns/issues?

(no objections)

Lagally: let's approve the minutes then

Issues/PRs

Issues

Issue 426

Lagally: ened to have discussion on use cases for digital twins
... also some home work items from the main call about future use cases to be presented during the ME joint call on Feb. 4
... we still have one more call before that
... some initial set of use cases would make sense
... some more use cases here
... let's talk about them during the use case session

PR 424

Lagally: McCool has created a PR for MMI use cases

Lifecycle

Lagally: have installed Elena's lifecycle diagram on GitHub repo

Elena: you should also have permission for edit

Lagally: we had discussion on a possible intermediate state between manufactured and bootstrapped

Elena: you can have some identity provisioning
... bootstrapped is related to establishing user's identity, and optional

Lagally: would not make changes directly here
... could be a null operation
... could have a bootstrapped state even if it's possibly empty
... (better to keep the current transition diagram than connecting operational directly from manufactured)
... we probably need some terminology for clarification
... about user configuration

Elena: do you have any idea?

Lagally: not yet

Elena: (shows the security mitigation table)

<elena_> https://rawgit.com/w3c/wot-security/master/index.html#wot-threat-model-assets

Elena: "system user data"

Lagally: those terminologies to be defined

<elena_> https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5

Elena: need to leave
... diagram URL above

Lagally: let me see if I can edit it

Kaz: our Google accounts should be authorized by Elena

Elena: yes, please send me an email

Lagally: ok, let's do that offline
... regarding the terminology
... "system data", "system user data", etc.
... maybe more privacy sensitive data is possible
... like user credentials
... maybe we don't need to introduce new definition (but could reuse the existing definition)
... based on the definition from the Security&Privacy Guidelines document

Elena: there are different types of data

Lagally: we just need to include the definition from the Security&Privacy document

(Elena leaves)

Lagally: let's look at the diagram quickly again
... manufacture state with optional data
... and then bootstrapped state with required data
... probably optional at the bootstrapped state as well
... (adds notes)
... who are the actors? (for the connection between manufactured and bootstrapped)
... need names for all the state transitions, perhavs only an abbreviation and a full legend somewhere else (in general)

Kaz: agree we should clarify the "actor"
... and for that purpose, (as I mentioned last week) probably it would be useful to identify the location/timing, etc., as well
... meaning where and when the actors do what
... at least at this initial stage of discussion

Lagally: (shows his slides on "Actors and Roles")
... yeah, we should clarify actors and roles
... (copies the list of actors and roles from the slides to the lifecycle diagram)
... will fix the font setting for the text later

(Zoltan joins)

Zoltan: I also made some comments
... 2 possible states there
... including configuration
... and destroyed
... those 2 are currently merged as "decommissioned"
... decommissioned means the data is wiped out, not destroyed

Lagally: do you think we need to have an additional state?

Zoltan: we should have "factory default" data for the "Manufactured" state
... also "Decommissioned" should be "Decommissioned/Destroyed"
... from WoT viewpoint, the Actors are not necessary to described here
... we can mention the examples, though

Kaz: note that when we discuss the lifecycle state transition, it would be useful to discuss that based on concrete use cases
... and those use cases should have concrete definition of actors, locations, actions, etc.
... the final diagram doesn't have to include those details, though

Lagally: (adds another note)
... consider creating a matrix table including actors and state transition
... this would illustrate who is permitted doing a state transition

Zoltan: btw, there is a typo at the title
... to be fixed as "WoT lifecycle diagram.drawio"

Lagally: fixed
... possible additional state for "Onborded"?
... "Onboarded/Registered with a Thing Directory"

Zoltan: don't think that needs to be a separate state

Kaz: agree
... onboading is part of (or similar to) the "Bootstrapped" state
... and Thing Directory is one possible method/mechanism for that
... so might make more sense to call the state "Onboarded"

Zoltan: we can keep both the names at the moment

Lagally: (changes the name to "Bootstrapped/Onboarded")
... do we have a Consumer at this state (Bootstrapped/Onboarded)

Kaz: it depends
... so I think we should think about the location as well
... if it's done at a a consumer's home, the consumer is included
... but if not, the consumer may not be included

Zoltan: why don't we add data on "device/consumer relationship has been established?" ?

Lagally: ok
... (also updates the transition from "Bootstrapped/Onboarded" to "Operational")
... provision WoT operational configuration, WoT security configuration, register deive wit hconsumers and/or directories, provision a device with a service
... btw, we're out of time
... let's continue the discussion during the next call
... Zoltan, can you talk about OCF and oneM2M?

Zoltan: can present OCF

Lagally: ok

Zoltan: can do that next week
... but maybe Michael Koster can also do that during Call 2

Lagally: ok
... AOB?

(none)

Lagally: the updated diagram has been save
... if you have any additional comments, please use another color (than yellow)

[Call 1 adjourned]

Call 2

<McCool> scribenick: mccool

Previous minutes

<mlagally> Minutes of last week's call are approved: https://www.w3.org/2020/01/16-wot-arch-minutes.html

Notes from first hour's meeting

Lagally: talking about lifecycle diagram
... added a number of things to the lifecycle diagram
... did not go further into use cases
... would like to ask Koster to talk about lifecycle in OCF

Koster: ok, we can do that

Lagally: did go through issues and marked use cases
... and added a few new issues for use cases
... did create a PR for a Digital Twin use case
... one issue is that the current lifecycle is just for the device
... for instance, onboarding/offboarding are not clear
... are these the same or separate from bootstrapping?
... fan of sequence diagrams, I think that would make things clearer
... identify these additional system states

Review issues

Lagally: several new issues and tags for use cases
... for PRs, we need some more use cases to be submitted
... need volunteers to actually put together some use cases

PRs

Lagally: just use cases, will defer discussion to use case discussion

Proposed REC publication

Lagally: diff shows some changes, we should review
... mostly typo fixes, and HTML reference fix for eventsource

McCool: note dates in references are picking up older dates for some reason
... for the WoT-Scripting-API and WoT-Thing-Description

<scribe> ACTION: kaz to look into fixing references

<mlagally> proposal: accept the latest draft of the architecture spec after incorporating the fixes to the outdated spec references for proposed REC publication

RESOLUTION: accept the latest draft of the architecture spec after incorporating the fixes to the outdated spec references for proposed REC

Lifecycle

<mlagally> https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5

Lagally: updated description of decomissioned
... need to have better flow around onboarding
... also have another document with terminology

McCool: I think we should focus on states in diagram, not how get there
... for example, covering discovery for onboarding, etc. will make things very complicated
... what really matters is we get into a state where the device has keys provisioned for access rights, etc.

Lagally: missing is what happens if device is de-registered from a service

McCool: I think since this can happen without the state on the device changes
... so it's a question about whether it belongs in this diagram
... if we put everything in one diagram, it will be impossible to read

Lagally: yes, should keep things simple, and focused on a specific purpose
... one purpose is to define specific terminology
... we should also get alignment with ping; both process and our work so far

McCool: I think we need to do some more work before reaching out to ping, eg. use cases
... also I realized recently we need to do more work to really preserve privacy during discovery...
... regarding the diagram, I think the arc labels need some work
... eg "factory reset" label seems like it applies to the arcs to the decommissioning state, which is not correct
... I like the idea of a table; can make it normative, and put details in it
... then the diagram can just be an informative illustration
... and we can omit details to make it easier to understand

Zoltan: have prepared some material for LwM2M and OCf
... it is quite big... maybe can just give references and people can look at them
... have references to docs, sections, tables, etc.

Lagally: it would good to have slides with the references, and then a high-level summary

Zoltan: best outcome is that we improve our diagram based on review of other standards

Lagally: ok, let's defer this discussion until next week

MMI use cases

<inserted> scribenick: kaz

<inserted> McCool: use case 1-1:

Kaz: a speakerphone like Amazon Echo at the living room could behave as an extended speech interface device for the smartphone at my bedroom when I'm at the living room

<inserted> McCool: use case 1-2:

McCool: next Intelligent Home Apparatus

Lagally: would be better to change the title ?
... like "Unified smart home control"

<inserted> McCool: use case 3-1:

McCool: next "Interactive Public Spaces"
... privacy-sensitive like add insertion
... filled in some gaps
... expected devices, data, etc.

Lagally: we're 5 mins over
... how to proceed?

Kaz: would suggest McCool create PRs to put the use cases to the w3c/wot-architcture repo
... and we continue the review next week

McCool: sounds good

Lagally: aob today?

<inserted> scribenick: McCool

McCool: summarized mmi

Lagally: let's merge and then discuss via issues
... also the digital twins?

McCool: we did not have time to discuss, but it is in its own file, so sure

<kaz> [Call 2 adjourned]