Supporting IoT Interoperability via Open Standards

Conexxus Strategy Conference, 13 Aug 2019Michael McCool: Intel Principal Engineer / W3C WoT WG Co-chair

Supporting IoT Interoperability via Open Standards

Conexxus Strategy Conference, Aug 2019Michael McCool: Intel Principal Engineer / W3C WoT WG Co-chair

Outline

• The Role of Open Standards in IoT– Business justification for IoT standards– Use cases

• The W3C Web of Things (WoT) Standards Work– Building Blocks– Key deliverable: Thing Description– Planned work: Profiles, Thing Directory

• The Future of Open Standards– Standards landscape for data and edge computing– Gaps and opportunities– Roadmap: where do we go from here?

Role of Open Standards in IoT

Business Justification• Why Standards?

– Standards support interoperability of products from multiple vendors.▪ Multiple sources for standardized products reduces risk.▪ Competition reduces cost.

– Standards support portability and scalability▪ Vendors can develop products and services that can be used in multiple markets.

– 40% of IoT use cases require integration of services from multiple verticals▪ McKinsey: The Value of Digitizing the Physical World

– Investing in closed systems is a business risk▪ Machina Research: Smart Cities Could Waste $341 Billion by 2025 on Non-standardized IoT Deployments

• Why Open Standards?– Free access to standards documents– Royalty-free– Wide participation

Use Case: Connected Car Charging

• EcoG provides PaaS support for custom fast EV charging

• Can link charging access and pricing to retail activity

Image provided under Creative Commons Attribution-Share Alike 3.0 Unported License by BP63Vincent

Use Case: Mozilla WebThings Gateway

• Mozilla provides a WoT gateway hub which bridges several other IoT standards to WoT

• Devices are interconnected locally, enhancing privacy

Use Case: AI-Enabled Security

• AI appliance provides person identification service

• Other Things provide motion detection and image capture services

• Orchestration system discovers sensors and AI service and connects then to trigger alarms when person identified in interdicted zones.

Other Retail Use Cases…

• Inventory monitoring and order management

• Automated checkout

• Security and access control

• Employee monitoring for hygiene management

• Customer reward programs tied to activity

• Loitering alerts

• Foot traffic monitoring and analysis

• Parking access control and guidance

• Smart signage and targeted marketing

• Refrigeration monitoring, including lifecycle tracking during shipment

Use Case: Smart Factory Digital Twins

• Provide bridge between IT and OT systems

• Manage data and control in local cloud and predict performance with digital twins.

EtherCAT

RS-485

MonitorServices

Integration: System Architecture

11

Device

DirectThing-to-Thing

Interaction

Existing Device

ComplementExisting Devices

DeviceWeb Browser

Web Integration

serverclientserver server

Integration and Orchestration

Remote access and Synchronization

client

Gateway

client

gateway

Cloud

client

proxy

Connected Car

server

Goal of Standards

Goal of Standards

Interoperability

Goal of Standards

Interoperability

“I can plug it in and it just works.”

Goal of Standards

Interoperability

“I can plug it in and it just works.”

In other words: standards help to automate or streamline an integration process so the user does not have to think about it.

Goal of Standards

Interoperability

“I can plug it in and it just works.”

To define: “I”, “plug”, “it” and “works”

What is “Interoperability”?

Ingestion Interoperability: Connect Data Sources to Data Stores

• Normalize data using common semantics upon data ingestion.

Transfer Interoperability: Connect Multiple Stacks

• Exchange data between vertical silos.

Mesh Interoperability: Connect Devices and Services

• Communication and control among distributed devices and services

Application Interoperability: Deploy Code across a Distributed System

• Manage applications running in portable and secure contexts.

Interoperability: Technical RequirementsP

rio

rity Requirement

Type

InteractionAbstraction

DataInterpretation

DiscoveryMechanism

ApplicationEnvironment

1 Ingestion Description Data Model

2 Transfer Description Data Model

3 Mesh Description Data ModelIntroduction,Directory

4 ApplicationAPIs and/orDescription

Data ModelIntroduction,Directory

Management, APIs,Runtime

W3C WoT Standards Work

W3C Web of Things – Building Blocks

21

Any IoT Device

Protocol Bindings

Data Model

Events

Properties

Actions

Interaction ModelThe index.html for Things

JSON-LD representation format to

describe Thing instances with metadata.

Uses formal interaction model and

domain-specific vocabularies to

uniformly describe how to use Things,

which enables semantic interoperability.

WoT Thing Description (TD)

Standardized JavaScript object API for

an IoT runtime system similar to the

Web browser. Provides an interface

between applications and Things to

simplify IoT application development

and enable portable apps across

vendors, devices, edge, and cloud.

WoT Scripting API

Common Runtime

Scripting API

Application Script

Capture how the formal Interaction

Model is mapped to concrete protocol

operations (e.g., CoAP) and platform

features (e.g., OCF). These templates

are re-used by concrete TDs.

WoT Binding Templates

…

HTTP

MQTTCoAP

Security Guidelines

WoT Architecture

Overarching umbrella with architectural constraints and guidance on how to use and combine building blocks.

Published Candidate Recommendations

• WoT Thing Description (TD){"@context": [

"https://www.w3.org/2019/wot/td/v1",{ "iot": "http://iotschema.org/" }

],"id": "urn:dev:org:32473:1234567890","name": "MyLEDThing","description": "RGB LED torchiere","@type": ["Thing", "iot:Light"],"securityDefinitions": ["default": {

"scheme": "bearer„}],"security": ["default"],"properties": {

"brightness": {"@type": ["iot:Brightness"],"type": "integer","minimum": 0,"maximum": 100,"forms": [ ... ]

}},"actions": {

"fadeIn": {...

Door = Thing

Handle = Affordance

What? How?

Open

Pull

Turn

• WoT Architecture– Constraints

▪ Things must have TD (W3C WoT)

▪ Must use hypermedia controls (general WoT)– URIs

– Standard set of methods

– Media Types

– Interaction Affordances

▪ Metadata of a Thing that shows and describes the possible choices (what) to Consumers, thereby suggesting howConsumers may interact with the Thing

Published WG Notes

• WoT Security and Privacy Guidelines– Details beyond the security considerations

in each specification for a holistic security and privacy configuration of Things

– Security testing plan

• WoT Binding Templates– Documentation for how to describe

existing IoT ecosystems (e.g., OCF or generic Web) with WoT Thing Description

• WoT Scripting API– Proposal for a standard API to consume

and produce WoT Thing Descriptions

– Provides interface between applications and network-facing API of IoT devices(cf. Web browser APIs)

– Documents learnings from the design process

Status and Recent Developments• Decision to adopt JSON-LD 1.1 proposed features to allow:

– Default values

– Object notation (name: value) instead of arrays

– Alignment with common JSON practices

• Security metadata– Focus on HTTPS (Basic Auth, Digest, Tokens, OAuth2)

• Protocol Bindings– Focus on HTTP and structured payloads compatible with JSON

– Support for Events also using subprotocols (e.g., long polling in HTTP)

• Extension Points– CoAP(S), MQTT(S), and further security schemes (e.g., ACE)

– Semantic annotations with custom vocabularies (JSON-LD @context and @type)

WoT Next Steps: Proposals1.1 Maintenance

• TD Security schemes

– Oauth2 flows

– PoP tokens

– ACE?

• TD Link Relation types

– TD hierarchies

– IANA?

• TD vocabulary

– Producer

– Full JSON Schema

– TD Default Values

• Refactoring

– Readability etc.

– Update WoT Archuse cases

– More examples

1.1 Improvements

• “Profile” for Plug&Play– TD default values

without override– Limit URI schemes,

media types, etc.

• Implementation View Spec– “Web Thing API”-like– Specify details such as

error responses, common features, etc.

➢ Could representthe “Profile”

• Complex Interactions– Monitor, cancel Actions– Action/Event queues– Error recovery➢ Hypermedia responses

• Observe Defaults– Method / subprotocol

• Protocol Vocabulary– CoAP(S)

(including CoAPS+WS)

28

2.0 New Items

• IG output

• Discovery

– Peer-to-peer

1.1~2.0 Tentative

• Privacy-preserving lifecycle and identity management

• Thing Templates

• Discovery

– Directory

• Protocol Vocabulary

– MQTT(S)(including MQTT+WS)

W3C WoT Resources

• W3C WoT Wiki– https://www.w3.org/WoT/IG/wiki

(IG/WG organizational information)

• W3C WoT Interest Group– https://www.w3.org/2016/07/wot-ig-charter.html

(charter)– https://lists.w3.org/Archives/Public/public-wot-ig/

(mailing list)– https://github.com/w3c/wot

(technical proposals)

• W3C WoT Working Group– https://www.w3.org/2016/12/wot-wg-2016.html

(charter)– https://www.w3.org/WoT/WG/

(dashboard)

• W3C WoT Candidate Recommendations– https://www.w3.org/TR/wot-architecture/– https://www.w3.org/TR/wot-thing-description/

• W3C WoT Working Drafts / Group Notes– https://www.w3.org/TR/wot-binding-templates/– https://www.w3.org/TR/wot-scripting-api/– https://www.w3.org/TR/wot-security/

• W3C WoT Editors’ Drafts and Issue Tracker– https://github.com/w3c/wot-architecture/– https://github.com/w3c/wot-thing-description/– https://github.com/w3c/wot-binding-templates/– https://github.com/w3c/wot-scripting-api/– https://github.com/w3c/wot-security/

• Reference Implementation: node-wot– https://github.com/eclipse/thingweb.node-wot

Future of Open Standards in IoT

WARNING

“It’s hard to make predictions, especially about the future.”

IoT Standards Map: Data – Now

32

Discovery Ingestion Exchange Modeling Consumption

Descriptions Encoding Protocols Semantics Query

RAML

W3C: WoT Thing Descriptions

W3C: RDF/JSON-LD

SQL

IETF: JSON

IETF: CBOR

IETF: HTTPW3C: HTML

W3C: XML

JSON Schema

iot.schema.org

ETSI: NGSI-LD

W3C: RDF Schema/SHACL

IETF: CoAP

OMG: DDS

IETF: IP/TCP/UDP

Oasis: MQTT

Oasis: AMQP

Haystack

W3C: SSN

W3C: OWLOGS: O&M

IETF: COINYAML

IETF: YANG

W3C: SPARQL

IETF: ICN

Oasis: TOSCA/UDDI

Oasis: SAML

OneDM

OCF: oneiota

Zigbee

LwM2M/IPSO

ZWave

OneM2M

OPC-UA: XML Schema

LF: Swagger/OpenAPI

Microsoft: DTDL/DCL

OneDM: SDF

IoT Standards Map: Data – Goal

33

Discovery Ingestion Exchange Modeling Consumption

Descriptions Encoding Protocols Semantics Query

W3C: RDF/JSON-LD

SQL

IETF: HTTPW3C: HTML

W3C: RDF Schema/SHACL

IETF: CoAP

OMG: DDS

IETF: IP/TCP/UDP

Oasis: MQTT

Oasis: AMQP

W3C: OWL

IETF: COIN

IETF: YANG

W3C: SPARQL

IETF: ICN

W3C: Data Schema

Structured Linked Data

IETF: JSON

IETF: CBOR

W3C: XML

IETF: YAML

W3C: JSON-LD 1.1

W3C/ISO:

IoT Semantics

W3C: Resource Descriptions

OPC-UA: W3C Data Schema

IoT Standards Convergence: Data

34

2019 2020 2021 2022 2023 2024 2025

De

sc

rip

tio

nD

ata

Mo

de

l Se

ma

nti

cs

Sc

he

ma

W3C: Resource

DescriptionsLF: OpenAPI

W3C: WoT TD

W3C: OpenAPI

IETF: YAMLW3C: XML

IETF: JSONIETF: CBOR

Structured Linked Data

W3C: JSON-LD 1.1

W3C: IoT Semantics

W3C: Data SchemaJSON Schema

OPC-UA: XML Schema

One Data

Model

OneM2MLwM2M/IPSO

ZWaveZigbee

OCF: oneiota

ETSI: NGSI-LDW3C: SSN

iot.schema.orgHaystack

OGS: O&MDescription:

• Metadata such as

location, security,

identification, owner,

support information,

relations

• Network interface plus

Data Models for each

possible communication

Data Model:

• Schema describes

structure of data

• Semantics describes

meaning of data.

W3C: WoT TD 1.1

IoT Standards Map: Compute - Now

35

Discovery Edge Computing Security

Introduction Exploration Stacks Components Mechanisms

IETF: ICN

Oasis: TOSCA/UDDI

Oasis: SAML

W3C: HTTPS Local

IETF: DTLS

IETF: TLS

IETF: OAuth2

IETF: PSK

Kubernetes

LF: EdgeX

LF: Akraino

Eclipse: Edge Stack(s)

Starling X

OPNFV

ONAP

IIC/OpenFog Ref Arch

AWS IoT

IETF: Resource DirsIETF: mDNS

IETF: DNS-SD

Bluetooth Ads

OCF: UPnP

SSDP

QR Codes

IETF: DHCP

Docker

IETF: SFC

Ubuntu: Snaps

NFC

Azure IoT Hub

AWS Greengrass

NIST Security Baseline

Interledger

SCONE (isolation)

AWS Lambda

Azure IoT Edge

Hyperledger

W3C: Web Payments

FiWare (ETSI: NGSI) Node.js

ECMAScript

OCP: Open Containers

CoreOS: Rocket

Docker Swarm

CoreOS Tectonic

Apache Mesos

RedHat OpenShift

LandscapeIntel: Clear Linux/ECS

IETF: Web Authn/FIDO

Kata (sandbox)

IoT Standards Map: Compute - Goal

36

Discovery Edge Computing Security

Introduction Exploration Stacks Components Mechanisms

X as a Service

W3C: HTTPS Local

IETF: DTLS

IETF: TLS

IETF: OAuth2

IETF: PSK

W3C: Edge Apps

ISO/IEEE: Ref Arch

AWS IoT/Edge

W3C: Service/Thing

DirectoriesIETF: URL-based

Introductions

Azure IoT/Edge NIST Security Baseline

W3C: Interledger

W3C: Dist. Ledgers

W3C: Web PaymentsECMA: Node.js

ECMAScriptGoogle IoT/Edge

Secure Accelerated

Containers

System Management

Service

AI Inference

AI TrainingW3C: Web Authn/FIDO

IoT Standards Convergence: Compute

37

2019 2020 2021 2022 2023 2024 2025

Dis

co

ve

ry Ex

plo

rati

on

Intr

od

uc

tio

n

Ed

ge

Co

mp

uti

ng

AI

Se

cu

rity

La

ng

.

OCF: PnP

IETF: DHCP

IETF: DNS-SD

IETF: mDNSIETF: URL-based

Introductions

W3C/IETF: Service/Thing

DirectoryIETF: ICN

W3C: Thing Description

IETF: Resource Directory Discovery:

• Introduction: provides

just a URL first point of

contact

• Exploration: uses

directory service (or

equivalent) identified by

first point of contact to

retrieve details of

resources

IETF: SSDP

Edge Computing:

• AI: AIaaS, PWA/SW →

Edge Apps, Secure

Accelerated Containers

• Security: HTTPS Local,

Identity (FIDO)

• Language: standardize

Node.js and Python

application environments

IETF: HTTPS W3C/IETF: HTTPS Local

OCP: Docker OCP: Secure Accelerated Containers

Web Authn/FIDO: Identity

Node.js NF: Standard Node.js

W3C: PWA + SW + WebML W3C: Edge Apps (incl. WebML)

nGraph/ONNX AI-as-a-Service

Python ?: Standard Python

Conclusions and Summary

Conclusions• Many current IoT applications tend to be siloed

– Solve a specific problem with a closed, custom implementation

• Open Standards can enhance IoT growth and deployment– Simplifying development and deployment

– Supporting development of modular, extensible systems

– Making it possible to source interchangeable equipment from multiple vendors

• Standardization will unlock scaling and new applications– Across verticals

– Across regions

• Standards support interoperability– But there are many kinds of interoperability…

– Different technical requirements

– Current device-cloud architectures will probably evolve to support more “local” solutions

Contacts

Dr. Michael McCool

Principal Engineer

Intel

Technology Pathfinding

michael.mccool@intel.com

Dr. Matthias Kovatsch

Principal Researcher

Huawei Technologies

Applied Network Technology Lab

matthias.kovatsch@huawei.com

https://www.w3.org/WoT/WG/