ISO/IEC 30118-11:2021

Information technology – Open Connectivity Foundation (OCF) Specification - Part 11: Device to cloud services specification

This document defines functional extensions to the capabilities defined in ISO/IEC 30118-1 to meet the requirements of the OCF Cloud. This document specifies new Resource Types to enable the functionality and any extensions to the existing capabilities defined in ISO/IEC 30118-1.

Technologies de l'information — Specification de la Fondation pour la connectivité ouverte (Fondation OCF) — Partie 11: Spécification des services entre appareil et nuage

General Information

• Status: Published
• Publication Date: 17-Oct-2021
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 18-Oct-2021
• Due Date: 16-May-2022
• Completion Date: 18-Oct-2021

Overview

ISO/IEC 30118-11:2021 - "Information technology - Open Connectivity Foundation (OCF) Specification - Part 11: Device to cloud services specification" defines the device‑to‑cloud extensions of the OCF Core. It extends ISO/IEC 30118-1 to meet OCF Cloud requirements by specifying new Resource Types and any necessary extensions to core capabilities. The standard aligns OCF Cloud architecture with cloud reference models and provides detailed interaction and operational flows for secure device registration, connectivity, and resource publication.

Key topics and requirements

• OCF Cloud architecture & alignment with ISO/IEC 17789 (cloud reference architecture) and 17788 (cloud vocabulary).
• Operational flows covering user account creation, mediator registration, device provisioning, device registration, connection lifecycle (connect, refresh, close), publishing links to the OCF Cloud Resource Directory (RD), and deregistration.
• Resource model including the OCF Cloud Resource Directory and CoAPCloudConf resource: definitions, CRUDN behaviours and state machine considerations.
• Functional interactions for onboarding, provisioning, resource publication, client registration, discovery, device management, and deregistration.
• Network & connectivity guidance, including CoAP-based interactions and references to CoAP over TCP/TLS/WebSockets (IETF RFC 8323).
• Security integration, cross-referenced with ISO/IEC 30118-2 (OCF Security) and OCF Cloud Security; OAuth 2.0 and Bearer token usage (RFC 6749, RFC 6750) are normative references.
• API documentation expectations: Annex A supplies OpenAPI/Swagger 2.0 definitions for resource types and RD behaviour.

Applications

ISO/IEC 30118-11:2021 is intended for practical IoT scenarios where devices require reliable, standardized cloud connectivity:

• Secure device-to-cloud connections for smart home devices (appliances, locks, cameras, sensors).
• Cloud-mediated device discovery and resource publication via a Resource Directory for remote control and monitoring.
• Mediator-based onboarding/provisioning workflows for constrained or legacy devices to register with an OCF Cloud.
• Interoperability across platforms and cloud providers using standardized Resource Types and OpenAPI specs.

Who should use this standard

• Device manufacturers implementing OCF-compliant cloud features.
• Cloud providers hosting OCF Cloud services and RD implementations.
• IoT platform developers and system integrators designing device onboarding, provisioning, and cloud APIs.
• Security architects ensuring OAuth and OCF Cloud security alignment.
• Standards bodies and implementers needing OpenAPI/Swagger definitions for interoperability testing.

Related standards

• ISO/IEC 30118-1 (Core specification)
• ISO/IEC 30118-2 (Security specification)
• ISO/IEC 17788, 17789 (Cloud vocabulary & reference architecture)
• IETF RFC 6749, 6750 (OAuth 2.0)
• IETF RFC 8323 (CoAP over TCP/TLS/WebSockets)
• OpenAPI / Swagger 2.0 (API definitions)

Keywords: ISO/IEC 30118-11:2021, OCF, device to cloud, IoT, Resource Directory, CoAPCloudConf, Resource Types, OAuth, OpenAPI, cloud interoperability.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 30118-11
First edition
2021-10
Information technology — Open
Connectivity Foundation (OCF)
Specification —
Part 11:
Device to cloud services specification
Technologies de l'information — Specification de la Fondation pour la
connectivité ouverte (Fondation OCF) —
Partie 11: Spécification des services entre appareil et nuage
Reference number
© ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Symbols and abbreviated terms . 2
4 Document conventions and organization . 3
4.1 Conventions . 3
4.2 Notation . 3
5 Overview . 4
5.1 Introduction . 4
5.2 OCF Cloud architecture alignment with ISO IEC 17789 . 4
5.3 Architecture . 5
5.4 Interaction flow . 6
5.5 Cloud operational flow . 7
5.5.1 Introduction . 7
5.5.2 Pre-requisites and OCF Cloud user account creation . 7
5.5.3 Mediator registration with the OCF Cloud . 7
5.5.4 Device provisioning by the Mediator . 8
5.5.5 Device registration with the OCF Cloud . 8
5.5.6 Connection with the OCF Cloud . 8
5.5.7 Publishing links to the OCF Cloud RD . 8
5.5.8 Client to server communication through the OCF Cloud . 8
5.5.9 Refreshing connection with the OCF Cloud . 9
5.5.10 Closing connection with the OCF Cloud. 9
5.5.11 Deregistering from the OCF Cloud . 9
6 Resource model . 11
6.1 OCF Cloud Resource Directory . 11
6.1.1 Indirect discovery for lookup of Resources . 11
6.1.2 Resource Directory definition . 11
6.1.3 RD operational flows . 12
6.2 CoAPCloudConf Resource . 17
6.2.1 Introduction . 17
6.2.2 Resource definition . 17
6.2.3 Cloud status governing state machine . 18
6.2.4 Error handling . 20
7 Network and connectivity . 20
8 Functional interactions . 21
8.1 Onboarding, provisioning, and configuration . 21
8.1.1 Overview . 21
8.1.2 Use of Mediator . 21
8.1.3 Device connection to the OCF Cloud . 24
8.1.4 Device registration with the OCF Cloud . 24
8.2 Resource publication . 24
© ISO/IEC 2021 – All rights reserved iii

8.3 Client registration with the OCF Cloud . 25
8.4 Resource discovery . 25
8.5 Device deregistration from the OCF Cloud . 27
8.6 Device management . 27
8.6.1 Behaviours on Device maintenance state changes . 27
10 Security . 27
Annex A (normative) Swagger2.0 definitions . 28
A.1 List of Resource type definitions . 28
A.2 Resource directory resource . 28
A.2.1 Introduction . 28
A.2.2 Well-known URI. 28
A.2.3 Resource type . 28
A.2.4 OpenAPI 2.0 definition. 28
A.2.5 Property definition . 32
A.2.6 CRUDN behaviour . 33
A.3 CoAP Cloud configuration Resource . 33
A.3.1 Introduction . 33
A.3.2 Example URI. 33
A.3.3 Resource type . 33
A.3.4 OpenAPI 2.0 definition. 33
A.3.5 Property definition . 37
A.3.6 CRUDN behaviour . 37

iv © ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received
(see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see  www.iso.org/iso/foreword.html. In
the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Open Connectivity Foundation (OCF) (as OCF Device to Cloud Services
Specification, version 2.2.0) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1
PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 30118 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2021 – All rights reserved v

Introduction
This document, and all the other parts associated with this document, were developed in response to
worldwide demand for smart home focused Internet of Things (IoT) devices, such as appliances, door
locks, security cameras, sensors, and actuators; these to be modelled and securely controlled, locally
and remotely, over an IP network.
While some inter-device communication existed, no universal language had been developed for the
IoT. Device makers instead had to choose between disparate frameworks, limiting their market share,
or developing across multiple ecosystems, increasing their costs. The burden then falls on end users
to determine whether the products they want are compatible with the ecosystem they bought into, or
find ways to integrate their devices into their network, and try to solve interoperability issues on their
own.
In addition to the smart home, IoT deployments in commercial environments are hampered by a lack
of security. This issue can be avoided by having a secure IoT communication framework, which this
standard solves.
The goal of these documents is then to connect the next 25 billion devices for the IoT, providing secure
and reliable device discovery and connectivity across multiple OSs and platforms. There are multiple
proposals and forums driving different approaches, but no single solution addresses the majority of
key requirements. This document and the associated parts enable industry consolidation around a
common, secure, interoperable approach.
ISO/IEC 30118 consists of eighteen parts, under the general title Information technology — Open
Connectivity Foundation (OCF) Specification. The parts fall into logical groupings as described herein:
– Core framework
– Part 1: Core Specification
– Part 2: Security Specification
– Part 13: Onboarding Tool Specification
– Bridging framework and bridges
– Part 3: Bridging Specification
– Part 6: Resource to Alljoyn Interface Mapping Specification
– Part 8: OCF Resource to oneM2M Resource Mapping Specification
– Part 14: OCF Resource to BLE Mapping Specification
– Part 15: OCF Resource to EnOcean Mapping Specification
– Part 16: OCF Resource to UPlus Mapping Specification
– Part 17: OCF Resource to Zigbee Cluster Mapping Specification
– Part 18: OCF Resource to Z-Wave Mapping Specification
– Resource and Device models
– Part 4: Resource Type Specification
– Part 5: Device Specification
vi © ISO/IEC 2021 – All rights reserved

– Core framework extensions
– Part 7: Wi-Fi Easy Setup Specification
– Part 9: Core Optional Specification
– OCF Cloud
– Part 10: Cloud API for Cloud Services Specification
– Part 11: Device to Cloud Services Specification
– Part 12: Cloud Security Specification

© ISO/IEC 2021 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 30118-11:2021(E)

Information technology — Open Connectivity
Foundation (OCF) Specification —
Part 11:
Device to cloud services specification
1 Scope
This document defines functional extensions to the capabilities defined in ISO/IEC 30118-1 to meet
the requirements of the OCF Cloud. This document specifies new Resource Types to enable the
functionality and any extensions to the existing capabilities defined in ISO/IEC 30118-1.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 30118-1 Information technology -- Open Connectivity Foundation (OCF) Specification --
Part 1: Core specification
https://www.iso.org/standard/53238.html
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Specification.pdf
ISO/IEC 30118-2 Information technology -- Open Connectivity Foundation (OCF) Specification --
Part 2: Security specification
https://www.iso.org/standard/74239.html
Latest version available at: https://openconnectivity.org/specs/OCF_Security_Specification.pdf
ISO/IEC 17788 Information technology – Cloud computing – Overview and vocabulary
https://www.iso.org/standard/60544.html
ISO/IEC 17789 Information technology – Cloud computing – Reference architecture
https://www.iso.org/standard/60545.html
OCF Core Optional Framework, Open Connectivity Foundation Core – Optional Specification, Version
2.2.0
Available at: https://openconnectivity.org/specs/OCF_Core_Optional_Specification_v2.2.0.pdf
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Optional_Specification.pdf
OCF Wi-Fi Easy Setup, Open Connectivity Foundation Wi-Fi Easy Setup, Version 2.2.0
Available at: https://openconnectivity.org/specs/OCF_Wi-Fi_Easy_Setup_Specification_v2.2.0.pdf
Latest version available at:
https://openconnectivity.org/specs/OCF_Wi-Fi_Easy_Setup_Specification.pdf
OCF Cloud Security, Open Connectivity Foundation Cloud Security, Version 2.2.0
Available at: https://openconnectivity.org/specs/ OCF_Cloud_Security_Specification_v2.2.0.pdf
Latest version available at:
https://openconnectivity.org/specs/OCF_Cloud_Security_Specification.pdf
© ISO/IEC 2021 – All rights reserved 1

OCF Cloud API for Cloud Services, Open Connectivity Foundation Cloud API for Cloud Services,
Version 2.2.0
Available at:
https://openconnectivity.org/specs/OCF_Cloud_API_For_Cloud_Services_Specification_v2.2.0.pdf
Latest version available at:
https://openconnectivity.org/specs/OCF_Cloud_API_For_Cloud_Services_Specification.pdf
IETF RFC 6749, The OAuth 2.0 Authorization Framework, October 2012
https://tools.ietf.org/html/rfc6749
IETF RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage, October 2012
https://tools.ietf.org/html/rfc6750
IETF RFC 8323, CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets,
February 2018
https://tools.ietf.org/html/rfc8323
OpenAPI specification, fka Swagger RESTful API Documentation Specification, Version 2.0
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1 and
ISO/IEC 30118-2 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
– ISO Online browsing platform: available at https://www.iso.org/obp
– IEC Electropedia: available at http://www.electropedia.org/
3.1.1
Cloud Provider
entity or organization that hosts an OCF Cloud (3.1.2).
3.1.2
OCF Cloud
logical entity that is owned by the Cloud Provider (3.1.1) that authorised to communicate with a Device
on behalf of the OCF Cloud User (3.1.3).
3.1.3
OCF Cloud User
Client that has permissions to interact with the Devices that are exposed by the OCF Cloud (3.1.2).
3.1.4
Resource Directory
set of descriptions of Resources where the actual Resources are held on Servers external to the entity
hosting the Resource Directory (3.1.4), allowing lookups to be performed for those Resources
3.2 Symbols and abbreviated terms
UX User Experience
2 © ISO/IEC 2021 – All rights reserved

4 Document conventions and organization
4.1 Conventions
In this document a number of terms, conditions, mechanisms, sequences, parameters, events, states,
or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g.,
Network Architecture). Any lowercase uses of these words have the normal technical English meaning.
In this document, to be consistent with the IETF usages for RESTful operations, the RESTful operation
words CRUDN, CREATE, RETRIVE, UPDATE, DELETE, and NOTIFY will have all letters capitalized.
Any lowercase uses of these words have the normal technical English meaning.
4.2 Notation
In this document, features are described as required, recommended, allowed or DEPRECATED as
follows:
Required (or shall or mandatory)(M).
– These basic features shall be implemented to comply with Core Architecture. The phrases "shall
not", and "PROHIBITED" indicate behaviour that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should)(S).
– These features add functionality supported by Core Architecture and should be implemented.
Recommended features take advantage of the capabilities Core Architecture, usually without
imposing major increase of complexity. Notice that for compliance testing, if a recommended
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines. Some recommended features could become requirements in the future. The phrase
"should not" indicates behaviour that is permitted but not recommended.
Allowed (may or allowed)(O).
– These features are neither required nor recommended by Core Architecture, but if the feature is
implemented, it shall meet the specified requirements to be in compliance with these guidelines.
DEPRECATED.
– Although these features are still described in this document, they should not be implemented except
for backward compatibility. The occurrence of a deprecated feature during operation of an
implementation compliant with the current document has no effect on the implementation’s
operation and does not produce any error conditions. Backward compatibility may require that a
feature is implemented and functions as specified but it shall never be used by implementations
compliant with this document.
Conditionally allowed (CA)
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is allowed, otherwise it is not allowed.
Conditionally required (CR)
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is required. Otherwise the definition or behaviour is allowed as default
unless specifically defined as not allowed.
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
© ISO/IEC 2021 – All rights reserved 3

5 Overview
5.1 Introduction
An OCF Cloud extends the use of CoAP to enable a Device to interact with a cloud by utilizing following
features
– CoAP over TCP protocol defined in ISO/IEC 30118-1
– The requirements within this document including those for a Resource Directory
– Security requirements and SVRs defined within the ISO/IEC 30118-2
Devices which are not within a single local network may interact with each other using CoAP over TCP
(see ISO/IEC 30118-1) via an OCF Cloud. At any point in time, a Device is configured to use at most
one OCF Cloud. The OCF Cloud groups Devices that belong to same OCF Cloud User under an OCF
Cloud created User ID. All the Devices registered to the OCF Cloud and belonging to the same User
ID can communicate with each other subject to the Device(s) authorising the OCF Cloud in the ACE2
policies.
Annex A specifies the Resource Type definitions using the schema defined in the
OpenAPI specification as the API definition language that shall be followed by an OCF Device realizing
the Resources specified in this document.
Note that an OCF Cloud is not an OCF Device, but a logical entity that is owned by the Cloud Provider.
An OCF Cloud is authorized to communicate with a Device by the OCF Cloud User
5.2 OCF Cloud architecture alignment with ISO IEC 17789
Reference ISO/IEC 17789 defines a cloud computing reference architecture (CCRA) which can be
described in terms of one of four architectural viewpoints; user, functional, implementation, and
deployment. Of the four viewpoints, implementation and deployment are explicitly out of scope of
ISO/IEC 17789.
OCF defines an application capabilities type cloud service, providing Communication as a Service
(CaaS) (reference ISO/IEC 17788). This cloud service is provided by a cloud service provider, the
mechanisms used by the cloud service provider in managing their overall cloud infrastructure are
outside the scope of the OCF defined cloud service. The OCF definition is specific to the interface
offered by the cloud service to the cloud service customer, specifically the cloud service user.
There are three different user views defined. In the case where the cloud service customer is an OCF
Device as specified in this document then the views provided are:
- Interface for the OCF Device to provide information to the cloud service
- Interface for the OCF Device to retrieve information that has been provided to the cloud
service
In the case where the cloud service customer is another instance of a cloud service as specified in
OCF Cloud API for Cloud Services then the view provided is:
- Interface for the other cloud service instance to retrieve and update the information that is
provided via the cloud service
The OCF cloud service pertains specifically to a cloud service user, there is a single applicable cloud
service activity, that of "Use cloud service" defined in clause 8.2.21 of ISO/IEC 17789.
4 © ISO/IEC 2021 – All rights reserved

Credentials for the user of the cloud service are provided using OAUTH2.0 as defined by
IETF RFC 6749. The cloud service, either itself, or leveraging an external authorization server,
provides a bearer token that is required in all requests from all cloud users. Please see clause 8.1
and OCF Cloud Security.
All connectivity between a cloud user and the cloud service is via mutually authenticated TLS; see
clause 7.1 of OCF Cloud Security.
5.3 Architecture
The OCF Cloud is a logical entity to which an OCF Device communicates via a persistent TLS
connection. It encapsulates two functions:
– an account server function which is a logical entity that handles Device registration, Access Token
validation and handles sign-in and token-refresh requests from the Device. An OCF Cloud User
creates offline an account on the account server (by means of the mediator). The account server
is then also used to register the Devices (Clients and Servers) per account. Note that all accounts
are fully separated, e.g. logging into account A does not give access to Devices registered to
account B.
– a Resource Directory as defined by this document. The Resource Directory exposes Resource
information published by Devices. A Client, when discovering Devices, receives a response from
the Resource Directory on behalf of the Device. With information included in the response from the
Resource Directory, the Client may connect to the Device via the OCF Cloud.
This is illustrated in Figure 1.

Figure 1 – OCF Cloud Architecture
© ISO/IEC 2021 – All rights reserved 5

5.4 Interaction flow
This clause describes how the elements with the overall OCF Cloud interact. Figure 2 provides an
overall introduction, Table 1 provides additional context to the elements in the flow.

Figure 2 – OCF Cloud interaction model
Table 1 – OCF Cloud interaction flow
Steps Description
1 The Mediator obtains an Access Token for the OCF Cloud User from an Authorisation
Provider
2 The Mediator registers with the OCF Cloud
3 The Mediator provisions "oic.r.coapcloudconf" on the Device with an Access Token, the
URL of the OCF Cloud, the identity (UUID) of the OCF Cloud, and optionally an
Authorisation Provider Name.
4, 5 The Device establishes a TLS session to the OCF Cloud and subsequently registers
with the OCF Cloud
6, 7 The OCF Cloud validates the registration request and authorises the Access Token.
Returning information to the Device in the "uid" of the OCF Cloud User and the
expiration information of the Access Token.
In the case where the OCF Cloud also acts as the Authorisation Server step 1 from Table 1 may be
between the Mediator and the OCF Cloud in which case step 7 is not required.
6 © ISO/IEC 2021 – All rights reserved

5.5 Cloud operational flow
5.5.1 Introduction
The sub-clauses listed provide an informative overview of the flow which results on a Device being
registered with an OCF Cloud and Client interaction with that Device. The clauses provide references
to the applicable clauses within this document and other documents that provide normative details.
The flow consists of the following high-level steps:
– Pre-requisites and OCF Cloud User account creation (see 5.5.2)
– Mediator registration with the OCF Cloud (see 5.5.3)
– Device provisioning by the Mediator (see 5.5.4)
– Device registration with the OCF Cloud (see 5.5.5)
– Device connection with the OCF Cloud (see 5.5.6)
– Devices Publishing Links to the OCF Cloud RD (see 5.5.7)
– Client to Server communication through the OCF Cloud (see 5.5.8)
– Device refreshing connection with the OCF Cloud (see 5.5.9)
– Device closing connection with the OCF Cloud (see 5.5.10)
– Device de-registering from the OCF Cloud (see 5.5.11)
5.5.2 Pre-requisites and OCF Cloud user account creation
The OCF Cloud User has a Device that they want to hook up to the OCF Cloud so that they can access
it remotely.
The Device is onboarded to the OCF Network as defined in ISO/IEC 30118-2.
The OCF Cloud User makes use of a Mediator to provision the Device. A Mediator is a logical function
that may be on the OCF Cloud User's personal device (e.g. phone) or elsewhere. The Mediator is
configured with or through some out of band process to obtain the URL of the OCF Cloud (e.g. the
Mediator may be an application from the Cloud Provider).
The OCF Cloud User has access credentials for authenticating the OCF Cloud User to the
Authorisation Provider (i.e. user name/password or similar)
5.5.3 Mediator registration with the OCF Cloud
See 8.1.2.2, 8.1.2.3.
Via some trigger (e.g. a UX or other out of bounds mechanism), the Mediator authenticates the OCF
Cloud User to the Authorisation Provider and requests Access Token from an Authorisation Provider.
The Mediator registers by providing its Access Token to the OCF Cloud which verifies the token and
creates a User ID with which the Mediator is associated. All instances of a Mediator for the same OCF
Cloud User will be associated with the same User ID. Similarly, this same User ID may be used to
assign multiple Devices to the same OCF Cloud User
© ISO/IEC 2021 – All rights reserved 7

5.5.4 Device provisioning by the Mediator
See 8.1.2.3; see also ISO/IEC 30118-2 clause 7.5.2
The Mediator connects to the Device through normal OCF processes. The Mediator then requests an
Access Token from the OCF Cloud for the Device being provisioned. The Mediator updates the
"oic.r.coapcloudconf" Resource on the Device with the Access Token received from the OCF Cloud,
the OCF Cloud URI, and the OCF Cloud UUID. The Mediator may also provide the Auth Provider Name.
Note that this Access Token may only be used one time for the initial Device Registration with the OCF
Cloud.
5.5.5 Device registration with the OCF Cloud
See 8.1.3 and 8.1.4; see also ISO/IEC 30118-2 clauses 10.5, 13.11, 13.12
On configuration of the "oic.r.coapcloudconf" Resource by the Mediator, the Device establishes a TLS
connection with the OCF Cloud using the URI that was provisioned, and the Device's manufacturer
certificate and the trust anchor certificate(s) for OCF Cloud certificate validation, both of which were
installed by the Device manufacturer. The combination of the Device's manufacturer certificate and
OCF Cloud User's Access Token ensures the interactions between the OCF Cloud and OCF Devices
are within the OCF Cloud User’s domain.
To register with the OCF Cloud, the Device then sends an UPDATE operation to the Account Resource
on the OCF Cloud which includes the Access Token that was provisioned in the "oic.r.coapcloudconf"
Resource. Note that the OCF Cloud maintains a unique instance of the Account Resource for every
Device.
If the UPDATE is successfully validated, then the OCF Cloud provides an UPDATE response that may
provide updated values for the Access Token and details on the lifetime (expiration) of that Token. The
OCF Cloud also includes the User ID to which the Device is associated. All values returned are stored
securely on the Device. The returned Access Token is not written to the "oic.r.coapcloudconf" Resource.
The Device is now registered with the OCF Cloud.
5.5.6 Connection with the OCF Cloud
See 8.1.4, see also ISO/IEC 30118-2 clause 13.12
In order to enable passing data between the Device and the OCF Cloud, the Device sends an UPDATE
request to the Session Resource; once validated, the OCF Cloud sends a response message that
includes the remaining lifetime of the associated Access Token. The Device now has an active
connection and can exchange data.
5.5.7 Publishing links to the OCF Cloud RD
See clauses 6.1.3.2 and 8.2; see also ISO/IEC 30118-2 clause 10.5.
Once the TLS connection has been established to the OCF Cloud the Device exposes its Resources
in the Resource Directory in the OCF Cloud so that they may be seen/accessed remotely.
5.5.8 Client to server communication through the OCF Cloud
See 8.3, 8.4; see also ISO/IEC 30118-2 clause 10.5.
As for a Server, Clients follow this same process and register with the OCF Cloud.
The OCF Cloud allows communication between all of an OCF Cloud User's Devices based on the fact
that they have the same User ID.
8 © ISO/IEC 2021 – All rights reserved

When the Client attempts CRUDN actions on the Links hosted by the OCF Cloud, the OCF Cloud
forwards those requests to the Device. The Device responds to the OCF Cloud which then proxies the
response to the Client (i.e. Client -> OCF Cloud -> Device -> OCF Cloud -> Client).
5.5.9 Refreshing connection with the OCF Cloud
See ISO/IEC 30118-2 clause 13.13.
When (or before) the Access Token expires, the Device refreshes its token by sending an UPDATE
request to the Token Refresh Resource.
5.5.10 Closing connection with the OCF Cloud
See ISO/IEC 30118-2 clause 13.12.
To log out of the OCF Cloud the Device sends an UPDATE request to the Session Resource indicating
a "login" status of "false". This does not delete or remove any of the Device Registration information.
The Device may log back into the OCF Cloud at any point prior to expiration of the Access Token.
5.5.11 Deregistering from the OCF Cloud
See 8.5; see also ISO/IEC 30118-2 clause 13.10.
To deregister with the OCF Cloud, the Device sends a DELETE request message to the Account
Resource including its Access Token. The OCF Cloud sends a response message confirming that the
Device has been deregistered.
To connect to the OCF Cloud again, the Device has to re-follow the flow starting with Mediator
provisioning (see clause 5.5.4).
Figure 3 captures the state machine that is described by the informative operation flow provided in
clause 5.5.
© ISO/IEC 2021 – All rights reserved 9

Figure 3 – Overall operational state machine
10 © ISO/IEC 2021 – All rights reserved

6 Resource model
6.1 OCF Cloud Resource Directory
6.1.1 Indirect discovery for lookup of Resources
Indirect discovery is when a 3rd party, other than the discovering Device and the discovered Device,
assists with the discovery process. The 3rd party, called a Resource Directory (RD), only provides
information on Resources on behalf of another Device but does not host Resources on part of that
Device.
In Figure 4, the OCF Cloud acts as Resource Directory for Device A and Device D which are both part
of the same account. Device A and Device D publish their Resource information to the OCF Cloud.
Device C which is also part of the same account as Devices A and D, may query the OCF Cloud to
acquire the Resource information of Devices A and D.
OCF Cloud acts as Resource
OCF
Directory for Device A and
Cloud
Device D
/oic/res
Publish
OCF
(to /oic/res)
Device A
Discovery
Request
Resource
Links
OCF
Discovery
Publish
Device C
Response
(to /oic/res)
Resource
OCF
Links
Device D
Figure 4 – Indirect discovery of Resources by via an RD
Indirect discovery is useful for when Devices may not be on the same network and require optimization
for discovery or routing. Once Resources are discovered using indirect discovery, i.e., RD query, then
the access to the Resource is done by a request sent to the endpoint exposed by the RD for the
Resource.
6.1.2 Resource Directory definition
An OCF Cloud which acts as a Resource Directory (RD) will be involved in the following operations.
– RD discovery – the procedure by which publishing Devices discover an RD, in the case of the OCF
Cloud this is a direct result of Device registration with an OCF Cloud.
– Resource publish – the procedures with which Devices publish their Resource information, i.e.
Links.
rd
– Resource exposure – the feature with which RDs expose the Links hosted by the 3 party Devices
via their own "/oic/res".
© ISO/IEC 2021 – All rights reserved 11

An RD makes use of Resource Type "oic.wk.rd" defined in Table 2 and Table 3. An OCF Cloud that
supports the capability to host indirect discovery shall expose an instance of the "oic.wk.rd" Resource
Type in its "/oic/res" to announce that it serves as an RD. The use of the "oic.wk.rd" Resource Type is
restricted to OCF Clouds only, a proximal network Device shall not expose the "oic.wk.rd" Resource
Type.
The discoverable instance of "oic.wk.rd" shall allow only secure connections (e.g. OCF Endpoint with
a scheme of "coaps" or "coaps+tcp"). A publishing Device sends an UPDATE request to "/oic/rd" with
its Links in the payload to publish the Links in "/oic/res" of the RD. A publishing Device is responsible
for ensuring the RD has the correct published Links exposed via its "/oic/res".
Table 2 – "oic.wk.rd" Resource type definition
Pre-defined URI Resource Resource OCF Description Related
Type Type ID Interfaces Functional
Title ("rt" value) Interaction
"/oic/rd" Resource "oic.wk.rd" "oic.if.baseline" The Discoverable Discovery
Directory Resource Type through
with which an RD 1)
facilitates its discovery and
provides the criteria to
select an RD and 2) allows
Devices to publish their
Links in "/oic/res" of the
RD.
Table 3 – "oic.wk.rd" properties
Property Property Value type Value Unit Access Mandatory Description
title name rule mode
Selector "sel" "integer" N/A N/A R Yes Provides the criteria for RD
selection. An integer
representing a value
calculated by the RD. The
value is in the range of 0 to
100. The lower the value,
the more preferable the RD
is.
An RD may be queried at its "/oic/res" Resource to find Resources hosted on other Devices. A
publishing Device may publish all or a partial list of Resources they host to an RD. The RD then
responds to queries for Resource discovery on behalf of the publishing Device. Note that only Devices
that belong to the same account as the querying Device are visible in the exposed instance of "/oic/res".
For general Resource discovery, the RD behaves like any other Server in responding to requests to
"/oic/res".
6.1.3 RD operational flows
6.1.3.1 Discovering an RD
In Figure 5, a Device that wishes to publish its Resources first registers with the OCF Cloud that hosts
the RD and then publishes the desired Resource information.
12 © ISO/IEC 2021 – All rights reserved

Figure 5 – RD discovery and RD supported query of Resources support
A Client that performs Resource discovery via an OCF Cloud RD does so via a unicast request to the
RD; the Resource Directory defined in this document does not support the use of multicast queries to
discover instances of an RD.
6.1.3.2 Publish Resources
6.1.3.2.1 Overview
After the selection process of an RD, a Device may push its Resource information to the selected RD,
i.e., publish the Links in its "/oic/res" to the "/oic/res" of the RD.
The publishing Device shall mark as observable all Resources that are to be published to the RD, see
clause 11.3.2 of ISO/IEC 30118-1. The minimum set of Resources that a publishing Device shall
publish are the mandatory Core Resources "/oic/d" and "/oic/p" as well as Resources that are defined
as mandatory for the Device Type being published. The publishing Device may publish additional
Resources beyond the mandatory set identified in this clause. The publishing Device should only
publish Resources that are otherwise published to its own "/oic/res"; a publishing Device should not
publish non-Discoverable Resources or Resources hosted by some other Device.
A publishing Device shall respond to discovery requests on its "/oic/res" Resource unless all its
Discoverable Resources have been published in an RD.
6.1.3.2.2 Publish: Push Resource information
Resource information may be published using an UPDATE request sent to "/oic/rd".
A Device which hosts a Resource may publish the Resource information, i.e. the Link targeting the
Resource, to an RD by sending an UPDATE request with the Link in the payload. The published Link
shall be exposed through the "/oic/res" of the RD.
When a Device first publishes a Link or Links, it shall send an UPDATE request to the "/oic/rd"
Resource of the RD including the following key-value pairs in the payload:
– "di" –its value shall be the Device UUID of the publishing Device, i.e. the "di" value of "/oic/d".
© ISO/IEC 2021 – All rights reserved 13

– "links" –its value shall be the array of Links to be published. Links may omit the "ins" Parameter in
which case the RD will assign a value for each Link. The supplied "ins" Parameter by the Client is
allowed to be overruled by the RD, e.g. an RD can ignore the supplied "ins" value.
– "ttl" –its value indicates how long (in seconds) the publishing Device requests the RD to keep this
published Link.
Notice that the payload shall carry the appropriate Content-Format of "application/vnd.ocf+cbor".
{
"di": "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9",
"links": [
{
"anchor": "ocf://e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9"
"href": "/myLightSwitch",
"rt": ["oic.r.switch.binary"],
"if": ["oic.if.a", "oic.if.baseline"],
"p": {"bm": 3},
"eps": [
{"ep": "coaps://[fe80::b1d6]:1111", "pri": 2},
{"ep": "coaps://[fe80::b1d6]:1122"},
{"ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3}
]
},
{
"anchor": "ocf://e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9",
"href": "/myLightBrightness",
"rt": ["oic.r.brightness"],
"if": ["oic.if.a", "oic.if.baseline"],
"p": {"bm": 3},
"eps": [
{"ep": "coaps://[[2001:db8:a::123]:2222"}
]
}
],
"ttl": 600
}
When an RD receives this initial UPDATE request, it determines whether to grant the request or not.
If the UPDATE request includes any Links that are not marked as observable, then the request is not
granted, and the RD shall reject that request with an error response
...