Supporting IoT Interoperability via Open Standards Conexxus Strategy Conference, 13 Aug 2019 Michael McCool: Intel Principal Engineer / W3C WoT WG Co-chair Supporting IoT Interoperability via Open Standards Conexxus Strategy Conference, Aug 2019 Michael 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 Services Monitor • Manage data and control in local cloud RS-485 and predict performance with EtherCAT digital twins. Integration: System Architecture

Cloud Gateway

client client Connected Car

server proxy gateway Remote access and Synchronization Integration and Orchestration Device

client Existing Device Web Browser Device

client server server server Direct Thing-to-Thing Complement Web Integration Interaction Existing Devices

11 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 Requirements

Requirement Interaction Data Discovery Application Abstraction Interpretation Mechanism Environment

Priority Type

1 Ingestion Description Data Model

2 Transfer Description Data Model

Introduction, 3 Mesh Description Data Model Directory Management, APIs and/or Introduction, 4 Application Data Model APIs, Description Directory Runtime W3C WoT Standards Work W3C Web of Things – Building Blocks

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

WoT Thing Description (TD) Security Guidelines WoT Scripting API JSON-LD representation format to Standardized JavaScript object API for describe Thing instances with metadata. Any IoT Device an IoT runtime system similar to the Uses formal interaction model and Common Runtime Web browser. Provides an interface domain-specific vocabularies to between applications and Things to Application Script uniformly describe how to use Things, simplify IoT application development which enables semantic interoperability. and enable portable apps across Scripting API vendors, devices, edge, and cloud. The index.html InteractionData Model Model for Things WoT Binding Templates Protocol Bindings Properties Capture how the formal Interaction Model is mapped to concrete protocol Actions operations (e.g., CoAP) and platform Events HTTP CoAP features (e.g., OCF). These templates MQTT … are re-used by concrete TDs. 21 Published Candidate Recommendations

• WoT Architecture • WoT Thing Description (TD) – Constraints { "@context": [ ▪ Things must have TD (W3C WoT) "https://www.w3.org/2019/wot/td/v1", { "iot": "http://iotschema.org/" } ▪ Must use hypermedia controls (general WoT) ], – URIs "id": "urn:dev:org:32473:1234567890", "name": "MyLEDThing", – Standard set of methods "description": "RGB LED torchiere", – Media Types "@type": ["Thing", "iot:Light"], "securityDefinitions": ["default": { – Interaction Affordances "scheme": "bearer„ }], ▪ Metadata of a Thing that shows and "security": ["default"], describes the possible choices (what) to "properties": { "brightness": { Consumers, thereby suggesting how "@type": ["iot:Brightness"], Consumers may interact with the Thing "type": "integer", "minimum": 0, "maximum": 100, "forms": [ ... ] } Pull }, Handle = Affordance "actions": { What? How? "fadeIn": { ... Door = Thing Open Turn Published WG Notes

• WoT Security and Privacy • WoT Scripting API Guidelines – Proposal for a standard API to consume – Details beyond the security considerations and produce WoT Thing Descriptions in each specification for a holistic security – Provides interface between applications and privacy configuration of Things and network-facing API of IoT devices – Security testing plan (cf. Web browser APIs)

– Documents learnings from the design • WoT Binding Templates process – Documentation for how to describe existing IoT ecosystems (e.g., OCF or generic Web) with WoT Thing Description 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: Proposals

1.1 Maintenance 1.1 Improvements 1.1~2.0 Tentative 2.0 New Items • TD Security schemes • “Profile” for Plug&Play • Privacy-preserving lifecycle • IG output – TD default values and identity management – Oauth2 flows without override • Discovery – PoP tokens – Limit URI schemes, • Thing Templates – Peer-to-peer media types, etc. – ACE? • Discovery • Implementation View Spec • TD Link Relation types – “Web Thing API”-like – Directory – TD hierarchies – Specify details such as • Protocol Vocabulary – error responses, IANA? common features, etc. – MQTT(S) • TD vocabulary ➢ Could represent (including MQTT+WS) the “Profile” – Producer • Complex Interactions – Full JSON Schema – Monitor, cancel Actions – TD Default Values – Action/Event queues • Refactoring – Error recovery ➢ Hypermedia responses – Readability etc. • Observe Defaults – Update WoT Arch – Method / subprotocol use cases • Protocol Vocabulary – More examples – CoAP(S) (including CoAPS+WS)

28 W3C WoT Resources

• W3C WoT Wiki • W3C WoT Candidate Recommendations – https://www.w3.org/WoT/IG/wiki – https://www.w3.org/TR/wot-architecture/ (IG/WG organizational information) – https://www.w3.org/TR/wot-thing-description/ • W3C WoT Interest Group – https://www.w3.org/2016/07/wot-ig-charter.html • W3C WoT Working Drafts / Group Notes (charter) – https://www.w3.org/TR/wot-binding-templates/ – https://lists.w3.org/Archives/Public/public-wot-ig/ – https://www.w3.org/TR/wot-scripting-api/ (mailing list) – https://www.w3.org/TR/wot-security/ – https://github.com/w3c/wot (technical proposals) • W3C WoT Editors’ Drafts and Issue Tracker – https://github.com/w3c/wot-architecture/ • W3C WoT Working Group – https://github.com/w3c/wot-thing-description/ – https://www.w3.org/2016/12/wot-wg-2016.html – https://github.com/w3c/wot-binding-templates/ (charter) – https://github.com/w3c/wot-scripting-api/ – https://www.w3.org/WoT/WG/ – https://github.com/w3c/wot-security/ (dashboard) • 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

Discovery Ingestion Exchange Modeling Consumption Descriptions Encoding Protocols Semantics Query W3C: RDF Schema/SHACL W3C: RDF/JSON-LD W3C: SPARQL W3C: WoT Thing Descriptions OGS: O&M W3C: OWL LF: Swagger/OpenAPI iot.schema.org RAML Haystack JSON Schema W3C: SSN Microsoft: DTDL/DCL ETSI: NGSI-LD OPC-UA: XML Schema OneDM: SDF W3C: HTML IETF: HTTP OCF: oneiota IETF: CoAP SQL Zigbee Oasis: TOSCA/UDDI OMG: DDS ZWave Oasis: SAML Oasis: MQTT IETF: CBOR Oasis: AMQP LwM2M/IPSO IETF: JSON OneM2M W3C: XML YAML IETF: ICN OneDM IETF: COIN IETF: IP/TCP/UDP IETF: YANG 32 IoT Standards Map: Data – Goal

Discovery Ingestion Exchange Modeling Consumption Descriptions Encoding Protocols Semantics Query W3C: RDF Schema/SHACL W3C: RDF/JSON-LD W3C: SPARQL W3C: OWL W3C: Resource Descriptions

W3C: Data Schema

W3C: HTML IETF: HTTP W3C/ISO: IoT Semantics OPC-UA: W3C Data Schema IETF: CoAP OMG: DDS SQL W3C: JSON-LD 1.1 Oasis: MQTT IETF: CBOR Oasis: AMQP IETF: JSON W3C: XML IETF: ICN IETF: COIN IETF: YAML Structured Linked Data IETF: IP/TCP/UDP IETF: YANG 33 IoT Standards Convergence: Data

2019 2020 2021 2022 2023 2024 2025

W3C: WoT TD W3C: WoT TD 1.1 W3C: Resource

LF: OpenAPI W3C: OpenAPI Descriptions Description Description: OGS: O&M • Metadata such as Haystack location, security, iot.schema.org identification, owner, W3C: SSN ETSI: NGSI-LD support information, W3C: IoT Semantics relations OCF: oneiota • Network interface plus Semantics Zigbee One Data Data Models for each ZWave LwM2M/IPSO Model possible communication

OneM2M DataModel JSON Schema Data Model: W3C: Data Schema • Schema describes OPC-UA: XML Schema structure of data IETF: CBOR • Semantics describes Schema IETF: JSON W3C: JSON-LD 1.1 meaning of data. W3C: XML IETF: YAML Structured Linked Data 34 IoT Standards Map: Compute - Now

Discovery Edge Computing Security Introduction Exploration Stacks Components Mechanisms

IETF: mDNS IETF: Resource Dirs IIC/OpenFog Ref Arch Docker W3C: HTTPS Local IETF: DNS-SD IETF: SFC LF: EdgeX OCP: Open Containers IETF: DTLS OCF: UPnP LF: Akraino Ubuntu: Snaps IETF: TLS CoreOS: Rocket SSDP Eclipse: Edge Stack(s) IETF: OAuth2 Kata (sandbox) IETF: DHCP Starling X IETF: PSK SCONE (isolation) OPNFV IETF: Web Authn/FIDO ONAP Landscape NIST Security Baseline Bluetooth Ads Intel: Clear Linux/ECS Kubernetes QR Codes Oasis: TOSCA/UDDI AWS IoT RedHat OpenShift Interledger NFC Oasis: SAML AWS Greengrass Docker Swarm Hyperledger AWS Lambda CoreOS Tectonic W3C: Web Payments Azure IoT Hub Apache Mesos

Azure IoT Edge ECMAScript IETF: ICN FiWare (ETSI: NGSI) Node.js 35 IoT Standards Map: Compute - Goal

Discovery Edge Computing Security Introduction Exploration Stacks Components Mechanisms ISO/IEEE: Ref Arch W3C: HTTPS Local IETF: URL-based W3C: Service/Thing Secure Accelerated Introductions Directories Containers W3C: Edge Apps IETF: DTLS

X as a Service IETF: TLS IETF: OAuth2 AI Inference AWS IoT/Edge IETF: PSK W3C: Web Authn/FIDO AI Training

Azure IoT/Edge NIST Security Baseline System Management Service W3C: Interledger

Google IoT/Edge ECMAScript W3C: Dist. Ledgers ECMA: Node.js W3C: Web Payments 36 IoT Standards Convergence: Compute 2019 2020 2021 2022 2023 2024 2025

IETF: Resource Directory Discovery: W3C/IETF: Service/Thing IETF: ICN • Introduction: provides Directory just a URL first point of

Exploration W3C: Thing Description contact IETF: SSDP • Exploration: uses directory service (or IETF: mDNS

Discovery equivalent) identified by IETF: URL-based IETF: DNS-SD first point of contact to Introductions IETF: DHCP retrieve details of Introduction resources OCF: PnP

nGraph/ONNX AI-as-a-Service

AI Edge Computing: W3C: PWA + SW + WebML W3C: Edge Apps (incl. WebML) • AI: AIaaS, PWA/SW → Edge Apps, Secure OCP: Docker OCP: Secure Accelerated Containers Accelerated Containers Web Authn/FIDO: Identity • Security: HTTPS Local,

Identity (FIDO) Security IETF: HTTPS W3C/IETF: HTTPS Local • Language: standardize Node.js and Python Edge Computing Edge Node.js NF: Standard Node.js application environments

Lang. Python ?: Standard Python 37 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 https://www.w3.org/WoT/WG/

Dr. Michael McCool Dr. Matthias Kovatsch Principal Engineer Principal Researcher

Intel Huawei Technologies Technology Pathfinding Applied Network Technology Lab [email protected] [email protected]