WoT f2f in Osaka - Tuesday, OpenDay -- 16 May 2017

<inserted> scribenick: kaz

remote: Michael_Koster, Yingying_Chen

Greetings from Panasonic

Ohsumi-san and Fuchiue-san

Today's agenda - Naka-san

naka: explains today's schedule
... and provide logistics information
... coffee and lunch will be served at the HUB space
... demo available at the presentation room during coffee breaks
... wifi available
... demo tour and social dinner in the evening
... leaving here at 16:40
... ISO rep not available, so Naka-san will give brief explanation

ISO/IEC JTC1 SC41 work

naka: scope and standards
... explains the work briefly

kaz: IRC is available at #wot

naka: Getting Started with WoT Project

kaji: [ Conceptual Architecture and Objective ]
... [ Practical viewpoint of Silo vs WoT ]
... one-stop universal platform
... [ WoT Framework example ]
... [ Usage of Semantics on WoT ]
... global identical vocabulary needs to be defined
... regardless of languages, etc.
... attribute for discovery
... [ WoT Framework example ]
... WoT client and WoT server
... [ WoT Servient building block ]
... servient has both the capabilities of server and client
... [ WoT server in device itself ]
... [ WoT server for constraint device ]
... [ WoT interoperability PoC in Panasonic ]
... 5 different services included in Panasonic demo yesterday
... smart apps platform
... smart home platform
... IRKit platform
... Hue platform
... Alexa platform

<naomi> kaji: [ Cross Interaction Demo ]

kaji: KDDI tmp sensor and Siemens app
... Siemens app controls Panasonic light
... Fujitsu app also controls Panasonic light
... [ Standardization process in WoT ]
... Yongjing mentioned the story during the AC meeting in Beijing
... please join WoT IG/WG!
... questions/comments?

(no specific questions/comments)

kaji: shows photos
... from Santa Clara meeting
... and video from Osaka
... and then video from Santa Clara again

Logistics note - Naka-san

naka: IRC channel: #wot
... can join using http://irc.w3.org/?channels=#wot

Star Micronics introduction - Miura-san

koji: tx for inviting me
... 3 main products
... automatic lathes, small printers, precision products
... legacy POS printer
... 2nd top world share
... also mobile POS printer
... 1st world share
... various partners
... POS market pyramid
... mobile POS market is our focus
... why Star is No.1?
... keeping up with the trend of smartphone/tablet market
... many innovative solutions
... MFi certified
... multiple lineups
... easy-to-use SDK freely available
... so easy setup
... original software services like WebPRNT, PassPRNT and AllReceipts
... that's why Star's printers are de-facto
... software solutions including Star SDK
... both for iOS and Android
... not only APIs but also source codes
... Star WebPRNT
... from iOS, Android and Surface
... HTML/JS + StarLine XML/HTTP over wifi
... web bridge function for Bluetooth
... Star PassPRNT as software-based printer server
... driver application

remote+ Sam

scribe: Star AllReceipts
... digital receipt is provided by AllReceipts service
... current situation
... our printer supports this kind of multiple I/F
... USB-A, USB-B, LAN and another USB-A
... tx

kaz: ok to upload this presentation?

koji: let me check

mm: printer driver as a web service?
... payload as XML?

koji: yes

<inserted> scribenick: naomi

kaz: koji mentioned a difficulty of basic printer which restricts sizes
... in this case any data is available, the slide says
... do you have any specific problems?
... w3c wot group has difficulty of streaming data
... we need some method on it
... how to specify data

koji: BoS printer market we need to have 100% guarantee
... streaming idea works but not perfect solution for 100% guraantee
... we have to set data links inside of Thing Description
... client have to count data

mm; JSON market

scribe: tickets
... are you looking that market?

koji: we might sell ticket service

kaz: mm, you mean online store?

mm: no, my point is point of sale
... we have IoT application to log in

koji: we support multipul language
... and right to left, left to right
... this is not for wot but we focus Thing Description

kaz: another question
... do you have usual http and @2 style of printing?
... W3C CSS writing mode spec
... do you use that kind of specs on printing?

koji: yes
... it'll fit our concerning point
... this software idea can fit as well
... inside of apps to generate convert commands
... it can easy to generate receipt

kaz: interesting point
... relationship between semantics and CSS style

koji: any questions?

<kaz> [ morning break ]

OCF 1.0 Overview - Michael McCool

<inserted> scribenick: kaz

mm: [Outline]
... OCF history, background and markets
... OCF architecture and principles
... working on diagrams
... changes between OIC 1.1 and OCF 1.0 draft candidate
... [OCF - High Level Goals]
... easy for developers
... common data model
... initial target is smart home
... [OCF&IoTivity]
... , open source implementation
... budget under Linux Foundation
... C++ implementation and now Node implementation
... primary focus on CoAP
... [OCF - Conceptual Framework]
... profiles, core framework and transports
... core framework is standard mechanism
... interaction/data model, resource model
... discovery, data transmission, data management, device management
... transports: bluetooth, wifi, lte, ...
... [OCF - Resource Model]
... common properties and resource specific properties
... interfaces basically provide views
... sensor view, etc.
... [Resource Model - examples]
... resource URI: /a/light1 and /a/fan1
... /a/light1 - rt: oic.ex.light; if: oic.if.rw; prop: discoverable, observable; n: myHallWayLight; State: 0 (off); Dim Level: 0
... [Common Interaction Model - Transport Agnostic]
... Create, Retrieve, Update, Delete, Notify
... [Let's look deeper at a Resource ...]
... Server - DevA
... [There can be more Properties]
... [Resource Type - Data Modeling]
... 2 things to describe metadata
... first thing is set of properties
... by JSON Schema
... and verbs using RAML (ReStful API Modelling Language)
... describes the request and response
... and now the third option
... emerging standard, Swagger (aka, open API)
... OIC introspection
... [Table 19: oic.wk.p resource type definition]
... OCF specification defines "oic.wk.p" resource type for platform and its list of properties
... [Link]
... how to define te connection between two resources
... /a/room and /switch
... relative URL
... {
... "href": "/switch",
... "rel": "contains",
... "anchor": "/a/room",
... ...
... [Collections]
... also scenes
... set of devices
... can be stored
... [Collections...example]
... "Room" collection - room has lights and fan
... /my/room/1
... {
... "rt": "acme.room",
... "if": ["oic.if.r", "oic.if.rv"],
... ...
... [Interfaces]
... subset of resources
... interface provides a "view" into a Resource or Collection
... Interface defines allowed methods and semantics on that "view"
... OCF has a set of predefined Interfaces
... [OCF ER Model]
... not from the official OCF spec...
... platform-devices
... WoT semantics define similar model
... [Major Changes in OCF 1,0 (Draft) CR from OIC 1.1]
... Swagger/OpenAPI for: data modeling, introspection, RAML is still used in main spec definition
... Enhanced security: alignment with IETF ACE and AllJoyn
... better specification of uses of certificates
... better management of onboarding and offboarding processes
... mandatory access control, system management
... [Summary]
... resource-oriented architecture
... IoTivity

<scribe> ... New features in OCF 1.0

UNKNOWN_SPEAKER: Questions?

dsr: relationship between OCF and narrow band IoT?

mm: OCF work is protocol/transport-agnostic
... CoAP designed based on UDP

T2TRG Overview Discussion - Michael Koster

mk: [T2TRG]
... started in March 2015
... chartered by IRTF
... investigate "Internet of Things" applications and architecture beyond IETF CoRE/CoAP
... [Topics]
... quite broad
... REST and Hypermedia for connected things
... Event-state duality, pub-sub pattern, notification
... Connected Thing Life Cycle
... Management and Operations
... Work with Industry SDOs and Fora - work with W3C WoT on data models and semantics
... Plugtests, Interop tests
... Practical Semantic Interoperability
... Mobile code
... Security
... [Research Drafts]
... RESTful design guidance
... Security challenges for IoT
... Hypermedia content types
... CoRAL - CBOR Encoding of Hypermedia Controls
... HSML - SenML + Link-Format Hypermedia Controls
... [Events]
... meet in conjunction with IETF and related activities
... joint meetings with Industry Fora, e.g., OCF
... semantic interop in conjunction with IETF 99 in Prague, July 15-16
... planning for semantic interop events
... multiple device ecosystems participating
... [Meetings]
... IETF 93, IETF 94, Jan 2016 (Sophia Antipolis Plugtest), March 2016 (with IAB Semantic Interop), IETF 95, IETF 96, Sep. 2016 (Joint with W3C WoT IG), Oct. 2016 (with Eclipsecon), IETF97, Mar. 2017 (joint with OCF), ...
... [Next T2TRG Event]
... T2TRG Joint Semantic and Hypermedia Interoperability Workshop
... with IETF 98, Prague, Jul 15-16
... OCF, LWM2M/IPSO, W3C WoT, iot.schema.org
... example topics: cross-ecosystem semantic interop planning, hypermedia controls for actions, hypermedia-driven apps, models and model translation
... [References]
... datatracker.ietf.org/rg/t2trg/charter/
... github.com/t2trg
... datatracker.ietf.org/rg/t2trg/documents/
... questions?

mm: next f2f of wot will be held Dusseldolf

mk: ending on Thursday and will travel to Prague on Friday

Security Process in W3C WoT - Elena Reshetova

er: [Importance of Security for WoT]
... why security is important for WoT?
... 10 things to know about the Oct 21 IoT DDos attacks
... avarage IoT device is compromised after being online for 6 mins
... large-scale IoT security breach coming in 2017
... here are the biggest IoT security threats facing the enterprise in 2017
... very popular topic
... [Always good to remember]
... 3 principles: start early, involve everyone and explore existing solutions
... [How do we do it?]
... 1. threat model - understand what you need to protect and why
... 2. scoping - organize and prioritize threats, define security objectives
... 3. state of the art - study related areas and their approaches to security
... 4. solutions - find a suitable mitigation for each in-scope threat
... 5. implementation and evaluation - implement and test each solution
... questions?

<scribe> ... (continues)

UNKNOWN_SPEAKER: [1. Threat model - Understand what you need to protect and why]
... stakeholders, assets, attackers/attack surfaces, threats
... [Resources]
... WoT security documentation: github.com/w3c/wot/tree/master/security-privcy
... WOT IG security webconf: www.w3.org/WoT/IG/wiki/IG_Security_WebConf
... that's all

naka: questions?

kaz: everybody from this meeting room is encouraged to join the Security TF :)

elena: good point

[ Lunch ]

afternoon session will start at 13:30

remote+ Elena

OpenFog - Masahiro Shimohori

ms: [Building this necessary interoperability of fog-enabled applications requires a collaborative approach]
... funded by the 5 companies and one univ
... Intel, MS, Cisco, Dell, ARM, Princeton Univ.
... [OpenFog mission]
... mission statement
... To drive industry and academic leadership in fog computing architecture, testbed develpment, and a variety of interoperability ...
... [OpenFog COnsortium]
... 57 members
... 6 founders
... affiliations, contributing members, and other members
... [OpenFog Consortium goals]
... technology, innovation, education
... testbed to demonstrate interoperability
... ... evangelize fog computing
... doing a lot of efforts
... [Organizational structure]
... technical WGs
... architecture framework, SW infrastructure, communications, security, manageability, liaisons, testbed
... under the technical committee
... and marketing committee, social impact committee, americas committee, greater china region committee, japan committee and european committee (planned)
... [OpenFog Reference Architecture]
... www.OpenFogConsortium.org/RA
... [The OpenFog reference Architecture Framework]
... software/device developers
... interoperability in IoT, 5G, AI and other complex data/network intensive apps
... and creating common language for fog computing and wil help unify the edge/fog ecosystem
... under a single, interoperable, testable set of hardware and software standards
... [Key pillars of the OpenFog architecture framework]
... security, scalability, open, autonomy, RAS, agility, hierarchy, programmability
... [Architecture description with perspectives]
... green layer: sensors, actuators, control; protocol abstraction; hardware platform instracture
... dark blue: network, accelators, compute, storage; OpenFog Node Security; OpenFog Node Managment; Hardware Virtualization
... blue: Node Management & Software Backplane
... Orange: Application Support
... grey: Application Services
... vertical mechanisms: Security, Manageability, Data Analytics&Control, ...
... perspectives; node view (green), system view (dark blue), software view (blue);
... [A closer look at fog nodes]
... gog nodes communicate with each other in a distributed manner

<scribe> ... new value chain and business entities

UNKNOWN_SPEAKER: [Technical WG focuses]
... [Reference Architecture Contributions]
... [Node Security]
... basis of Fog security
... hardware root-of-trust
... physical security
... [Network Security Aspect]
... node to cloud
... REST over TLS
... node to node
... HTTP over TLS, CoAP over DTLS
... node to device
... IP adaptation
... [Data Security Aspect]
... Data in Use
... data in memory undergoing procesisng

<scribe> ... [New Work & Task forces]

<scribe> ... new TFs established

UNKNOWN_SPEAKER: [Security Requirement Taskforce]
... mission statement
... to define sets of requirements that has to express the fundamental security (and in the future evaluation) requirements for an OpenFog compliant (in the future certified) node and system.
... as a reminder, the work shall support both brown and green field implementations
... [Security Requirement Taskforce (contd.)]
... Method
... [Security MVIs]
... minimum viable interface
... [Smart Objects for an OpenFog Architecture: SW Infrastructure WG - Task Group]
... What are Smart Objects?
... Why do we care about Smart Objects?
... Smart Object Landscape, ...
... [What's a Smart Object?]
... an object that describes its own possible interactions
... can be physical, e.g., sensor, computing device, wearables
... can be cyber, elgl, data, executable code, apps, services, clouds
... [Why do we care about Smart Objects?]
... reduce time and cost to develop, deploy and maintain IoT applications
... data interoperability; service, object and software composition
... [Smart Object Landscape]
... W3C Semantic Web, W3C Web of Things, ipso, OCF, IIC, Haystack Connect, UPnP, Allseen Alliance, IETF, OPC, RDA, NIST
... [Smart Object Issues]
... a lot of challenges
... frameworks: standards, ontologies, interoperability
... [Charter]
... working closely with other SDOs including W3C
... [Transaction Management & Orchestration Princeples]
... [Logical Transaction Layers - concept]
... distributed resources
... 1. Fog Platform Infrastructure - Shared Resources
... 2. Microservice Logical Fabric assemblies
... 3. Data, Object, Interface&Access
... 4. Fog Transaction&Management
... defines scope of services
... e.g., with a building
... would control temperature and humidity
... resources are connected to storages
... project could be energy management
... [What is a Transaction?]
... transaction based TLA time (e.g., 10sec) consists of:
... Internet (3sec)
... Application (3sec)
... System+Storage (2sec)
... Network (2sec)

mm: fog as distributed cloud
... micro services?
... access to a service, e.g., computer vision
... public devices
... difference in computing storage

ms: go back to the diagram of "Logical Transaction Layers"
... these are system infrastructure view (=Fog Platform Infrastructure layer)
... metrics of business for a transaction
... [Transaction Level Management Elements]
... the fog is logical description of resources
... on top of that, orchestration layer
... and delivery model
... on the left side
... transaction management e.g., by blockchane
... [Resource, Data, Object Transaction Management]
... [Moving forward...]
... [OpenFog Priorities (2017-2018)]
... technical WGs under the technical committee
... interface standardization with an SDO -> open reference implementation
... certification and interoperability fogfests
... regional use cases and test cases from regional committees
... APIs to standardize

mm: questions?

unida: regarding smart object
... diversity is one problem
... how to overcome?

ms: study in the market
... e.g., W3C perspectives, OCF perspectives
... common vocabulary in those areas
... not to have one single standard
... but consider interoperability
... common vocabulary the use cases
... other SDOs like OIC, AllSeen
... maybe OCF would have different profiles

yz: similar question
... you plan to pick up one of existing standards
... or interoperability like WoT

ms: would take existing good things
... don't want to reinvent wheels
... interoperability with existing standards
... may work on open source project with other SDOs
... also testbed project

yz: common vocabulary?
... can be done with somebody collaboratively?
... how to host that?

ms: openfog has a liaison wg
... liaison from technical viewpoint
... communicate with other SDOs
... simple liaison and collaborative work on common vocabulary

yz: generating your own vocab?

ms: don't have to be a single entity

<dsr> scribenick: dsr

Kazayuki Ashimura presents W3C work on automotive.

The automotive industry has seen lots of change.

Kaz runs through the list of Automotive WG meetings

He presents a diagram showing the vehical signal architecture.

The bottom level is the car’s internal system as exposed e.g. on the CAN bus

The Vehicle Information API is exposed via Web Sockets using a Vehicle server.

Kaz mentions the VW submission https://www.w3.org/Submission/2016/01/

Work has started on a test framework.

The Vehicle Signal Spec is defined by GENIVI not W3C.

Kaz lists some links to related other work.

The Web of Things architecture will enable an ecosystem of automotive related services.

The VIAS (Vehicle Information API spec) defines an API that is exposed to applications in a web browser.

The VISS (Vehicle Signal Spec) feeds a JavaScript library that then exposes the VIAS API to applications.

Michael McCool asks a question on how to satisfy requirements for functional safety certification.

One solution is to prevent the apps from being able to control the car in ways which would risk safety.

This may require a module that enforces this.

Kaz: the car maker is responsible for that.

Michael: this becomes very challenging for self-driving cars.

Kaz: web of things needs to handle safety and security

Kajimoto-san asks about requirements such as response time.

scribe: we break for coffee and a group photo …

oneM2M Overview - Norikazu Yamasaki

<inserted> scribenick: kaz

ny: agenda
... overview of oneM2M partnership project
... standardization at IoT/M2M Service Layer
... release 2 and release 3 ...
... [Global Partnership Project
... 8 partner type 1: atis, TIA, ETSI, tsdsi, CCSA, TTA, ARIB, TTC
... also patner type 2 (vertical payers and industry groups)
... BBF, OMA, HGI (merged into oneM2M), New Generation M2M Consortium, Global Platform, CEN&CENTRIC
... [200+ Members Organizations]
... [Purpose & Deliverables]
... oneM2M purpose: to specify and promote an M2M common service layer
... oneM2M deliverables: technical reports (informative) and technical specs (normative)
... [oneM2M Organization Structure]
... Steering Committee - finance, legal, marketing, methods/proc., certification
... [Work Process]
... various use cases: enargy, enterprise, healthcare, public services, residential, other, transportation, industry
... common requirements based on the use cases
... that is stage 1
... stage2/3 is specification
... [M2M/IoT Common Service Layer]
... M2M Service Layer was defined by ITU-T FG-M2M
... software layer
... between M2M apps and communication hardware/software that provides data transport
... nomally rides on the top of IP
... [oneM2M Architecture Approach]
... Pipe (vertical)
... Horizontal Interoperability (based on Common Service Layer)
... [oneM2M Architecture]
... application layer (consists of Application Entity): device AE, Gateway AE
... Service Layer (consists of Common Service Entity)
... Network Layer (consists of Network Service Entity)
... defining interface between entities
... [Common Service Functions (CSFs)
... registration, discovery, security, group management
... data management&repository, subscription&notification, device management, application&service management
... ...
... [Communication Protocols]
... reuse IP-based existing protocols
... service layer core protocols: CoAP, MQTT, etc.
... [Timeline of oneM2M Key Events]
... 2012 - 2013 - 2014 - 2015 - 2016 - 2017
... oneM2M partnership project launch: Q3, 2012
... Release 1 Issued: Q1, 2015
... Interoperability Test Event #1: Q3, 2015
... Interoperability Test Event #2: Q2, 2016
... Release 2 Issued: Q3, 2016
... Interoperability Test Event #3: 2017
... [oneM2M Release 2 Features]
... oneM2M as eneric interworking framework: AllJoyn/AllSeen, OIC, LWM2M
... Semantic interoperability

<scribe> ... [Ongoing Collaborations]

UNKNOWN_SPEAKER: with other SDOs
... utiliaztion: OMA, BBF, OASIS, HGi, IETF, ETSI
... Interworking: Allseen, OCF (including OIC and UPnP)
... Collaboration: IIC
... liaison&collaboration: ITU-T, GSMA, W3C, 3GPP, IEEE, ISO/IEC JTC1/WG10
... related to IoT technology
... regarding collaboration with W3C, the detail will be explained by Yongjing
... [Toward Release 3]
... Release 3 planning
... work track 1: Market Adoption Track (high priority)
... work track 2: Industrial IoT and smart cities
... work track 3: Forward Looking Areas
... [Phased Approach for ertification]
... initial phase: Oct. 2016-
... Global Phase: 2Q, 2018?
... [OSS and Implementation]
... Industry-driven open source software/platforms
... LAAS-CNRS: OM2M
... KETI: OCEAN
... Cisco: Open Daylight
... examples of commercial implementations/demos
... LG, Huawei, SK Telecom, Sierra Wireless, Ericsson, LG U+, kt, ...
... [Busan Smart City Project/Korea]
... [Smart City/France]
... [UK]
... [India]
... [LG U+]
... [Open IoT Platform (sensinov/France)]

Relationship between WoT and oneM2M - Yongjing Zhang

yz: [Technical Highlights]
... [Architecture Configurations]
... Infrastructure Node (IN)
... Middle Node (MN)
... Application Service Node (ASN)
... Application Dedicated Node (ADN)
... Non-oneM2M Node (NoDN)
... lot of options
... [Generic CRUD procedure]
... create request/response
... retrieve request/response
... [Communication Models]
... blocking synchronous
... non-blocking synchronous
... non-blocking asynchronous
... [oneM2M Resource Model vs WoT]
... CSEBase - base
... cseType - @type
... supportedResourceType, pointOfAccess, nodeLink - property?
... [Data Management]
... different resource types
... support hierarchical data model
... support semantic annotation
... can represent (depending on implementation context)
... eventable
... [Subscription & Notification (event)
... can set event criteria
... target address of notification
... [Device Management]
... mgmtObj as a template is specialized to individual management resource, e.g., deviceinfo and firmware
... some are actionable and some are not

mm: hybrid function

yz: [Group Management]

mm: OCF has same functionality

yz: [Semantics]
... RDF descriptors
... semantic discovery/query
... [Security: Enrollment & Security Association]
... enrollment phase and security association phase
... [Security: Encryption]
... [Security: Authorization (Access Control)]
... protocol specific
... [oneM2M Interworking Overview]
... to make different standards/technologies working smoothly together
... - transparent interworking
... - translucent interworking
... - semantic interworking
... [OIC/OCF Interworking]
... OIC/OCF domain and oneM2M domain
... [Ontology based Interworking]
... oneM2M based ontology
... the upper ontology serving as the anchor to facilitate/automate the mapping from external systems to oneM2M resource tree
... [Proximal Interworking via HAIM]
... mapping at the semantic level
... common template
... [HAIM example]
... SDT concepts vs WoT concepts
... [Interworking: WoT->oneM2M]
... exposing the WoT interface described in TD to oneM2M systems
... benefit: WoT services/data can be consumed by oneM2M apps
... question: do oneM2M apps need to understand WoT data model at all?
... [Interworking: oneM2M->WoT]
... exposing oneM2M interfaces to WoT systems
... benefit: oneM2M services/data can be consumed by WoT servients
... question: is WoT descriptive enough for oneM2M data models and interfaces?
... [Annex: oneM2M specification walkthrough]

kaji: comments/questions?

seba: we should look into the details
... possible scenario for the next PlugFest

yz: can provide further information for discussion

[ OpenDay ends]

Demo Tour at Panasonic Center Osaka

and then Dinner!

- DRAFT -

WoT f2f in Osaka - Tuesday, OpenDay

16 May 2017

Attendees

Contents

Greetings from Panasonic

Today's agenda - Naka-san

ISO/IEC JTC1 SC41 work

Logistics note - Naka-san

Star Micronics introduction - Miura-san

OCF 1.0 Overview - Michael McCool

T2TRG Overview Discussion - Michael Koster

Security Process in W3C WoT - Elena Reshetova

OpenFog - Masahiro Shimohori

oneM2M Overview - Norikazu Yamasaki

Relationship between WoT and oneM2M - Yongjing Zhang

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output