W3C

- DRAFT -

WoT-Security

20 Jan 2020

Attendees

Present
Kaz_Ashimura, Michael_McCool, Elena_Reshetova, Oliver_Pfaff, Zoltan_Kis, Michael_Lagally, David_Ezell
Regrets
Chair
McCool
Scribe
zkis, kaz

Contents


<kaz> scribenick: zkis

Edge Apps

<kaz> McCool: (goes through his slides on "Summary of proposed technical standards strategy")

McCool: 2 use cases in edge computing: compute (including AI inference) and IoT orchestration
... one tech that can be used is Web Workers, to offload work to a separate browser thread
... the idea is to generalize this offloading to a separate execution thread on the edge
... that runs the WoT Scripting API as well
... problems are security and persistence
... need a background execution model
... when the user is not on the web page (i.e. web page is not in focus and on the top)
... we need to discuss the security and privacy related issues
... new things (possibly new standards, or extensions): management API to deploy compute units, and discovery
... might involve new WGs

McCool describes the use cases in detail, for compute offload and IoT orchestration

McCool: requirements: access local network,security requirements, discovery
... the management APIs could be described by TDs
... discovery needs a directory node that could also be a first contact point for onboarding/configuration
... after authentication and setup, the edge browser app could offload compute units to edge devices
... propose Web Workers to deploy compute units to edge devices

Zoltan: need to differentiate between web workers and edge workers

Lagally: this already assumes some technology choices
... is this just an example, or is it part of the design?

McCool: the intent is to use current web technologies
... minimize the work that needs to be done in W3C
... there are a couple of tech that we could use or extend
... like PWAs (progressive web app) and web workers
... not impossible to do containers

Lagally: there are many options on the edge, such as docker contains, where you would be more flexible
... the distribution mechanisms using web tech are very (too) flexible

McCool: we need a concrete set of designs

<kaz> scribenick: kaz

McCool: code exist running on the network
... could use the other thing by other service
... using some cloud-based discovery service is also fine
... will have discussion with the Web&Networks IG
... Feb. 13th
... would put the information on the WoT wiki
... but will have a preliminary call with the WN Chairs first
... [Edge apps: definition and requirements]
... question about who would do the offloarding
... use case 1: compute offload
... allow browser-based computing access
... allow small IoT devices access
... small IoT devices might use Zigbee and/or CoAP
... would be useful to include offloading by small devices
... management service would be useful for small devices as well

Zoltan: part of binding?

Lagally: specific need for discovery?

McCool: issue we have to realize is...
... offloading could be a cloud service
... non-trivial changes for workers
... and I'm sure there will be huge size of privacy discussion there

Kaz: wondering about discovery as a kind of "google search"
... can actually get something (some device) by searching with Google or visiting Amazon shopping site

McCool: yeah, DNS people also are interested and that's related to IETF's work

Kaz: yeah, underlying mechanism could vary

Privacy Threat Model

McCool: created an issue

Issue 152

McCool: referring to the PING's Threat Model document: https://w3cping.github.io/privacy-threat-model/

Elena: threat model for what?

McCool: someone needs to look into it
... will read it for discussion next week
... would help us understand their view
... we can use GitHub issue to give comments

MUD

McCool: another topic is IETF MUD

Issue 153

McCool: MUD is inverse of TD
... how it could be aligned with TD?

MUD (D)TLS profiles for IoT devices

McCool: make sure the consistency
... different kind of algorithms
... related to our security model
... have created an issue (153)
... will be at IETF in Vancouver in March
... there will be DNS session and MUD session there

Lifecycle

McCool: I like this structure
... main pass and decommissioned
... need to think about a couple of things
... information lifecycle vs device lifecycle
... really separate lifecycle?
... might be redundant to have two separate lifecycle diagrams

Elena: don't know if we need to have separate diagrams

McCool: two issues
... directory service

Lagally: should have a separate diagram for directory

McCool: at the decommissioned phase, information should be destroyed
... there is no "coming-back" from decommissioned
... btw, there were some typos to be fixed

Lagally: we need to continue the discussion during the architecture call
... may need another phase between manufactured and bootstrapped

McCool: good point
... for device-specific ID
... we have chip manufacturer and IoT manufacturer
... we should wrap up the discussion and continue the discussion during the architecture call

Kaz: a device which includes multiple sub-systems like automotive should be also considered. right?

McCool: yeah

Kaz: can continue the detailed discussion during the Architecture call on Thursday

[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/01/27 06:46:45 $