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 <10KB, Flash <100KB (RFC 7228)

• Less overhe ad/ Less Traffic

• Minimize CPU Load, Memory impacts, Traffic and Bandwidth
- Compact header
- Binary protocol
- Compressed encoding of payload

• Low Complexity
- Simple Resource Model
>Short URI (Late Binding w/ resource type defined)
>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", <update>
"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”, <symmetric pair-wise>
”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!