OIC Standard Introduction PDF

Introduction of OIC standard  Scope of IoT Vertical Controller Profiles Smart Home Industrial Healthcare … Group ID & Protocol...

Introduction of OIC standard  Scope of IoT Vertical Controller Profiles Smart Home Industrial Healthcare … Group ID & Protocol management Addressing Bridge / GW Baseline Common Functionality Resource Device CRUDN Security Model management Discovery Messaging Streaming Controller App Cloud Interface Connectivity Wi-Fi BT/BLE Thread … Cloud Servers Cloud Servers service #1 service #2 domain domain Things Controller Controller Local Control Remote Control Server to Server 2  Definition of various Things By defining resourc es of things and By defining functions/operations its properties of things SetSwitch BinarySwitch -Power(in) -true(on), false(off) Resources Dimming -properties SetDimmingLevel Functions -dimmingSetting (int) -Input & Output Parameters -step (int) -step(in), range(in) -range [0-100] Brightness SetBrightness -brightness (int) -brightness (in) e.g., Light bulb -(no Verbs) + Objects -(Verbs + Obje cts) *Fixed set of verbs (CRUDN) from transport layer will be used -RPC model -Resourc e model in RESTful Archite cture (e.g., W3C, CSEP, etc.) 3 Support of Constrained Things *RAM Broad and Shallow Hierarchy 4 Support of Multiple Verticals Legacy vertical services usually designed as silos Home Health Domain → No common way to communicate among them Insulin level low! Need Help! … Health Home Industrial Health Home Industrial … Discovery Common Platform Addressing Messaging Health Home Industrial Security … A common platform provides a foundation Smart Home Domain for vertical servic es to collaborate and interwork by providing common services and data models 5 Interoperability Full interoperability from the conne ctivity layer up to the service layer is the only way to truly guarantee a satisfactory UX Interoperability at the Conne ctivity and/or Platform layer only provides partial interoperability which can ultimately lead to fragmentation ① Connectivity Level ② Platform Level ③ Service Level Interoperability Interoperability Interoperability Vertical Vertical Vertical Vertical Vertical Vertical Services Services Services Services Services Services Platform Platform Platform Platform Platform Platform Connectivity Connectivity Connectivity Connectivity Connectivity Connectivity 6 Interoperability & Certification Conformanc e test -Each device proves conformanc e to specifications Interoperability test -Each device prov es interoperability with other devices Conformance Test Certificate Issue CERTIFIED & Logo Licensing Device under Test Interopera bility Prerequisites: Test Dep end ency Certific ation (e.g. Connectivity) Certification Scope Tested Optional Tested Open Optional Mandatory Optional Optional Open (in spe c, c ert & committed Spec Sourc e Spec Sourc e in Open Source Project) Fe atures Fe atures Fe atures Fe atures Open Source Specification 9 Introduction to OIC – Optimized for IoT RESTful Architecture Common Certification Platform Program CoAP for Full Stack Constrained Interop. Test Devices 8 OIC Key Concepts (1/2) Free IPR License (Code: Apache 2.0 & Spe c: RAND-Z) ▪ License covers both code, standards and related IPR ▪ License applies to members and affiliates of members Dedicated and optimized protocols for IoT (e.g. CoAP) ▪ Specific considerations for constrained devices ▪ Fully compliant towards RESTful architecture ▪ Built-in discovery and subscription mechanisms Standards and Open Source to allow flexibility creating solutions ▪ Able to address all types of devices, form-factors, companies and markets with the widest possibility of options ▪ Open Source is just one implementation to solve a problem 9 OIC Key Concepts (2/2) Full stack definition for maximum interoperability ▪ Conne ctivity, Platform and Vertical Services defined ▪ License applies to members and affiliates of members Certification and Logo program ▪ Guarantees all devic es work together ▪ Consistent user awareness for interoperability 10 OIC Structure OIC Board of Directors Standard IoTivity Specification & Certification Open Source Project Open Source Coordination Steering Group Sponsored (funded) by OIC Membership Develops reference implementation Technology of OIC standard Planning Ecosystem Marketing Communications http://www.iotivity.org Specification Structure Infrastructure Core Framework Security Remote Access Certification Test Plans and Test Cases Resourc e Model Resource Specification (Domain agnostic) Per Vertical Domain Device Specification Domain Specific Resource Specification 20 OIC Roles OIC Client – i) Initiate an transaction (send a request) & ii) access an OIC Server to get a service OIC Server – i) host OIC Resource & ii) send a response & provide service 13 OIC Architecture OIC adopted RESTful Architecture Current OIC Archite cture defines 2 logical roles that devices can take -OIC Server : A logical entity that exposes hosted resources -OIC Client : A logical entity that accesses resources on an OIC Server OIC OIC Client Server R Model 1 14 Organization of an OIC Device OIC Device concept Resource URI: /oic / p rt: oic.wk.p /oic / p if: oic.if.r n: homePlatform policy: bm:11 /oic /res /oic /res pi: at1908 /oic / d /oic / d mnmn: Samsung /oic / mnt /oic / prs OIC Device 1 OIC Device 2 Physical Device e.g. light bulb Mandatory Optional 15  Device example: light device (oic.d.light) Example overview - Smart light device with i) binary switch & ii) brightness resource Device type: Light device (oic.d.light) [Defined by the domain] Associated resources - Core resourc es: ① oic/res, ② oic/d - Device specific resourc es: ③ Binary switch (oic.r.switch.binary), - Other optional resources can be exposed, in this example ④ Brightness resourc e (oic.r.light.brightness) Example: Smart light device with 4 resources Devic Devic oic/res Associated Resource Type M/O e e Title Type oic/d oic/res (oic.wk.core) M Binary switch oic/d (oic.d.light) M Light oic.d.light Brightness Binary switch (oic.r.switch.binary) M Brightness (oic.r.light.brightness) O 16 OIC Spec Features – Core Framework Spec ① Discovery: Common method for device discovery (IETF CoRE) Vertical Industrial Profiles Smart Home Internet … ② Messaging: Constrained device support as default (IETF CoAP) as well as protocol translation via intermediaries OIC Core Framework ③ Common Resource Model: Real world entities ⑥ defined as data models (resources)\ Group Protocol management ID & Addressing Bridge /GW ④ CRUDN: Simple Request/Response mechanism with Create, Retrieve, Update, Delete and Notify ③ Common ④ ⑤ ⑦ commands Device ⑤ Device Management: Network connection Resource CRUDN Security management Model settings and remote monitoring/reset/reboot ① ② functions Discovery Messaging Streaming ⑥ ID & Addressing: OIC IDs and addressing for OIC entities (Devices, Clients, Servers, Resources) ⑦ Security: Basic security for network, access control L2 Conne ctivity Networking Transport based on resources, key management etc 17 OIC Core Framework Basic Operation Discovery Operation Discovery -Discover access policies, device info and resources on the devices Operation - Get device information by retrieving resources -Control devices by changing resources -Observe change on the properties of resources Basic common services -Device Monitoring -Maintenanc e (e.g., reboot, factory rese t, statistics colle ction, etc.) Conne ctivity Connectivity Networking Transport Se curity Security 18 Protocol Stack Application Alternatives JSON or XML/EXI can Resource Model Encoding be negotiated Encoding (CBOR) v6 (v4 supported for IP Version legacy devices) CoAP DTLS TLS UDP TCP IPv6 L2 Conne ctivity (Wi-Fi) Project B OIC Stack 19 End point Discovery (CoAP Discovery) OIC devices make use of CoAP Discovery (defined by IETF RFC 7252) - Resource Discovery (Possible to discovery resource being hosted by device directly) - Low processing overhead on each node - High traffic efficiency (in terms of amount of data sent/received for discovery) 20 Encoding Schemes – JSON, XML/EXI, CBOR OIC resourc e is represented as sequence of bits by encoding schemes when to transfer it over the network OIC supports several encoding schemes and it will be negotiated and accepted by OIC Server when OIC Client requests OIC has mandated CBOR as the default encoding scheme JSON XML/EXI CBOR Description - Lightweight, text- - Binary - Concise binary obje ct based, language- compression representation based on independent data standard for XML JSON data model interchange format Standard IETF RFC 7159 W3C Efficient XML IETF RFC 7049 Interchange Format 1.0 Content Type /application/json /application/exi /application/cbor OIC M/O Optional Optional Mandatory * JSON: J avaScript Object Notation, EXI: Efficient XML Interchange, CBOR: Concise Binary Object Representation 21 Collection Resources A container is used to model complex structures An OIC Resourc e that contains one or more references (specified as OIC Links) to other OIC Resources is an OIC Collection An OIC Link embraces and extends typed “web links” as spe cified in RFC 5988 1/13/2016 22 Resource Directory Offloads handling of discovery (response to multicast messages) to devices that are capable of doing so Key enabler for sleepy end nodes, enhanc es battery life. Device B acts as Resource OIC Directory for Device A and Device B Device D; Device A and D do not respond to multicast query /oic/res OIC Publish Multicast Device A (to /oic Discovery res) Request by /oic/res Unicast Device C Publish Response with (to /oic resources for OIC res) Devices A, B Device C and D /oic/res Multicast OIC Group Device D 1/13/2016 23 Scenes/Rules/Scripts (1 of 3) Overview Mechanisms for automating certain operations Rules, Scripts and Scenes can be grouped and reused Scenes A static entity that stores a set of defined resourc e property values for a colle ction of resourc es. Provide a mechanism to store a setting over multiple OIC Resourc es that may be hosted by multiple separate OIC Servers. Once set up, can be used by multiple OIC Clients to recall a setup 1/13/2016 24 Scenes/Rules/Scripts (2 of 3) Rules A logical “if then” statement Consists of a rule condition and a Rule Member (a script) The rule condition is an evaluation criterion which can include evaluation of the value of a sensor on an OIC Server When the evaluation criterion is evaluated true then the Rule Members are set to a specific determined value A rule condition is evaluated when one of the observed resourc es in the rule condition changes 1/13/2016 25 Scenes/Rules/Scripts (3 of 3) Scripts A programmatic element that can be used to incorporate conditionals, delays, loops and other programmatic devices, including reading and writing scenes Scripts can consist of a set of steps that are executed either upon meeting the conditions of a rule or as part of another script, in order to automate tasks Scripts can also be used to set a scene to a specific value A Script is realized as the set of Rule Members that are executed when a rule condition holds true Summary Sc enes are bundled user settings Scripts are automated background tasks Rules are conditional statements that execute scripts when the condition is true 1/13/2016 26 Block Transfer with CoAP Messaging Basic CoAP messages work well for the small payloads we expect from light-weight, constrained IoT devices It is envisioned whereby an application will need to transfer larger payloads CoAP block wise transfer as defined in IETFdraft-ietf-core- block-17 shall be used by all OIC Servers that receive a retrieve request for a content payload that would exceed the size of a CoAP datagram 1/13/2016 27 Messaging Protocol Negotiation Supported messaging protocols are conveyed in the property (mpro) on the /oic/res (resourc e discovery) Omitting this property defaults to the messaging protocol as specified in the vertical specification (e.g., CoAP for Smart Home) After discovery, an OIC Client can use any of the supported messaging protocols supported by the OIC Server 1/13/2016 28 CoAP Serialization over TCP Provides the ability for CoAP to run over TCP in environments where TCP is already availa ble and where UDP may be blocked. If TCP is used then reliability is provided by TCP rather than the inherent reliability mechanisms within CoAP (confirmable messages). Use the new protocol negotiation feature to convey support during resource discovery (/oic/res) 1/13/2016 29 OIC Specification Overview Smart Home Device and Resource Specification Open Interconne ct Consortium, Inc. Smart Home Device and Resource Specification Way of Working Open Interconne ct Consortium, Inc. Defining OIC Components (on top of CORE) OIC Servers Defined by device identifier: standardized name of the device List of mandatory OIC resourc es per devic e Note that OIC Clients are implicitly specified as “opposite” side of an OIC Server. Currently OIC does not impose interaction sequences. All Resources are allowed to talk to/from any OIC Client at any point in time OIC Resourc e Defined by resource identifier: standardized name of the resourc e List of mandatory properties per resourc e List of allowed actions (read/readwrite/..) per resource 1/13/2016 32 Vendor extensions Vendor is allowed to: Create own defined (none OIC standardized) resources Create own defined (none OIC standardized) device types Extend existing devices with additional (not mandated) resources With standardized resource types With vendor defined resource types 1/13/2016 33 Tooling SHTG defines all resource schemas using JSON, all resource APIs using RAML SHTG developed Python based tool chain that auto-generates specification text based on the RAML and JSON that is defined per resourc e. Capabilities provided by the tooling include: - Auto validation of the RAML against RAML syntax rules - Auto validation of the JSON schemas against JSON Draft-04 rules - Auto valid ation of all example JSON against the applica ble JSON schemas High confidence level in the validity of the resource definitions Ability to simulate all resources 1/13/2016 34 Specifications Spe cifications are split in 2 documents: Device specification Resourc e spe cification The Device specification uses the resources defined in the resource specification 35 Device Specification Contains profiles of Core specification security specification Contains list of smart home devic es Each Smart home device definition contains: unique identifier (rt) a list of mandatory resourc es 36 Resource Specification List of reusable resourc es that are used in an Smart Home Device Contains generic list of error codes Uses core definitions Each Smart home resource definition contains: unique identifier (rt) Indication if the resource is an sensor or actuator List supported methods List per method the JSON schema for input and output Resources are specified in RESTful API Modelling Language (RAML) 37 Smart Home Use Cases Selected key enabling use cases to scope activity Use Case Priority Indoor Environment Control Cloud Lighting control OIC OIC Energy Saving Washer/Dryer 1 OIC Energy Management 3 Remote Acc ess for Devic e Control Smart watch notify and control 6 2 Smart Video Environment 1 Smart Smart Home Offic e Phone OIC Gateway OIC 3 Smart Garage Device Grouping and Control 1 Control proximal OIC Devices Multi player gaming 7 2 On board new Devices Smart watch gaming on TV 3 Control remotely with an OIC Client Fire safety monitor and Notify 4 Keyless Entry 2 Home Security Health Monitor and Notify 5 38 Indoor Environment Control Smart device WAN Network (Cloud) LAN Network (Home) Home GW Windows Smart device A/C Temperature Humidity 51 Lighting Control Smartphone WAN Network (Cloud) LAN Network (Home) Home GW Lighting Lighting Smartphone Lighting 40 Energy-saving washer/ dryer Smart device WAN Network (Cloud) LAN Network (Home) Home GW Smart device Washer Dryer 41 Energy Management 42 Remote Access Device Control 43 Keyless Entry WAN Network Smartphone (Cloud) LAN Network (Home) Home GW Door lock Smartphone Door locks 44 Home Security 45 Health Monitor & Notify WAN Network (Cloud) LAN Network (Home) Home GW Smartphone 46  Smart Home Device Type Device Type Minimum Resource Set Device Type Minimum Resource Set Air Conditioner Binary Switch, Temperature Binary Switch, Refrigeration, Refrigerator Temperature (2) Air Purifier Binary Switch Robot Cleaner Binary Switch, Mode Blind Open Level Smart Plug Binary Switch Dishwasher Binary Switch, Mode Switch Binary Switch Door Open Level Thermostat Temperature (2) Clothes Dryer Binary Switch, Mode Camera Media Clothes Washer Binary Switch, Mode Generic Sensor Sensor Fan Binary Switch Binary Switch, Audio, Media Source List ( Garage Door Door Receiver 2) Light Binary Switch Binary Switch, Operational State, Scanner Automatic Document Feeder Oven Binary Switch, Temperature (2) Security Panel Mode Binary Switch, Television Binary Switch, Audio, Media Source List Printer Operational State Water Valve Open Level Exposure of an OIC Devic e Type is Mandatory. If an OIC Server hosts an OIC known device then it shall follow a ll normative requirements in the Device Specification applicable to that Device. 59 Defined Resource Types (1/2) Resource Types Use Case Resource Types Use Case Air Flow Indoor Environment Lock Keyless Entry Air Flow Control Control Lock Code Battery Device Control Mode Binary switch Device Control Open Level Device Control Brightness Operational State Colour Chroma Ramp Time Lighting Control Lighting Control Colour RGB Refrigeration Device Control Dimming Indoor Indoor Environment Temperature Environment Door Control Control Energy Consumption Time Period Device Control Energy Management Energy Usage Indoor Environment Humidity Control Icemaker Device Control 60 Defined Resource Types (2/2) Sensor Support Resourc es Resource Type Use Case Sensor Resource Type Use Case Audio TV, Home Entertainment Acceleration Extended Sensor Set Auto Focus IP Camera Activity Count (for a Generic Sensor Device) Auto White Balance IP Camera Atmospheric Pressure Automatic Document Scanner Support Carbon Dioxide Feeder Carbon Monoxide Button Device Control Contact Colour Saturation IP Camera Glass Break DRLC Smart Energy Heart Rate Zone Energy Overload Smart Energy Illuminance Media IP Camera Magnetic Field Direction Media Source List TV, Home Entertainment Presence Movement (Linear) Robot Cleaner Radiation (UV) Night Mode IP Camera Sleep PTZ IP Camera Smoke Signal Strength Proximity Three Axis Touch Water Resource Types are Conditionally Mandatory. If an OIC Server hosts an OIC known resource then it shall follow all normative requirements in the Resource Specification applicable to that Resource. 61 OIC Bridge - Background & technical need There are many different IoT standards out there There are many different vendor solutions out there Hence it would be good for OIC if OIC could use these devices and create a (vendor defined) bridge to these non-OIC devices. Goal: To represent non OIC devices by means of a bridge as an OIC server on the network. Conceptual: Bridge establishes an OIC stand ardized north bridge so that all OIC clients can use the bridged devices. The south bridge will be vendor/implementation specific: it uses the protocol defined by the bridged device. (for example: it needs to realize Philips Hue APIs if a Hue light is bridged) 50  OIC Bridge - Definition An OIC smart home bridging device is a device that represents one or more other non-OIC devices as OIC Smart Home Devices on the network. The represented devices themselves are out of the scope of OIC. The bridging (that is, how the bridge communicates with the non-OIC devices) is implementation and vendor specific. The only difference between a ‘regular’ OIC Device and a bridged device is that the latter is encapsulated in an OIC Smart Home Bridge Device. An OIC Smart Home Bridge Device shall be indica ted on the network with an “rt” of “oic.d.bridge”. When such a device is discovered the exposed resources on the OIC Smart Home describe the devices that are being bridged. Bridge Device Entity OIC device (client) Non OIC OIC bridge device communication OIC light device Entity OIC OIC fan device communication 51 Bridge Device example: bridge (oic.d.bridge) OIC light device baseURI: 100.0.0.1:5683/0 oic/res oic/d (oic.d.light) OIC bridge device Binary switch baseURI: 100.0.0.1:5683 oic/res oic/d OIC fan device baseURI: 100.0.0.1:5683/1 oic/res oic/d (oic.d.fan) Binary switch 52  Bridging relationship with oic /res /oic/res /oic/d [ {"di": "bridge_device_id", { "links": [ "n": "myRoomBridgeDevice", { "href": "/oic/d", "rt": “oic.d.bridge", "rt": "oic.d.bridge", "if": "oic.if.r", "if": "oic.if.r", “di": “bridge_device_id“, "rel": "hosts"}]}, "icv": "oic.1.5“, } {"di": "light_device_id", "links": [ { "href": "0/oic/d", "rt": "oic.d.light", "if": "oic.if.r", "rel": “contains external"}, { "href": "1/myLightSwitch", "rt": "oic.r.switch.binary", "if": "oic.if.a", "rel": “contains external"}]}, {"di": "fan_device_id", "links": [ { "href": "1/oic/d", /oic/d /oic/d "rt": "oic.d.fan", "if": "oic.if.r", { { "n": "myRoomLightDevice", "n": "myRoomFanDevice", "rel": “contains external"}, "rt": “oic.d.light", "rt": “oic.d.light", { "href": "1/myFanSwitch", "if": "oic.if.r", "if": "oic.if.r", “di": “light_device_id“, “di": “fan_device_id“, "rt": "oic.r.switch.binary", "icv": "oic.1.5" "icv": "oic.1.5" "if": "oic.if.a", } } "rel": “contains external"}]} 65 ] OIC Security Summary OIC key management supports end-to-end device protection Resource layer ACLs allow intended interactions while preventing unintended interactions Secure device ownership helps prevent attacks when devices are added to the network 54 To Cross a Boundary We Must Define the Endpoint OIC Device An OIC d evic e is the endpoint...more spe cifically it is the OIC resourc e layer OIC resourc es define how device capabilities are exposed to other OIC devices Resourc es are acc essed securely through a secure channel such as DTLS End-to-end message encryption, integrity and replay protection OIC does not define endpoint hardening techniques Resource layer hardening is implied 55  Secure Resource Manager (SRM) OIC Device OIC Applic ation Resource Introspection (RI) layer Secure Resource Manager (SRM) Layer Secure Virtual Resource Manager Persistent Stora ge Policy Engine (PE) Resource (RM) Interface (PSI) database Connectivity Abstra ction (CA) layer SRM Duties protection – Manage se cure endpoint resourc es – Device ownership (Creds, ACLs, Device ID, Config status) – Security provisioning – Enforc e resourc e acc ess and endpoint – SVRD storage prote ction 56  Ownership Transfer and Bootstrapping Devices typically ship from a manufacturer in an “un-owned” state The user does some magic to affect taking ownership of the device, using an Onboarding Tool (OBT) Take over responsibility of the device and relieve manufacturer of any liability due any actions the devic e may take under user’s ownership Ownership transfer creates a relationship between an OIC device and an OBT. The relationship is defined through esta blishment of an Ownership Credential and a set of ownership-complete states Device Gets OBT Discovers Devic e is Un- Ownership Bootstrapping on the / Provisioning the Device owned Transfer Network 1/13/2016 57 Ownership Transfer and Bootstrapping Security Spec Defines Several Ownership Transfer Methods (OTM): Just-Works, DECAP, Random-PIN, Manufacturer Certificates Also allows Vendor Specific Method All OTMs are optional for an OIC device to implement, but it is mandatory to support at least one among Just-Works, DECAP, Random-PIN or Manufacturer Certificates. (We will need to be able to test all for certification ultimately) Might change in the future spe c OTMs differ in: How a devic e esta blishes trust How the physical owner’s “intent” is proved What cipher suites are used OTMs should bring the devic e to a well defined state 1/13/2016 58 Secured vs. Un-secured OIC Servers support a secured and un-secured interfac e. Generally speaking, the un-secured interfac e is for discovery only. All other services should be visible on the secured interface only. The un-secured interfac e has no message protection and no access control enforc ement Publicly visible unique IDs (device, platform, etc.) may present a privacy problem Discovera ble resourc es are resourc es that can be delivered as part of a discovery request (secured interface or not) At the time of creating, a resource is defined as “discovera ble” or not. 1/13/2016 59 Message Integrity and Confidentiality DTLS only for now. The devic es communicating need to have use able credentials to talk to each other. If they are missing, the devices could contact the CMS to get them. All se cured communication is encrypted and signed. 1/13/2016 60 Access Control Resources on the secured interface (that should be almost everything) are only accessible if there is a proper entry in the Access Control List No ACL, No Service An ACL says “X can do Y on resource Z” X can be a deviceID, a role, or a group (in the future) Y can be any combination of CRUDN If no ACL is present, and the device has an AMS configured, it can ask the AMS what authorization X has on Z. 1/13/2016 61 Access Control : example /oic/sec/acl { "Subject": ”switch1", "Resource": "/light", Subject: d evic e / group or role "Permission": "00000100", "Period": " ", Resource(s): one or more URN "Re currenc e": " ", "Rowner": "oic.se c.ams" Permission: bitma p of CRUDN } Period(s): validity periods Recurrence(s): recurrence rule(s) Rowner: the service that owns this acl 1/13/2016 62  Resource Access Example OIC Client OIC Server Device3 Device1 acl0 Devic e1 /oic/d /oic/light/0 GET /oic/d /oic/d Properties: Properties: Read Model On-Off [{“/ oic / d”, “Model”, “T”, “Mfg Date”, “1/1/2015”}] Mfg Date DimLevel OIC Stack acl1 OIC Client /oic/light/1 Device2 Device2 Properties: x PUT/oic/light/1 /oic/light/1 On-Off Read, Write DimLevel 11 – 5p RSP 4.01 [{“/ oic / light/ 1”, “On-Off”, “Off”, “DimLevel”, “80”}] Daily Acc ess is blocked if no ACL match is found Device1 request to get /oic/d is accepted due to ACL Read permission Device2 request to update /oic/light/1 is denied due to time-of-day policy An intermediary (Devic e4) may also enforc e ACLs Credential Management OIC devices can support the use of both symmetrical and asymmetrical credentials for establishing se cure communication - Symmetric Key is mandatory - Local PKI mechanism is supported (Keys are issued in home domain and used only within that domain.) Missing credentials could be procured from a CMS Credentials may have an expiration period Expired credentials can be refreshed 1/13/2016 64 Credential Management : example /oic/se c/cred { ”CredID": ”1”, "Subje ctID": ”devic e1”, CredID: Local short ID ”RoleID”: ” ”, SubjectID: device or group ”CredType": "1”, ”PublicData”: “”, RoleID(s): roles this credential allows a subje ct to assert “PrivateData ”: “ABCDEFGHIJKLMNP”, CredType: sym/asym/cert/… "Period": ”P1W ", PublicData, PrivateData, OptionalData "Re currenc e": " ", "Rowner": "oic.se c.ams" Period: Expiration period of credential } Credential Refresh Method: Rowner: service that can modify this resource 1/13/2016 65 OIC Specification Overview Remote Access Open Interconne ct Consortium, Inc. Remote Access (“RA”) in OIC (implementation plan) Remote Access endpoint Devices: Remote Access Endpoints (“RAE”): OIC Servers also capable of XMPP, optionally capable of ICE-client Remote Access Proxies (“RA-Proxy”): Superset of RAE – Capable of ‘representing’ “RA-constrained devices” “RA-Constrained”: Devices incapable of natively supporting RA tech Cloud Components: XMPP Server(s) 80  The OIC RA Model Non-OIC (RA-Constraine d ) device XMPP Server 1 XMPP Server 2 … RA-Constrained OIC Device “RAE” “RA-Proxy” CoAP XMPP-native Q R Realm II Realm I K L M S N A F P G ? H B J C D E 1/13/2016 81 Remote Access XMPP Servers Application Discovery, RI Layer Resource Model Routing control SRM DM Client ACL/Cred IP BT BLE XMPP Media data CA Layer Platform Remote Things (RAE) Client Server Components: - Device Management Server: Device/Capability Registration and Authorization - Signaling Server: Delivering candidate address to recipient, discovery, presence, low BW data, SDP control Client Components: RA Endpoint (RAE) & RA-Proxy - XMPP Client 69 RA as defined in Spec 1.0 Format for bare-JIDs (owner) and full-JIDs for RAEs Includes JID-Resource overloading for: OIC Spec version Device-type UUID Mapping from Core/Smart-Home Resources to full-JID format Allows for Presence, Remote Discovery, XMPP-Roster-based access Communication of CRUDN messages between the OIC clients and OIC servers that are in the same roster 70 RA-Roadmap – Post Spec 1.0 priorities Defining RA-Proxy functionality Leverage XMPP PubSub (XEP-0060) Extending full-JID overloading model & XMPP Presence Adding RA-Proxy Device-type – avoid gratuitous remote device queries “App notes” for temporary remote acc ess via XMPP Multi- User Chat (MUC – XEP-0045), Family members, neighbors, etc. Adding Jingle (XEP-0166) for media signaling 71 Thank you!