Cloud Integration 25.12 ONVIF™ www.onvif.org December, 2025 2008-2025 ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT.  THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 25.06 Jun-2025 Ottavio Campana First release 25.12 Dec-2025 Ottavio Campana Add listing the available FW images for cloud firmware upgrade This document defines the connection protocol for sharing cloud native devices between cloud-based clients. IETF RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication <> IETF RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage <> IETF RFC 7616 - HTTP Digest Access Authentication <> ONVIF Core Specification <> ONVIF Security Service Specification <> OpenAPI 3.1.0 <>

Device Sharing The procedure, started by the owner of the device, to allow another Operational Cloud Service to connect to the device. Device Transfer The procedure, started by the owner of the device, to allow another Operational Cloud Service to connect to the device. With device transfer, the original cloud service loses access. Operational Cloud Service The cloud platform receiving access to the devices from a provisioning cloud service. Manufacturer Cloud Service The initial cloud platform, provided by the device vendor, where the user can take ownership of the devices. Provisioning Cloud Service The cloud platform currently managing the device and starts either device transfer or sharing. Share Token A Token passed between a "Provisioning Cloud Service" and an "Operational Cloud Service" to prove that the "Provisioning Cloud Service" has access rights to the device. Uplink The connection established by the local service to the remote client. Web Services A web service is a software component or system that allows devices to communicate over the internet by exchanging data.

JSON JavaScript Object Notation JWT JSON Web Token MCS Manufacturer Cloud Service OCS Operational Cloud Service PCS Provisioning Cloud Service VMS Video Management System YAML Yet Another Markup Language.

On-boarding devices in cloud native Video Management Systems involves two major steps: A device taken out of the box connects with its pre-programmed parameters to a Manufacturer Cloud Service (MCS), so that the user can take ownership of the device. Once the device is successfully claimed by the user, the MCS behaves as a Provisioning Cloud Service (PCS). The user can transfer the device from a PCS to an Operational Cloud Service (OCS), i.e. the cloud native VMS the user expects to use for his surveillance system. N.B. that at any time, a OCS may act as a PCS. The scope of this cloud service covers only the second step, i.e. device sharing or transferring between different cloud services. The procedure outlined in these specifications can be used to share or transfer a device from a MCS to an OCS during the initial setup, but also from an old PCS to a new OCS. Figure demonstrates the two phases. N.B. the grey rectangle visually identifies the scope of these specifications.

If the original connection to the MCS is kept, it is possibile for the MCS to perform FW upgrade, upon request from the OCS. On the MCS, multiple versions of device FW images may be present for each model, so that the OCS can select the desired one. In case upgrading to the desired FW version will require multiple operations, the device and the MCS will perform them automatically, without the need for the OCS to know the required steps. Figure demonstrates the flow for cloud firmware upgrade.

Unlike for other services defined by ONVIF, in this document the term Web Services is the name of a standardized method of integrating applications using open, platform independent Web Services standards such as JSON, OpenAPI 3.1.0 and YAML over an IP network. JSON is used as the data description syntax, OpenAPI is used for message transfer and YAML is used for describing the services.

gives an overview of the basic principles for development based on Web Services and OpenAPI. The service provider (MCS) implements the ONVIF service. The service is described using the YAML-based file. Then, the YAML file is used as the basis for the service requester (OCS) implementation/integration. Integration is simplified using code generating tools that generate platform specific code that can be used by the developers to integrate the Web Service. The Web Service provider and requester communicate using the OpenAPI message exchange protocol. OpenAPI is a lightweight messaging protocol used to encode the information in a Web Service request and in a response message before sending them over a network. OpenAPI messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols. This ONVIF standard defines conformant transport protocols for the SOAP messages for the described Web Services. The Web Service overview section introduces into the general ONVIF service structure, the command definition syntax in the specification, error handling principles and the adopted Web Service security mechanisms.

The functions defined within this document do not require authehtication, since presenting a valid share token is a valid proof that the user was successfully authenticated by the MCS.

The services defined in this standard, whenever consumed, shall be protected by using only HTTPS as transport, in order to protect the share token from interception and unauthorized use.

To start the device sharing operation, the OCS must provide a share token to the PCS, to prove it has the rights to access the camera. The way the OCS retrieves the share token is beyond the scope of this specification. The share token must be a JWT and must include the following claims: onvif:xaddr: The full URI where the PCS will be accepting the incoming requests from the OCS onvif:sn: The serial number of the device. onvif:model: The device model. onvif:manufacturer: The manufacturer of the device. The claims onvif:sn, onvif:model and onvif:manufacturer shall match the values returned by GetDeviceInformation of the Device service.

This operation triggers sharing a device with a new Operational Cloud Service. Once the information is sent to the camera, the camera will generate a public key associated to the assigned ClientID. The generated public key will be passed to the PCS, so that it will transfer it to the OCS with the deviceSharingCompleted function, so that it will be able to authenticate the device and let it retrieve the JWT meant to be used to authenticate the Uplink Service. request startDeviceSharing [startDeviceSharing] response This is an empty message faults 400 - Invalid Argument Value

This operation notifies the new Operational Cloud Service that the camera was successfully configured. The public key shall be a base64 encoded DER-encoded PKCS#10 certification request. request deviceSharingCompleted [deviceSharingCompleted] response This is an empty message. faults No command specific faults defined.

This operation notifies the OCS of the available FW versions for a specific device model. It is mandatory that the value of the model parameter coincides with the model parameter of tds:GetDeviceInformationResponse. request model [string] response An array of lists with all the FW versions available for the specified model faults 400 - Invalid Argument Value