ГОСТ Р 71437-2024 Информационные технологии. Спецификация открытого взаимодействия (OCF). Спецификация служб «устройство–облако»

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСТ Р

71437—

2024

Информационные технологии

СПЕЦИФИКАЦИЯ ОТКРЫТОГО ВЗАИМОДЕЙСТВИЯ (OCF)

Спецификация служб «устройство—облако»

(ISO/IEC 30118-11:2021, NEQ)

Издание официальное

Москва Российский институт стандартизации 2024

ГОСТ Р 71437—2024

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 июня 2024 г. № 737-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 30118-11:2021 «Информационные технологии. Спецификация открытого взаимодействия (OCF). Часть 11. Спецификация служб «устройство—облако» (ISO/IEC 30118-11:2021 «Information technology — Open Connectivity Foundation (OCF) Specification — Part 11: Device to cloud services specification», NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

6 Федеральное агентство по техническому регулированию и метрологии не несет ответственности за патентную чистоту настоящего стандарта

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

©Оформление. ФГБУ «Институт стандартизации», 2024

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

II

ГОСТ Р 71437—2024

Содержание

1 Область применения..................................................................1

2 Нормативные ссылки..................................................................1

3 Термины и определения................................................................1

4 Сокращения и обозначения.............................................................2

5 Общие положения....................................................................3

5.1 Облако и устройства OCF...........................................................3

5.2 Согласование облачной архитектуры OCF с эталонной архитектурой облачных вычислений . . . .3

5.3 Архитектура облака OCF............................................................4

5.4 Обмен информацией с облаком OCF..................................................4

5.5 Последовательность операций взаимодействия с облаком................................5

6 Ресурсная модель.....................................................................9

6.1 Каталог ресурсов облака OCF........................................................9

6.2 Ресурс CoAPCIoudConf............................................................15

7 Сеть и возможности подключения.......................................................18

8 Функциональное взаимодействие.......................................................18

8.1 Включение, подготовка и настройка..................................................18

8.2 Публикация ресурсов..............................................................21

8.3 Регистрация клиента в облаке OCF..................................................22

8.4 Обнаружение ресурсов............................................................22

8.5 Отмена регистрации устройства в облаке OCF.........................................23

8.6 Управление устройствами..........................................................23

Приложение А (справочное) Определения ресурсов Swagger 2.0..............................25

Библиография........................................................................36

III

ГОСТ Р 71437—2024

Введение

Настоящий стандарт разработан в ответ на растущий спрос на ориентированные на умный дом устройства Интернета вещей (1оТ). Примерами таких устройств являются умные устройства бытовой техники, такие как дверные замки, камеры видеонаблюдения, датчики и исполнительные элементы. В настоящее время такие устройства создаются с учетом возможности надежного управления ими через IP-сеть локально или в удаленном режиме.

Несмотря на возможность обмена информацией между устройствами универсального языка для Интернета вещей разработано не было. Таким образом, производители устройств должны выбирать между разрозненными платформами, ограничивая свою долю на рынке, или разрабатывать устройства для нескольких экосистем, увеличивая затраты на разработку. Конечные пользователи должны определить, совместимы ли продукты, которые они хотят, с экосистемой, которая у них есть, или найти способы интегрировать свои устройства в свою систему и попытаться решить проблемы совместимости самостоятельно.

Эта проблема актуальна не только для умного дома: развертывание 1оТ в коммерческих средах также затруднено из-за проблем с безопасностью взаимодействия. Настоящий стандарт решает задачу создания безопасной структуры взаимодействия устройств Интернета вещей.

Целью настоящего стандарта и связанных с ним документов является подключение более 25 миллиардов устройств к Интернету вещей, обеспечивая при этом безопасное и надежное обнаружение устройств и подключение к различным операционным системам и платформам. Существует множество предложений и форумов, продвигающих различные подходы, но ни одно решение не соответствует большинству основных требований. Настоящий стандарт и связанные с ним документы позволяют консолидировать отрасль, используя в качестве основы взаимодействия общеприменимый и безопасный подход.

IV

ГОСТ Р 71437—2024

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

СПЕЦИФИКАЦИЯ ОТКРЫТОГО ВЗАИМОДЕЙСТВИЯ (OCF)

Спецификация служб «устройство—облако»

Information technology. Open connectivity foundation (OCF) specification. Device to cloud services specification

Дата введения — 2024—09—30

1 Область применения

Настоящий стандарт описывает функциональные расширения возможностей архитектуры ядра спецификации открытого взаимодействия (OCF)¹\ интерфейсов, протоколов и служб, позволяющих реализовать профили OCF (см. [1]), для соответствия требованиям облака OCF. В настоящем стандарте описаны новые типы ресурсов, позволяющие использовать функциональные возможности и любые расширения существующих возможностей архитектуры ядра OCF, интерфейсов, протоколов и служб, позволяющих реализовать профили OCF (см. [1]).

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ГОСТ ISO/IEC 17788 Информационные технологии. Облачные вычисления. Общие положения и терминология

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 каталог ресурсов (resoutce directory): Набор описаний ресурсов, где фактические ресурсы хранятся на серверах, внешних по отношению к объекту, на котором размещен каталог ресурсов, что позволяет осуществлять поиск по этим ресурсам.

¹) Спецификация открытого взаимодействия (Open Connectivity Foundation) (далее OCF) — это отраслевая организация, заявленная миссия которой заключается в разработке стандартов спецификаций, продвижении набора функциональной совместимости и в предоставлении программы сертификации устройств, задействованных в Интернете вещей (1оТ).

Издание официальное

1

ГОСТ Р 71437—2024

3.2 облако OCF (OCF cloud): Логический объект, принадлежащий поставщику облачных услуг, который уполномочен обмениваться данными с устройством от имени пользователя облака ОСЕ

3.3 пользователь облака OCF (OCF cloud user): Клиент, имеющий разрешения на взаимодействие с устройствами, доступ к которым осуществляется через облако ОСЕ

3.4 поставщик облачных услуг (cloud provider): Субъект или организация, размещающая на своих мощностях облако ОСЕ

3.5 устройство OCF (OCF device): Устройство, соответствующее спецификации OCF для взаимодействия с облаком ОСЕ

4 Сокращения и обозначения

В настоящем стандарте приведены следующие сокращения и обозначения:

АСЕ2 — запись контроля доступа второго поколения (access control entry 2);

ACL — список управления доступом (access control list);

AMS — служба управления доступом (динамически создает ресурсы ACL в ответ на запрос

ресурса устройства) (access management service);

API — программный интерфейс приложений (application programming interface);

CaaS — обмен информацией как услуга (категория служб облачных вычислений, в которой

потребителю службы облачных вычислений предоставляются следующие возможности: взаимодействие в реальном времени и совместная работа) (communications as a service);

CCRA — эталонная архитектура облачных вычислений (cloud computing reference architecture);

CMS — служба управления учетными данными (credential management service);

CoAP — протокол ограниченных приложений (constrained application protocol);

CoAPs — безопасный (усиленный) протокол CoAP (secure constrained application protocol);

CRUDN — операции манипулирования ресурсами (CREATE, RETRIEVE, UPDATE, DELETE and NOTIFY);

DOTS — служба передачи владения устройством (логический объект, устанавливающий право собственности на устройство) (device ownership transfer service);

FaaS — функция как сервис (категория служб облачных вычислений, в которой потребителю службы облачных вычислений предоставляются возможности вызова экземпляра управляющего кода без необходимости управления серверами и серверным приложением) (function as a service);

IETF — открытое международное сообщество проектировщиков, ученых, сетевых операторов и провайдеров (internet engineering task force);

loT — Интернет вещей (Internet of things);

OBT — инструмент адаптации (инструмент, реализующий функциональные возможности DOTS, AMS и CMS) (onboarding tool);

OpenAPI — формализованная спецификация и экосистема множества инструментов, предоставляющая интерфейс между front-end системами, кодом библиотек низкого уровня и коммерческими решениями в виде API (спецификация построена таким образом, что не зависит от языков программирования, и удобна в использовании как человеком, так и машиной);

RD — каталог ресурсов (resource directory);

SSL — криптографический протокол, который подразумевает более безопасную связь (secure sockets layer);

SVR — ресурс, обеспечивающий функции безопасности (security virtual resource);

TLS — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом (transport layer security);

URI — унифицированный (единообразный) идентификатор ресурса (uniform resource identifier);

URL — унифицированный локатор ресурса (uniform resource locator);

2

ГОСТ Р 71437—2024

UUID — всемирно уникальный идентификатор (universally unique identifier);

OAUTH2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе (протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу).

5 Общие положения

5.1 Облако и устройства OCF

Облако OCF расширяет возможности использования протокола СоАР, позволяя устройству взаимодействовать с облаком, используя протокол СоАР поверх протокола управления передачей (TCP), позволяющего двум хостам создать соединение и обмениваться потоками данных (см. [1]) и с учетом:

- требований настоящего стандарта, включая требования к каталогу ресурсов;

- требований безопасности и SVR (см. [2]).

Устройства, находящиеся вне одной локальной сети, могут взаимодействовать друг с другом через облако OCF с помощью протокола СоАР поверх TCP. В любой момент времени устройство может использовать только одно облако ОСЕ Облако OCF группирует устройства, принадлежащие одному и тому же пользователю облака OCF, используя при этом идентификатор пользователя, созданный в облаке ОСЕ Все устройства, зарегистрированные в облаке OCF и относящиеся к одному и тому же идентификатору пользователя, могут взаимодействовать друг с другом при условии, что устройства авторизовали облако OCF в политиках АСЕ2.

В приложении А приведены определения типов ресурсов с использованием схемы, установленной в спецификации OpenAPI, в качестве языка определения API, которому должно следовать устройство OCF, наделенное соответствующими ресурсами.

Следует обратить внимание на то, что в отличие от устройства OCF облако OCF — это логический объект, принадлежащий поставщику облачных услуг.

Для связи с устройством облако OCF должно быть авторизовано пользователем облака ОСЕ

С целью соответствия принятым в IETF подходам в отношении операций RESTful слова CRUDN, CREATE, RETRIVE, UPDATE, DELETE и NOTIFY содержат только прописные буквы.

Примечание — Эти же слова имеют общепринятое техническое значение.

5.2 Согласование облачной архитектуры OCF с эталонной архитектурой облачных вычислений

Эталонную архитектуру облачных вычислений (CCRA) (см. [3]) можно рассматривать с одной из четырех точек зрения: использования, функциональности, реализации и развертывания.

Архитектура OCF определяет тип облачных служб как приложения, предоставляющего обмен информацией как услугу (CaaS) (см. ГОСТ ISO/IEC 17788). Служба облачных вычислений предоставляется поставщиком облачных услуг, а механизмы, используемые поставщиком облачных услуг для управления своей комплексной облачной инфраструктурой, выходят за рамки определения OCF облачных служб. Определение OCF ограничивается интерфейсами, предлагаемыми облачной службой потребителю, а именно — пользователю служб облачных вычислений.

Определены три различных интерфейса. Если потребителем облачных услуг является устройство OCF, как это предусматривается настоящим стандартом, то возможны следующие варианты:

- интерфейс для устройства OCF для передачи информации облачной службе;

- интерфейс для устройства OCF для получения информации, предоставленной облачной службой;

- интерфейс для другого экземпляра облачной службы для получения и обновления информации, предоставляемой через облачную службу.

Последний вариант подразумевает, что потребитель облачной службы является очередным экземпляром облачной службы, как указано в API-интерфейсе облака OCF для облачных служб.

Службы облачных вычислений OCF предоставляются конкретным пользователям облачных служб, имеющих единственно возможным применимым действием «Использование облачной службы» (см. [3]).

Учетные данные пользователя облачной службы предоставляются с использованием протокола OAUTH2.0 (см. [4]). Служба облачных вычислений выдает токен, который далее следует использовать

3

ГОСТ Р 71437—2024

в каждом запросе от каждого пользователя облака либо непосредственно самой службой облачных вычислений, либо с помощью внешнего сервера авторизации (см. 8.1 и [5]).

Обмен информацией между пользователем облака и облачными службами осуществляется через протокол TLS с взаимной аутентификацией (см. [5]).

5.3 Архитектура облака OCF

Облако OCF — это логический объект, с которым устройство OCF взаимодействует через постоянное TLS-соединение. Облако OCF поддерживает следующие функции:

- функция сервера учетных записей, который представляет собой логический объект, обеспечивающий регистрацию устройства, проверку токена доступа и обработку запросов на вход и обновление токена от устройства. Пользователь облака OCF создает автономную учетную запись на сервере учетных записей (с помощью посредника). Сервер учетных записей также используется для регистрации устройств (клиентов и серверов) для каждой учетной записи. Следует отметить, что все учетные записи полностью изолированы. Например, вход в учетную запись А не дает права доступа к устройствам, зарегистрированным для учетной записи В;

- функция каталога ресурсов. Согласно определению в настоящем стандарте, каталог ресурсов обеспечивает клиента информацией о ресурсах, предоставляемых устройствами. Запрашивая устройство, клиент получает от имени этого устройства ответ от каталога ресурсов. Используя информацию, включенную в ответ из каталога ресурсов, клиент может подключиться к устройству через облако OCF.

Этот процесс показан на рисунке 1.

Сервер ресурсов

Рисунок 1 — Облако OCF

5.4 Обмен информацией с облаком OCF

В данном разделе описывается взаимодействие элементов с облаком OCF в целом. Рисунок 2 дает общее представление, а в таблице 1 представлена дополнительная информация.

Если облако OCF также выступает в качестве сервера авторизации, шаг 1 из таблицы 1 выполняется между посредником и облаком OCF, в этом случае действия 7 не требуется.

4

ГОСТ Р 71437—2024

Рисунок 2 — Модель взаимодействия с облаком OCF

Таблица 1 — Взаимодействие с облаком OCF

5.5 Последовательность операций взаимодействия с облаком

5.5.1 Общие положения

Процессы, которые имеют место при регистрации устройства в облаке OCF и последующем взаимодействии клиента с этим устройством, приведены в 5.5.2—5.5.11.

Последовательность состоит из следующих обобщенных процессов:

- подготовка и создание учетной записи пользователя облака OCF;

- регистрация посредника в облаке OCF;

- подготовка устройства посредником;

- регистрация устройства в облаке OCF;

- подключение устройства к облаку OCF;

- публикация ссылок на каталог ресурсов облака OCF;

- связь между клиентом и сервером через облако OCF;

- обновление соединения устройства с облаком OCF;

- прерывание соединения устройства с облаком OCF;

- отмена регистрации устройства в облаке ОСЕ

5

ГОСТ Р 71437—2024

5.5.2 Подготовка и создание учетной записи пользователя облака OCF

Для получения удаленного доступа к устройству пользователь облака OCF должен подключить устройство к облаку OCF (см. [2]).

Для подготовки устройства пользователь облака OCF использует посредника. Посредник — это логическая функция, которая может выполняться на личном устройстве пользователя облака OCF (например, на телефоне) или где-либо еще. Посредник настраивается с помощью или посредством какого-либо стороннего процесса для получения URL-адреса облака OCF. В частности, посредником может быть приложение поставщика облачных услуг.

Пользователь облака OCF имеет учетные данные для аутентификации пользователя в облаке OCF через сервер авторизации. Учетные данные представляют собой имя пользователя/пароль или аналогичные данные.

5.5.3 Регистрация посредника в облаке OCF

По определенной схеме, например взаимодействуя с пользователем или используя сторонний механизм, посредник аутентифицирует пользователя облака OCF на сервере авторизации и запрашивает у него токен доступа.

Посредник регистрируется, предоставляя токен доступа в облако OCF, которое проверяет токен и создает идентификатор пользователя, с которым связан посредник. Все экземпляры посредника для одного и того же пользователя облака OCF будут связаны с одним и тем же идентификатором пользователя. Точно так же один и тот же идентификатор пользователя может использоваться для назначения нескольких устройств одному и тому же пользователю облака ОСЕ

Более подробно приведено в 8.1.2.2, 8.1.2.3.

5.5.4 Подготовка устройства посредником

Посредник подключается к устройству с помощью обычных процессов ОСЕ Затем посредник запрашивает у облака OCF токен доступа для предоставляемого устройства, обновляет на устройстве ресурс oic.r.coapcloudconf, используя полученный из облака OCF токен доступа, URI облака OCF и UUID облака ОСЕ Посредник может также указать имя сервера авторизации. Следует отметить, что упомянутый токен доступа допускается использовать только один раз для первоначальной регистрации устройства в облаке ОСЕ

Более подробно приведено в 8.1.2.3 (см. также [2], 7.5.2).

5.5.5 Регистрация устройства в облаке OCF

После настройки посредником ресурса oic.r.coapcloudconf устройство устанавливает TLS-соединение с облаком OCF, используя для валидации сертификата облака OCF предоставленный URI и установленные производителем устройства сертификат производителя и сертификат(ы) привязки доверия. Сочетание сертификата производителя устройства и токена доступа пользователя облака OCF гарантирует, что взаимодействие между облаком OCF и устройствами OCF будет происходить в пределах домена пользователя облака ОСЕ

Для регистрации в облаке OCF устройство отправляет запрос на операцию UPDATE учетных записей в облаке OCF, который содержит токен доступа, предоставленный в ресурсе oic.r.coapcloudconf. Необходимо отметить, что облако OCF поддерживает уникальный экземпляр учетной записи для каждого устройства.

Если операция UPDATE успешно подтверждена, то облако OCF направляет ответ на UPDATE, в котором могут содержаться обновленные значения токена доступа и сведения о сроке действия этого токена. Кроме того, облако OCF также хранит идентификатор пользователя, с которым связано устройство. Все возвращаемые значения должны надежно храниться на устройстве. Возвращенный токен доступа в ресурс oic.r.coapcloudconf не записывается.

По окончании этих действий устройство зарегистрировано в облаке ОСЕ

Более подробно приведено в 8.1.3 и 8.1.4 (см. также [2], 10.5, 13.11, 13.12).

5.5.6 Подключение устройства к облаку OCF

Чтобы разрешить обмен информацией между устройством и облаком OCF, устройство отправляет запрос UPDATE в ресурс сеанса. После проверки облако OCF отправляет ответное сообщение, в котором указывается оставшееся время жизни соответствующего токена доступа. После этого устройству доступно активное соединение с возможностью обмена данными.

Подробная информация приведена в 8.1.3, 8.1.4 (см. также [2], 13.12).

5.5.7 Публикация ссылок на каталог ресурсов облака OCF

После установления TLS-соединения с облаком OCF устройство представляет (публикует) ресурсы в каталоге в облаке ОСЕ Они становятся доступными для просмотра или получения удаленного доступа (см. 6.1.3.2, 8.2, а также [2], 10.5).

6

ГОСТ Р 71437—2024

5.5.8 Связь между клиентом и сервером через облако OCF

Для получения доступа к серверу клиенты следуют процедуре, приведенной в 5.5.2, и регистрируются в облаке OCF аналогично.

Облако OCF обеспечивает взаимодействие между всеми устройствами пользователя облака OCF на основе того, что они имеют один и тот же идентификатор пользователя.

Когда клиент предпринимает попытку выполнить действия манипулирования ресурсами (CRUDN) по ссылкам, размещенным в облаке OCF, облако OCF направляет соответствующие запросы на нужное устройство. Устройство отвечает облаку OCF, которое затем передает ответ клиенту. Таким образом, взаимодействие происходит по схеме клиент -> облако OCF -> устройство -> облако OCF -> клиент (см. 8.3, 8.4 и [2], подраздел 10.5).

5.5.9 Обновление соединения с облаком OCF

До или в момент истечения срока действия токена доступа устройство обновляет свой токен, отправляя запрос UPDATE ресурсу обновления токена (см. [2], подраздел 13.13).

5.5.10 Прерывание соединения с облаком OCF

Чтобы выйти из взаимодействия с облаком OCF, устройство отправляет на ресурс сеанса запрос UPDATE со значением false для статуса входа в систему (login). Эта операция не удаляет и не уничтожает какую-либо информацию о регистрации устройства. Устройство может повторно войти в облако OCF в любой момент до истечения срока действия токена доступа (см. [2], подраздел 13.12).

5.5.11 Отмена регистрации в облаке OCF

Для отмены регистрации в облаке OCF устройство отправляет ресурсу учетной записи сообщение запроса DELETE, указывая свой токен доступа. Облако OCF отправляет ответное сообщение, подтверждающее, что регистрация устройства была отменена.

Чтобы повторно подключиться к облаку OCF, устройство должно повторить процедуру, начиная с подготовки посредником (см. 5.5.4).

На рисунке 3 показана машина состояний, которая отражает последовательность операций, представленных в настоящем разделе (см. 8.5 и [2], подраздел 13.10).

7

ГОСТ Р 71437—2024

Рисунок 3 — Машина состояний взаимодействия с облаком OCF

8

ГОСТ Р 71437—2024

6 Ресурсная модель

6.1 Каталог ресурсов облака OCF

6.1.1 Косвенное обнаружение при поиске ресурсов

Косвенное обнаружение — это когда третья сторона, отличная от обнаруживающего устройства и самого обнаруженного устройства, содействует процессу обнаружения. Третья сторона, а именно каталог ресурсов (RD), только предоставляет информацию о ресурсах от имени устройства, но не распоряжается ресурсами на этом устройстве.

На рисунке 4 облако OCF действует как каталог ресурсов для устройств А и D, которые принадлежат одной и той же учетной записи. Устройства А и D публикуют информацию о своих ресурсах в облаке OCF. Устройство С, которое также принадлежит той же учетной записи, что и устройства А и D, может запросить у облака OCF сведения о ресурсах устройств А и D.

Рисунок 4 — Непрямое обнаружение ресурсов через каталог ресурсов

Косвенное обнаружение целесообразно в тех случаях, когда устройства находятся в разных сетях и требуется оптимизация обнаружения или маршрутизации. После того, как ресурсы обнаружены с помощью непрямого обнаружения, после запроса к каталогу ресурсов доступ к ресурсу осуществляется напрямую посредством запроса, отправленного в конечную точку, предоставленную каталогом ресурсов.

6.1.2 Каталог ресурсов

Облако OCF, которое действует как каталог ресурсов (RD), участвует в следующих операциях:

- обнаружение каталога ресурсов (RD discovery) — процедура, с помощью которой устройства обнаруживают каталог ресурсов. В случае облака OCF это является прямым результатом регистрации устройства в облаке OCF;

- публикация ресурсов (Resource publish) — процедуры, с помощью которых устройства публикуют информацию о ресурсах, т. е. ссылки;

- экспозиция ресурсов (Resource exposure) — функция, с помощью которой каталог ресурсов через собственный каталог/oic/res предоставляет ссылки на ресурсы, размещенные на сторонних устройствах.

В каталоге ресурсов используется тип ресурса oic.wk.rd, определенный в таблицах 2 и 3. Облако OCF, которое поддерживает возможность непрямого обнаружения, должно предоставлять в каталоге /oic/res экземпляр типа ресурса oic.wk.rd, чтобы объявить о том, что оно выполняет функции каталога ресурсов. Использование типа ресурса oic.wk.rd ограничено только облаками OCF. Устройства ближайшего сетевого окружения не должны предоставлять тип ресурса oic.wk.rd.

Обнаруживаемый экземпляр oic.wk.rd должен допускать только безопасные соединения, такие как, например, конечная точка OCF со схемами подключения coaps или coaps+tcp. Для публикации ссылок

9

ГОСТ Р 71437—2024

в каталоге ресурсов /oic/res публикующее устройство отправляет в предварительно определенный URL /oic/rd запрос UPDATE со своими ссылками. Ответственность за то, что в каталоге ресурсов опубликованы корректные ссылки, доступные через его ресурс /oic/res, лежит на публикующем устройстве.

Таблица 2 — Определение типа ресурса oic.wk.rd

Таблица 3 — Свойства oic.wk.rd

Чтобы найти ресурсы, размещенные на других устройствах, можно запросить каталог ресурсов через его ресурс /oic/res. Устройство при публикации ресурсов может предоставлять для размещения в каталоге ресурсов как полный, так и частичный перечень своих ресурсов. После публикации каталог ресурсов от имени опубликовавшего устройства отвечает на запросы на использование ресурсов. Следует отметить, что в открытом экземпляре /oic/res присутствуют только устройства, принадлежащие той же учетной записи, что и запрашивающее устройство. В общем случае при запросе ресурсов каталог ресурсов ведет себя точно так же, как любой другой сервер, отвечая на запросы к ресурсу /oic/res.

6.1.3 Операции каталога ресурсов

6.1.3.1 Обнаружение каталога ресурсов

На рисунке 5 устройство, ресурсы которого предполагается использовать совместно, сначала регистрируется в облаке OCF, в котором расположен каталог ресурсов, а затем публикует информацию о ресурсах.

Клиент, который выполняет обнаружение ресурсов через каталог ресурсов облака OCF, осуществляет это посредством одноадресного запроса к каталогу ресурсов. Каталог ресурсов, определенный в настоящем стандарте, не поддерживает использование многоадресных запросов для обнаружения экземпляров каталога ресурсов.

6.1.3.2 Публикация ресурсов

Общие положения

После выбора каталога ресурсов устройство может передать информацию о ресурсах в выбранный каталог ресурсов, т. е. опубликовать ссылки из собственного каталога ресурсов /oic/res в выбранный каталог /oic/res.

Публикующее устройство должно помечать все ресурсы, публикуемые в каталоге ресурсов, как доступные для обнаружения (см. [1], пункт 11.3.2). Минимальный набор ресурсов, которые публикующее устройство должно публиковать, — это обязательные базовые ресурсы /oic/d и /oic/р, а также ресурсы, которые определены как обязательные для данного типа устройства. Помимо этого обязательного набора публикующее устройство может также публиковать и дополнительные ресурсы. Публикующее устройство должно публиковать только те ресурсы, которые имеются в его собственном каталоге ресурсов /oic/res. Публикующее устройство не должно публиковать необнаруживаемые ресурсы или ресурсы, размещенные на каком-либо другом устройстве.

10

ГОСТ Р 71437—2024

Рисунок 5 — Обнаружение каталога ресурсов и запрос ресурсов с использованием каталога ресурсов

Публикующее устройство должно отвечать на запросы на обнаружение собственного ресурса /oic/res только в том случае, если не все его доступные для обнаружения ресурсы опубликованы в каталоге ресурсов.

Публикация — передача информации о ресурсах.

Информация о ресурсе может быть опубликована с помощью запроса UPDATE, отправленного в предварительно определенный URL/oic/rd.

Устройство, на котором размещается ресурс, может публиковать в каталоге ресурсов информацию об этом ресурсе, т. е. ссылку, указывающую на ресурс с помощью запроса UPDATE с такой ссылкой в данных. Опубликованная ссылка должна быть доступна через каталог ресурсов /oic/res.

Если устройство публикует ссылку или ссылки впервые, оно должно отправить запрос UPDATE в ресурс /oic/rd каталога ресурсов. Запрос содержит в данных следующие пары параметр—значение:

- di — его значение должно быть UUID публикующего устройства, т. е. значением di /oic/d.

- links — его значением будет массив публикуемых ссылок. В ссылках может отсутствовать параметр ins, и в этом случае значение каждой ссылке присвоит каталог ресурсов. Предоставленный клиентом параметр ins может быть переопределен каталогом ресурсов, т. е. каталог ресурсов может игнорировать предоставленное ins.

- ttl — его значение определяет время (в секундах), в течение которого каталог ресурсов должен хранить ссылку, опубликованную по запросу публикующего устройства.

Необходимо отметить, что информационное наполнение должно иметь соответствующий формат контента application/vnd.ocf+cbor: {

"di": ⁿe61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "links": [

{

"anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9" "href": "/myLightSwitch", "rt": ["oic.r.switch.binary"] , "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3}, "eps" : [

{"ep": "coaps://[fe80::bld6]:1111", "pri": 2}, {"ep": "coaps://[fe80::bld6] :1122"},

{"ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3} ]

11

ГОСТ Р 71437—2024

}, { "anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "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 }

Первоначальный запрос каталога ресурсов UPDATE может быть удовлетворен или отклонен каталогом ресурсов. Если, например, запрос UPDATE включает в себя какие-либо ссылки, которые не могут быть разрешены, то запрос должен быть отклонен каталогом ресурсов с сообщением об ошибке, например «Неверный запрос». Если запрос удовлетворен, то каталог ресурсов должен отправить обратно на публикующее устройство ответ об успешном выполнении UPDATE. Информационное наполнение ответа должно включать в себя ту же информацию, что и исходный запрос UPDATE, со следующими возможными отличиями:

- для каждой ссылки каталог ресурсов должен включить в ответ параметр ins. Каталог ресурсов должен присвоить параметру ins уникальное значение, однозначно идентифицирующее данную конкретную ссылку в его массиве ссылок. Если публикующее устройство включило значение ins в запрос UPDATE, то каталог ресурсов может использовать его до тех пор, пока оно не будет соответствовать какому-либо существующему значению ins в его массиве ссылок;

- значение параметра ttl должно быть присвоено каталогом ресурсов и включено в ответ. Каталог ресурсов должен использовать значение, указанное в запросе UPDATE, но может также присвоить параметру и меньшее значение, если он не может обеспечить запрошенное значение ttl. По истечении времени, заданного параметром, каталог ресурсов должен удалить ссылки. Чтобы поддерживать ссылку в действительном состоянии, публикующее устройство должно обновить ttl, используя запрос UPDATE.

Каталог ресурсов должен добавлять новые ссылки в /oic/res и предоставлять их в ответ на корректный запрос ресурсов RETRIEV: { "di": ⁿe61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "links": [ { "anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "href": "/myLightSwitch", "rt": [ "oic.r.switch.binary"], "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3}, "eps" : [ {"ep": "coaps://[fe80::bld6]:1111", "pri": 2}, {"ep": "coaps://[fe80::bld6]:1122"}, {"ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3} ] , "ins": 11235 }, { "anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "href": "/myLightBrightness" , "rt": [ "oic.r.brightness"], "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3},

12

ГОСТ Р 71437—2024

"eps" : [

{"ер": "coaps://[[2001:db8:a::123]:2222"}

] , "ins": 112358

}

"ttl": 600

}

6.1.3.3 Экспозиция ресурсов

Гиперссылка /oic/res и извлечение ресурсов

Процесс обнаружения на основе /oic/res для облака OCF не поддерживает использование многоадресной рассылки. Зарегистрированный клиент может обнаружить ресурсы, отправив одноадресное сообщение RETRIEVE в /oic/res. В ответ на запрос RETRIEVE устройству (клиенту) возвращаются только те ресурсы, которые зарегистрированы под той же учетной записью, что и клиент.

Взаимодействие с ресурсами, обнаруженными с помощью каталога ресурсов, осуществляется с использованием тех же механизмов и методов, что и с ресурсами, обнаруженными путем получения ресурсов через /oic/res устройства, на котором эти ресурсы размещаются, например подключением к предоставленной конечной точке и выполнением над ресурсом операций CRUDN.

Ответ /oic/res запрашивающему клиенту включает ссылки с параметром anchor, содержащим идентификатор OCF URI. Этот ответ /oic/res содержит один массив ссылок. Каждая ссылка должна содержать «привязочный» параметр, содержащий OCF URI, где компонент авторизации <devicelD> указывает на устройство, на котором размещен целевой ресурс.

Например, каталог ресурсов может вернуть клиенту следующее.

[

{

"anchor": "Ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49",

"href": "/oic/res",

"rel": "self",

"rt": [ "oic.wk.res"],

"if": ["oic.if.11", "oic.if.baseline"],

"p": {"bm": 3},

"eps": [

{"ep": "coap://[2001:db8:a::bld4]:77777"},

{"ep": "coaps://[2001:db8:a::bld4] : 33333"}

]

{

"anchor": "Ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49",

"href": "/oic/d",

"rt": ["oic.wk.d", "oic.d.fan"],

"if": ["oic.if.r", "oic.if.baseline"],

"p": {"bm": 3},

"eps": [

{"ep": "coap://[2001:db8:a::bld4]:77777"},

{"ep": "coaps://[2001:db8:a::bld4]:33333"}

]

},

{

"anchor": "Ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49",

"href": "/oic/p",

"rt": [ "oic.wk.p"],

"if": ["oic.if.r", "oic.if.baseline"],

"p": {"bm": 3},

"eps": [

{"ep": "coaps://[2001:db8:a::bld4]:33333"}

]

13

ГОСТ Р 71437—2024

{

"anchor": "Ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49" "href": "/oic/rd", "rt": ["oic.wk.rd"], "if": ["oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coaps://[2 001:db8:a::bld4] :33333" } ]

{

"anchor": "Ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49" "href": "/myFanSwitch", "rt": ["oic.r.switch.binary"], "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coaps://[2001:db8:a::bld4]:33333"} ]

{

"anchor": "ocf://dc70373c-le8d-4fb3-962e-017eaa863989" "href": "/oic/d", "rt": ["oic.wk.d", "oic.d.light"], "if": ["oic.if.r", "oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coap://[2001:db8:b::c2e5]:66666"},

{"ep": "coaps://[2001:db8:b: :c2e5] :22222" }

]

},

{

"anchor": "ocf://dc70373c-le8d-4fb3-962e-017eaa863989" "href": "/oic/р", "rt": ["oic.wk.p"], "if": ["oic.if.r", "oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coaps://[2001:db8:b::c2e5]:22222"} ]

},

{

"anchor": "ocf://dc70373c-le8d-4fb3-962e-017eaa863989" "href": "/myLightSwitch", "rt": ["oic.r.switch.binary"], "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coaps://[2001:db8:b::c2e5]:22222"}

]

},

{

"anchor": "ocf://dc70373c-le8d-4fb3-962e-017eaa863989" "href": "/myLightBrightness", "rt": ["oic.r.brightness"], "if": ["oic.if.a", "oic.if.baseline"],

14

ГОСТ Р 71437—2024

"р": {"bm": 3},

"eps": [

{"ер": "coaps://[2001:db8:b::c2e5]:22222"}

]

}

]

6.2 Ресурс CoAPCIoudConf

6.2.1 Общие положения

Ресурс CoAPCIoudConf предоставляет информацию о конфигурации для подключения к облаку OCF. Данный ресурс может быть дополнительно включен в коллекцию Easy Setup (oic.r.easysetup) и таким образом использоваться в процессе простой настройки, как определено в OCF Wi-Fi Easy Setup.

Ресурс CoAPCIoudConf должен предоставлять только безопасные конечные точки (например, CoAPS) (см. [1], раздел 10).

Ресурс CoAPCIoudConf предоставляет информацию о конфигурации для подключения к облаку OCF. Это опциональный обнаруживаемый ресурс, который может быть дополнительно включен в коллекцию Easy Setup (oic.r.easysetup) и использоваться в процессе Easy Setup.

Ресурс CoAPCIoudConf должен показывать только безопасные конечные точки (например, CoAPS) (см. [1], раздел 10).

6.2.2 Определение ресурса

Определение ресурса CoAPCIoudConf приведено в таблице 4.

Таблица 4 — Ресурс CoAPCIoudConf

Определение типа ресурса oic.r.coapcloudconf приведено в таблице 5.

Таблица 5 — Определение типа ресурса oic.r.coapcloudconf

15

ГОСТ Р 71437—2024

Окончание таблицы 5

Если значение параметра dec устанавливается устройством, то его начальным значением должен быть «0» («Без ошибок»).

6.2.3 Состояние облака, управляющее машиной состояний

6.2.3.1 Общие положения

Параметр cps отображает состояние регистрации устройства в облаке OCF. Возможные состояния приведены в таблице 6.

Таблица 6 — Состояния регистрации устройства

На рисунке 6 показан конечный автомат с переходами в зависимости от значения параметра cps.

6.2.3.2 Состояния регистрации

Состояние uninitialized

Устройство не было настроено посредником, не заданы значения параметров cis, sid или at типа ресурса oic.r.coapcloudconf (т. е. текущее значение cis — это неразрешимый URI, а значение sid — это нулевой UUID). Возможно устройство находится в начальном состоянии. Устройство должно перейти в это состояние в результате сброса устройства (клиент с соответствующими привилегиями или настройка ОВТ pstat) в случае, если не заданы предварительные значения параметров настройки. Выполнение операции UPDATE для изменения свойств ресурса CoAPCIoudConf возможно только в состояниях «не инициализировано», «готова к регистрации» или «не удалось» (uninitialized, readytoregister или failed).

16

ГОСТ Р 71437—2024

AnyState

'Сброс устройства

InitialStartState

Устройство не имеет предварительной конфигурации, которую необходимо создать с помощью конфигурации облака

Uninitialzied

Установить д ля сра значение uninitialzied, принять конфигурацию клиента ^

CoAPCIoudConf, сконфигурированный посредником

Устройство предварительно настроено с помощью конфигурации облака

ReadyToRegister

। Установить для cps • _чзначение readytoregister у

Клиент сбрасывает конфигурацию облака

Начать регистрацию устройства, установить TLS-сессию, отправить UPDATE ресурсу /oic/sec/account

Вмешательство пользователя (вне диапазона)

^ Uninitialized ^л

Registering

Произошла ошибка при регистрации

Failed

Установить для сра значение tailed, ^причину см. в dec

Установить для cps значение registering, выполнить .процедуру регистрации

Автоматическое повторение попытки регистрации

Устройство отменяет регистрацию

Завершение с ответом Success Path

Registered

Установить для cps ^значение registered

Рисунок 6 — Конечный автомат состояния регистрации

Состояние readytoregister

Устройство было настроено посредником с заданием значений параметров cis, sid и at типа ресурса oic.r.coapcloudconf, но подключение к облаку OCF отсутствует, и устройство не находится в процессе подключения. Устройство может находиться в данном состоянии изначально. Устройство перейдет в это состояние из состояния uninitialized после того, как посредник настроит значения параметров cis, at и sid в oic.r.coapcloudconf. Устройство перейдет в это состояние в результате сброса устройства (задание клиентом параметра pstat), если заданы предварительные значения параметров настройки.

Состояние registering

Устройство перейдет в состояние registering после инициирования установления TLS-соединения с облаком ОСЕ Устройство должно перейти из состояния registering в состояние registered при получении ответа об успешном запросе UPDATE, отправленного на ресурс /oic/sec/account. Если на запрос UPDATE, отправленный на ресурс /oic/sec/account, получен ответ о неудачном запросе, то устройство должно перейти в состояние failed, если только устройство не повторит попытку регистрации самостоятельно, отправив запрос UPDATE на ресурс /oic/sec/account. В этом случае устройство должно оставаться в состоянии registering (см. 8.1.4).

17

ГОСТ Р 71437—2024

Состояние registered

Устройство завершило регистрацию в облаке OCF, как определено в пункте 8.1.4. Если после этого регистрация устройства отменяется в соответствии с 8.5, то устройство переходит в состояние readytoregister.

Состояние failed

Во время процедуры регистрации устройство получило ответ от облака OCF о неудаче, как определено в 8.1.4, и не пытается автономно выполнить повторную попытку. Устройство может иметь какие-либо сторонние средства или схему вмешательства пользователя, которые для обеспечения возможности повторной попытки позволяют перевести устройство из состояния failed в состояние readytoregister или состояние uninitialized.

Значение параметра dec, если оно доступно, должно содержать конкретную причину сбоя, из-за которого устройство оказалось в состоянии failed.

6.2.4 Обработка ошибок

Параметр dec ресурса CoAPCIoudConf (т. е. oic.r.coapcloudconf) используется для определения характера ошибки, возникшей в процессе настройки облака при попытке подключения к облаку OCF, с использованием информации, заполненной посредником в ресурс CoAPCIoudConf. Это необязательный параметр, но если он предусмотрен реализацией, то его значение устанавливается устройством:

- устройство должно установить значение 1-го параметра dec, если оно получает ответ об ошибке от облака OCF;

- устройство должно установить значение 2-го параметра dec, если происходит сбой подключения к облаку OCF, например, отсутствие ответа, тайм-аут;

- устройство должно установить значение 3-го параметра dec, если ему не удается обновить токен доступа, например, если оно получает ответ об ошибке во время процедуры обновления токена.

7 Сеть и возможности подключения

Между устройством и облаком OCF устанавливается сессия TLS (см. [6]). Сессия устанавливается после настройки устройства, в соответствии с 8.1.2.3.

8 Функциональное взаимодействие

8.1 Включение, подготовка и настройка

8.1.1 Общие положения

На рисунке 7 представлено взаимодействие между различными структурами в процессе регистрации устройства в облаке OCF. Сведения о процессе регистрации устройства в облаке OCF представлены в таблице 7.

8.1.2 Действия посредника

8.1.2.1 Общие положения

Посредник — это специализированная служба, которая используется для предоставления ресурса oic.r.coapcloudconf и обеспечения подключения автономного устройства к облаку OCF. Подробное описание посредника приведено в руководстве по простой настройке OCF Wi-Fi.

Посредник входит в состав ОВТ (инструмент адаптации) и поэтому может быть использован на любом устройстве, на котором внедрен ОВТ. Устройство может обмениваться данными с облаком OCF, если доверенный посредник авторизовал устройство. Устройство и посредник подключаются через DTLS, используя учетные данные из /oic/sec/cred.

В рамках подготовки устройства посредник в предоставляемом устройством ресурсе oic.r.coapcloudconf задает следующую информацию:

- значение URL-адреса облачного интерфейса OCF (cis);

- значение OCF облака OCF (sid) (для проверки подлинности облака);

- токен доступа (at), проверенный облаком OCF;

- необязательное значение: имя поставщика авторизации (арп), через которое был получен токен доступа.

Если в процессе регистрации и аутентификации устройства в облаке OCF возникает ошибка, то посредник, чтобы получить подсказку относительно причины ошибки, может получить значение параметра dec, если оно реализовано на устройстве ресурсом oic.r.coapcloudconf.

18

ГОСТ Р 71437—2024

Рисунок 7 — Регистрация в облаке OCF

Таблица 7 — Процесс регистрации устройства в облаке OCF

8.1.2.2 Авторизация посредником пользователя облака OCF

Посредник использует механизм авторизации пользователя, позволяющий облаку OCF проверять авторизацию пользователя облака OCF и получать идентификационные данные пользователя облака OCF. Поставщику авторизации должны доверять как пользователь облака OCF, так и само облако OCF. Для получения токена доступа в качестве формы авторизации от пользователя облака OCF через поставщика авторизации посредник может использовать OAUTH 2.0 (см. [4]) или другой механизм аутентификации пользователя. Такая авторизация преследует различные цели.

Во-первых, авторизация показывает согласие пользователя облака OCF на подключение посредника к облаку OCF. Во-вторых, авторизация используется для получения информации для привязки устройств к конкретному пользователю облака ОСЕ

Механизм авторизации пользователей используется для достижения следующих целей:

- получение токена доступа, подтвержденного облаком OCF;

- авторизация пользователя облака OCF через поставщика авторизации, что означает согласие на подключение к облаку ОСЕ

Если пользователь облака OCF использует еще и другого посредника, то возможно получение нового токена доступа от поставщика авторизации.

Чтобы установить TLS-соединение, посредник подключается к облаку OCF, используя предоставленный посредником сертификат.

При первом подключении посредник начинает процесс регистрации в облаке ОСЕ Для регистрации в облаке OCF посредник предоставляет облаку OCF токен доступа посредника, полученный от поставщика авторизации.

19

ГОСТ Р 71437—2024

Затем облако OCF проверяет токен доступа у поставщика авторизации. Если поставщик авторизации успешно подтверждает токен доступа, то он возвращает информацию о пользователе облаку OCF, которому принадлежит токен доступа. Облако OCF генерирует уникальный токен доступа для посредника, который может быть как исходным токеном доступа от посредника, так и новым токеном доступа, и в таком случае при регистрации посредником этого пользователя облака OCF ему присваивается идентификатор пользователя (параметр uid ресурса oic.r.account). Идентификатор пользователя используется в дальнейшем в качестве уникальных идентификационных данных пользователя облака OCF. Все экземпляры посредника для одного и того же пользователя облака OCF будут связаны с одним и тем же идентификатором пользователя. Эта информация возвращается посреднику через TLS-соединение. Возвращенные токен доступа и идентификатор пользователя используются облаком OCF для идентификации посредника. В последующих взаимодействиях с облаком OCF посредник будет использовать именно этот возвращенный токен доступа.

При регистрации через одного и того же посредника все регистрируемые в облаке OCF устройства получают от облака OCF один и тот же идентификатор пользователя.

8.1.2.3 Подготовка устройства посредником

До начала взаимодействия посредника с облаком OCF для предварительной регистрации устройства в облаке OCF посредник проходит процедуру идентификации (см. 8.1.2.2), после успешного прохождения которой посредник может запросить облако OCF связать устройства OCF с этим идентификатором пользователя. Чтобы зарегистрировать устройство в облаке OCF, посредник сначала запрашивает из облака OCF токен доступа для устройства. Для получения токена доступа для устройства посредник может предоставить облаку OCF UUID устройства, т. е. значение параметра di /oic/d устройства.

Затем облако OCF возвращает уникальный для устройства токен доступа. Облако OCF хранит таблицу соответствия предоставленных посредником токенов доступа и UUID устройств. Во время регистрации устройства облако OCF проверяет токен доступа и устанавливает сеанс TLS с устройством с соответствующим UUID. Если токен доступа для устройства был создан не облаком OCF, то облако OCF также может возвращать имя поставщика авторизации, связанное с токеном доступа.

Посредник передает этот токен доступа устройству (параметр at) посредством запроса UPDATE для обновления ресурса устройства oic.r.coapcloudconf (см. рисунок 8). Предоставленный токен доступа должен рассматриваться устройством как токен доступа типа Bearer, как это определено в [7]. Кроме того, посредник также передает URI облака OCF (параметр cis), который может быть либо настроен предварительно, либо предоставлен посреднику пользователем облака OCF. Затем для идентификации облака OCF посредник передает UUD облака OCF (параметр sid). Если облако OCF вместе с токеном доступа для устройства также вернуло имя поставщика, то оно тоже передается посредником на устройство (параметр apn oic.r.coapcloudconf).

Подробная информация о заполнении записей АСЕ2 на устройстве для разрешения получения запроса CRUDN от посредника и облака OCF приведена в [2], пункт 7.5.2.

В таблице 8 приведена более подробная информация, связанная с процессом.

Более подробная информация по сопоставлению свойств между устройством и облаком OCF приведена в [2], пункт 7.5.2.

8.1.3 Подключение устройства к облаку OCF

По завершении подготовки устройства (см. 8.1.2.3) и после перехода устройства в состояние RFNOP (если только оно еще не находится в RFNOP) устройство должно установить TLS-соединение с облаком OCF (см. [2], раздел 10).

посредник

Установлено безопасное соединение между посредником и устройством 1

11 UPDATE (ОБНОВИТЬ) /exampte/coapdoudconf (at: <ACCESS_TOKEN>, apn: <AUTH_PROVIDER>, ds: <SERVER_URL>, i

; sid:<OCF CLOUD UUID»}

] 2 Ответ UPDATE[

I I

Посредник! I CTBO I

Рисунок 8 — Подготовка устройства посредником

20

Таблица 8 — Подготовка устройства посредником

ГОСТ Р 71437—2024

Если аутентификация для установления сеанса TLS не была успешной, то параметр dec ресурса oic.r.coapcloudconf на устройстве и если это поддерживается устройством должно быть обновлено в соответствии со сбоем. Если аутентификация прошла успешно, то устройство и облако OCF устанавливают зашифрованное соединение в соответствии с согласованным набором шифров. Кроме того, если TLS-соединение потеряно из-за сбоя, параметр dec ресурса oic.r.coapcloudconf на устройстве, если это поддерживается устройством, должно быть обновлено до значения состояния сбоя (значение «2»).

Если TLS-соединение потеряно из-за сбоя или закрыто облаком OCF, то оно может быть восстановлено посредством выполнения процедур аутентификации (см. [2], раздел 10). Устройство может попытаться восстановить TLS-соединение автоматически, либо для повторной попытки установления TLS-соединения устройству может потребоваться какое-либо действие пользователя.

8.1.4 Регистрация устройства в облаке OCF

Облако OCF хранит и обновляет таблицу идентификаторов пользователей (параметр uid ресурса oic.r.account), UUID устройств (параметр di ресурса oic.r.account) и токенов доступа (параметр accesstoken ресурса oic.r.account). Последний параметр для аутентификации устройств, подключающихся к облаку OCF, получает то же значение, что и параметр at, полученный из oic.r.coapcloudconf.

После того, как TLS-соединение с облаком OCF установлено, устройство должно зарегистрироваться в облаке OCF, отправив запрос UPDATE в /oic/sec/account в соответствии с определенной ролью ресурса безопасности (см. [2], подраздел 13.10). Облако OCF последовательно связывает TLS-соединение с соответствующими параметрами uid и di, указанными в ресурсе /oic/sec/account/. При регистрации через любого посредника, связанного с этим идентификатором пользователя, другому устройству, регистрирующемуся в облаке OCF, назначается тот же идентификатор пользователя в облаке OCF. Регистрация устройства позволяет клиенту получать доступ к тем ресурсам в облаке OCF, которые ассоциированы с идентификатором пользователя, совпадающим с идентификатором пользователя клиента.

Если значения параметров в запросе UPDATE для /oic/sec/account не соответствуют значениям параметров, предоставленным посреднику облаком OCF, облако OCF должно закрыть TLS-соединение с устройством. Следует учитывать, что облако OCF может также выполнять дополнительные действия, например отправить электронное письмо пользователю облака OCF для дополнительной проверки при регистрации устройства.

Если запрос UPDATE принят облаком OCF, то ответ облака OCF будет в соответствии с ролью ресурса (см. [2], подраздел 13.10).

Значение параметра accesstoken, возвращаемое в ответе на запрос UPDATE, может быть действительным в течение ограниченного периода времени. В этом случае устройство может использовать ресурс /oic/sec/tokenrefresh для обновления токена доступа до истечения срока действия токена доступа, который определяется значением параметра expiresin.

По завершении регистрации устройства оно должно отправить запрос UPDATE в /oic/sec/session (см. [2], подраздел 13.11), чтобы обеспечить поддержание установленной TLS-сессии для последующего взаимодействия с каталогом ресурсов облака OCF, в соответствии с 8.2.

8.2 Публикация ресурсов

Облако OCF предоставляет каталог ресурсов, как это определено в 6.1. После регистрации устройства в облаке OCF устройство должно опубликовать свои ресурсы в каталоге ресурсов облака OCF в соответствии с вышеопределенными процедурами. Устройство и облако OCF поддерживают постоянное TLS-соединение, по которому передаются запросы устройства к облаку ОСЕ

Облако OCF обеспечивает внутреннюю связь между опубликованной информацией о конечной точке устройства и информацией о конечной точке, которую оно (облако OCF) предоставляет в ссылках в каталоге ресурсов облака ОСЕ Конечная точка, предоставляемая облаком OCF для каждого из опубликованных в нем ресурсов, принадлежит самому облаку OCF, а не публикующему устройству. Эти конечные точки используют схему coaps+tcp. Ссылки в каталоге ресурсов облака OCF идентифицируются

21

ГОСТ Р 71437—2024

только по учетной записи пользователя облака OCF (идентификатор пользователя). Например, зарегистрированные ссылки возвращаются клиенту исключительно с тем же идентификатором пользователя и не возвращаются какому-либо другому клиенту с другим идентификатором пользователя.

Некоторая неоднозначность возможна, когда разные экземпляры устройств от одного и того же поставщика публикуют свои ресурсы (например, несколько источников света). Эта ситуация связана с тем, что локальный параметр ссылки href, предоставляемый каталогом ресурсов, скорее всего, будет одинаковым в каждом из этих случаев. Чтобы избежать этой неоднозначности, каталог ресурсов должен добавлять в начало публикуемой ссылки href UUID публикующего устройства. Таким образом, для любого запроса, полученного облаком OCF, будет получен уникальный URI опубликованного ресурса.

На рисунке 9 приведен пример, представленного устройством UUID-идентификатора.

Устройство

Каталог ресурсов облака OCF

Идентификатор устройства:

88Ь7-с71 0-4Ь51 -4e0a-9faa-cfb429fd7f49

• POST/oic/rd

* ["links": [{"anchor”: ^Hocf://88b7-c7f0-4b51-4e0a-9faa-cfb429fd7f49",

' ¹ "href”:7myLightSwitch", "rt":["oic.r.switch.binary'!, "if:["oic.if.a","oic.if.baseline'], ; "p": Cbm": 3}, "eps": [fap': "coaps://[fe80::M dq:22222"}]}]

•----------------------------------------------------------------------->

i^,2 Ответ Success

Рисунок 9 — Публикация ресурсов в облаке OCF

8.3 Регистрация клиента в облаке OCF

Регистрируясь в облаке OCF, выступающее в роли клиента устройство выполняет те же процедуры, что и устройство, выступающее в роли сервера. Такой клиент связан с идентификатором пользователя таким же образом, как и сервер связан с тем же идентификатором пользователя.

8.4 Обнаружение ресурсов

Чтобы обнаружить ресурсы, опубликованные в облаке OCF, удаленное устройство может запросить ресурс /oic/res. Каталог ресурсов облака OCF отвечает ссылками на ресурсы, опубликованные в облаке OCF устройствами, которые зарегистрированы в облаке OCF с тем же идентификатором пользователя, что и удаленное устройство. Параметр ссылки eps в ответе /oic/res предназначен для облака OCF, а не для публикующего устройства.

На рисунке 10 показан процесс обнаружения ресурсов. Следует обратить внимание на то, что при заполнении href (в данном случае oic.r.switch.binary) в соответствии с 8.2 добавляется UUID целевого устройства.

Облако OCF действует как простой прокси-сервер, пересылая сообщения на публикующие устройства. Удаленное устройство отправляет запрос RETRIEVE в облако OCF для получения содержимого опубликованных ресурсов сервера. Облако OCF направляет сообщение на целевое устройство после предварительного удаления UUID устройства, который был добавлен к параметру ссылки href каталогом ресурсов облака ОСЕ Таким образом и другие запросы CRUDN, инициированные клиентом, перенаправляются на сервер через облако ОСЕ Публикующее устройство обрабатывает перенаправленный запрос как запрос от облака ОСЕ Публикующее устройство авторизует запрос (см. [2]), используя UUID облака OCF, заданный в параметре sid ресурса oic.r.coapcloudconf. Публикующее устройство отправляет ответное сообщение в облако OCF, а облако OCF пересылает ответ клиенту, отправившему соответствующий запрос. На рисунке 11 показана маршрутизация запросов через облако ОСЕ

Если облако OCF по какой-либо причине не может направить запрос клиента на сервер, оно может отклонить запрос с соответствующим ответом (например, Service Unavailable).

22

ГОСТ Р 71437—2024

Клиент

Каталог ресурсов облака OCF

' 1 RETRIEVE /nic/res?rt=oic. г. switch, binary

2 Найти ресурс

Рисунок 10 — Обнаружение ресурсов через облако OCF

8.5 Отмена регистрации устройства в облаке OCF

Чтобы отменить регистрацию в облаке OCF, устройство отправляет запрос DELETE на ресурс /oic/ sec/account (см. [2], подраздел 13.11).

После завершения отмены регистрации устройства облако OCF удаляет ссылки на отмененное устройство из каталога ресурсов облака OCF.

8.6 Управление устройствами

8.6.1 Порядок действий при изменении состояния устройства

Действия при переходе состояний устройства описаны в [2]. В настоящем разделе определены действия, необходимые для функциональности, определенной в настоящем стандарте.

В таблице 9 представлено краткое описание необходимых действий.

При аппаратном сбросе устройство, если оно зарегистрировано в облаке OCF, должно отменить регистрацию в облаке OCF в соответствии с процедурами ресурсов безопасности (см. [2], подраздел 13.10).

Кроме того, при аппаратном сбросе ресурс CoAPCIoudConf (oic.r.coapcloudconf) должен быть изменен в соответствии с таблицей 10 для тех параметров, которые включены в реализацию.

23

ГОСТ Р 71437—2024

Клиент

Облако OCF

Целевое устройство

Идентификатор устройства: ^8b7-c7«MbfH4e0a4^

11 UPDATE 88b7-c7f0-4b51-4e0a-9faa-cfb429fti7f49/myiJghtSwitctirstate' : true}

2 Внутренний запрос на проверку и подтверждение привилегий

Рисунок 11 — Маршрутизация запросов через облако OCF

Таблица 9 — Действия при изменении состояния устройства

Таблица 10 — Значения по умолчанию для ресурса CoAPCIoudConf

24

ГОСТ Р 71437—2024

Приложение А (справочное)

Определения ресурсов Swagger 2.0

А.1 Перечень определений типов ресурсов

Перечень ресурсов, определенных в настоящем стандарте, приведен в таблице А.1.

Таблица А.1—Перечень ресурсов

А.2 Каталог ресурсов

А.2.1 Введение

Ресурс, который будет доступен любому устройству, которое может выступать в качестве каталога ресурсов. Ресурс каталога ресурсов:

а) предоставляет критерии выбора (например, целое число) с помощью запроса GET;

б) по запросу POST публикует ссылку в /oic/res.

А.2.2 Общеизвестный URI

/oic/rd

А.2.3 Тип ресурса

Заданный тип ресурса: oic.wk.rd.

А.2.4 Определение OpenAPI 2.0

{

"swagger": "2.0 ", "info": {

"title": "Resource directory resource",

"version": "2019-02-22", "license": {

"name": "OCF Data Model License", "url":

"https://github.com/openconnectivitуfoundation/coгe/Ъ1ob/e2 8 a9e 0 a92e17 0 4 2ba3e83661e4c0 fbce8bdc4ba/ LICENSE.md",

"x-copyright": "Copyright 2016-2019 Open Connectivity Foundation, Inc. All rights reserved." }, "termsOfService": "https://openconnectivityfoundation.github.io/core/DISCLAIMER.md" }, "schemes": ["http"], "consumes": ["application/j son"], "produces": ["application/j son"], "paths": { "/oic/rd" : { "get": {

"description": "Resource to be exposed by any Device that can act as a

Resource Directory.\nl) Provides selector criteria (e.g., integer) with GET request\n2) Publish a Link in /oic/res with POST request\n", "parameters": [ {"$ref": "#/parameters/rdgetinterface"} ] , "responses": { "200": {

"description" : "Respond with the selector criteria — either the set of attributes or the bias factor\n", "x-example": {

"rt": ["oic.wk.rd"],

"if": ["oic.if.baseline"],

25

ГОСТ Р 71437—2024

"sei": 50

}, "schema": { "$ref": "#/definitions/rdSelection" }

"post": {

"description": "Publish the Resource information for the first time in /oic/ res. Updates to existing entries are not allowed.\nAppropriates parts of the information, i.e.. Links of the published Resources will be discovered through /oic/res.\nl) When a Device first publishes a Link, the request payload to RD may include the Links without an \"ins\" Parameter.\n2) Upon granting the request, the RD assigns a unique instance value identifying the Link among all the Links it advertises\n and sends back the instance value in the \"ins\" Parameter in the Link to the publishing Device.\n", "parameters": [

{"$ref": "#/parameters/rdpostinterface"}, { "name": "body", "in": "body", "required": true, "schema": { "$ref": "#/definitions/rdPublish" }, "x-example": {

"di": "e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "links": [ {

"anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "href": "/myLightSwitch", "rt": [ "oic.r.switch.binary" ], "if": [ "oic.if.a", "oic.if.baseline" ], "p": { "bm": 3 }, "eps": [

{ "ep": "coaps://[2001:db8:a::bld6]:1111", "pri": 2 },

{ "ep": "coaps://[2001:db8:a::bld6]:1122” },

{ "ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3 } ] }, {

"anchor": "Ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9",

"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

] ,

"responses": {

"200": {

"description" : "Respond with the same schema as publish with the additional \"ins\" Parameter in the Link.\n",

"x-example": {

"di": "e61c3e6b-9c54-4b81-8ce5-f9039cld04d9",

"links": [ {

"anchor": "ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9",

"href": "/myLightSwitch",

"rt": [ "oic.r.switch.binary" ],

26

ГОСТ Р 71437—2024

"if": [ "oic.if.a", "oic.if.baseline" ], "p": { "bm": 3 }, "eps": [

{ "ep": "coaps://[2001:db8:a::bld6]:1111", "pri": 2 }, { "ep": "coaps://[2001:db8:a::bld6]:1122" },

{ "ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3 } ] , "ins": 11235

{

"anchor": "ocf://e61c3e6b-9c54-4b81-8ce5-f9039cld04d9", "href": "/myLightBrightness", "rt": ["oic.r.brightness"], "if": ["oic.if.a", "oic.if.baseline"], "p": {"bm": 3}, "eps": [

{"ep": "coaps://[2001:db8:a::123]:2222"} ] , "ins": 112358 }

"ttl": 600 }, "schema": { "$ref": "#/definitions/rdPublish" } } } } } }, "parameters": { "rdgetinterface" : { "in" : "query", "name" : "if", "type" : "string", "enum" : ["oic.if.baseline"] }, "rdpostinterface" : { "in" : "query", "name" : "if", "type" : "string", "enum" : ["oic.if.baseline"] } }, "definitions" : { "rdSelection" : { "properties": { "rt" : {

"description": "Resource Type of the Resource", "items": { "enum": ["oic.wk.rd"], "type": "string", "maxLength": 64 }, "minitems": 1, "uniqueitems": true, "readonly": true, "type": "array" }, "n" : { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common. properties.core- schema.json#/definitions/n"

27

ГОСТ Р 71437—2024

"sei" : { "description": "A bias factor calculated by the Resource Directory", "maximum": 100, "minimum": 0, "readonly": true, "type": "integer" }, "id" : { "$ref" : "https://openconnectivityfoundation.github.io/core/schemas/oic.common. properties.core- schema.json#/definitions/id" }, "if" : {

"description": "The OCF Interfaces supported by this Resource", "items": { "enum": [ "oic.if.baseline" "type": "string", "maxLength": 64 }, "minitems": 1, "readonly": true, "uniqueitems": true, "type": "array" } }, "type" : "object", "required": ["sei"] }, "rdPublish" : { "properties": { "di" : {

"$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.json#/definitions/di"

}, "ttl" : {

"description": "Time to indicate a RD, i.e. how long to keep this published item, "type": "integer" }, "links" : {

"description": "A set of simple or individual OCF Links.", "items": { "properties": { "anchor": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.json#/definitions/anchor" "di": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.json#/definitions/di" }, "eps": { "$ref":

"https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.json#/definitions/eps" }, "href": {

"$ref":

28

ГОСТ Р 71437—2024

"https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.j son #/definitions/href" }, "if": {

"description": "The interface set supported by the published resource", "items": { "enum": [ "oic.if.baseline", "oic.if.11", "oic.if.b", "oic.if.rw", "oic.if.r", "oic.if.a", "oic.if.s" ] , "type": "string", "maxLength": 64 }, "minitems": 1, "uniqueitems": true, "type": "array" "ins": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.j son #/definitions/ins" }, "p": {

"$ref":

"https://openconnectivityfoundation.github.io/core/schemas/oic.links. properties.core- schema.json#/definitions/p" }, "rel": {

"description": "The relation of the target URI referenced by the Link to the context URI", "oneOf": [ { "default": [ "hosts" ] , "items": {

"maxLength": 64, "type": "string" }, "minitems": 1, "type": "array" }, { "default": "hosts", "maxLength": 64, "type": "string" } ] }, "rt": { "description": "Resource Type of the published Resource", "items": { "maxLength": 64, "type": "string"

"minitems": 1, "maxitems": 1,

29

ГОСТ Р 71437—2024

"uniqueitems": true, "type": "array"

}, "title": {

"$ref":

"https://openconnectivityfoundation.github.io/core/schemas/oic. links.properties.core- schema.json#/definitions/title"

"type": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.

links.properties.core- schema.json#/definitions/type" }

}, "required": [ "href", "rt", "if"

] ,

"type": "object"

"type": "array" }

},

"type" : "object",

"required": ["di", "links", "ttl"]

}

}

}

A.2.5 Определение параметров

В таблице A.2 определены параметры ресурса типа oic.wk.rd.

Таблица А.2 — Параметры ресурса типа rt = oic.wk.rd

30

ГОСТ Р 71437—2024

А.2.6 Запросы CRUDN

В таблице А.З определены операции CRUDN, которые поддерживаются для ресурса типа oic.wk.rd.

Таблица А.З — CRUDN-операции Ресурса с типом rt = oic.wk.rd

А.З Ресурс конфигурации СоАР облака

А.3.1 Введение

Ресурс CoAPCIoudConf предоставляет информацию о конфигурации для подключения к облаку OCF.

А.3.2 Пример URI

/CoAPCIoudConfResURI

А.3.3 Тип ресурса

Тип ресурса: oic.r.coapcloudconf.

А.3.4 Определение OpenAPI 2.0 { "swagger": "2.0", "info": {

"title": "CoAP Cloud Configuration Resource",

"version": "20190327", "license" : {

"name": "OCF Data Model License",

"url":

"https://github.com/openconnectivityfoundation/core/blob/e28a9e0a92e17042ba3e8366 le4c0fbce8bdc4ba/LICEN SE.md",

"x-copyright": "Copyright 2018-2019 Open Connectivity Foundation, Inc. All rights reserved." },

"termsOfService": "https://openconnectivityfoundation.github.io/core/DISCLAIMER.md" }, "schemes": ["http"], "consumes": ["application/j son"], "produces": ["application/json"], "paths": {

"/CoAPCIoudConfResURI?if=oic.if.rw" : {

"get": {

"description": "The CoAPCIoudConf Resource exposes configuration information for connecting to an OCF Cloud.\n", "parameters": [

{"$ref": "#/parameters/interface-all" } ] , "responses": {

"200": {

"description" : "",

"x-example":

{

"rt" : ["oic.r.coapcloudconf"],

"apn": "github",

"cis": "coaps+tcp://example.com:443",

"sid" : "987e6543-a21f-10dl-all2-421345746237", "dec": 0

},

"schema": { "$ref": "#/definitions/CoAPCloudConf" } } } }, "post": {

"description": "Update properties of the CoAPCIoudConf Resource.\n", "parameters": [

{"$ref": "#/parameters/interface-all"}, {

"name": "body",

31

ГОСТ Р 71437—2024

"in": "body", "required": true, "schema": { "$ref": "#/definitions/CoAPCloudConfUpdate" }, "x-example": {

"at": "0f3d9f7fe5491d54077d", "apn": "github", "cis": "coaps+tcp://example.com:443", "sid" : "987e6543-a21f-10dl-all2-421345746237" } } ] , "responses": { "200": { "description" : "", "x-example": { "apn": "github", "cis": "coaps+tcp://example.com:443", "sid" : "987e6543-a21f-10dl-all2-421345746237", "dec": 0 "schema": { "$ref": "#/definitions/CoAPCloudConf" } } } } }, "/CoAPCloudConfResURI?if=oic.if.baseline" : { "get": {

"description": "The CoAPCloudConf Resource exposes configuration information for connecting to an OCF Cloud.\n", "parameters": [ ("$ref": "#/parameters/interface-all"} ] , "responses": { "200": { "description" : "", "x-example": { "rt": ["oic.r.coapcloudconf"], "if" : ["oic.if.rw","oic.if.baseline"], "apn": "github", "cis": "coaps+tcp://example.com:443", "sid" : "987e6543-a21f-10dl-all2-421345746237", "dec": 0 "schema": { "$ref": "#/definitions/CoAPCloudConf" } } }

"post": { "description": "Update Properties of the CoAPCloudConf Resource.\n", "parameters": [ {"$ref": "#/parameters/interface-all"}, {

"name": "body", "in": "body", "required": true, "schema": { "$ref": "#/definitions/CoAPCloudConfUpdate" }, "x-example": { "at": "0f3d9f7fe5491d54077d", "apn": "github",

32

ГОСТ Р 71437—2024

"cis": "coaps+tcp://example.com:443", "sid" : "987e6543-a21f-10dl-all2-421345746237"

}

}

] ,

"responses": {

"200": {

"description" : "",

"x-example":

{

"apn": "github",

"cis": "coaps+ tcp://example.com:4 4 3",

"sid" : "987e6543-a21f-10dl-all2-421345746237",

"dec": 0

"schema": { "$ref": "#/definitions/CoAPCloudConf" } }

"parameters": { "interface-all" : { "in" : "query", "name" : "if", "type" : "string", "enum" : ["oic.if.rw","oic.if.baseline"] }

}, "definitions" : { "CoAPCIoudConf" : { "properties": { "rt" : {

"description": "Resource Type of the Resource", "items": { "enum": ["oic.r.coapcloudconf"], "type": "string", "maxLength": 64 }, "minitems": 1, "uniqueitems": true, "readonly": true, "type": "array" }, "n" : { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common. properties.core- schema.json#/definitions/n" }, "cis" : {

"description": "URL of OCF Cloud", "format": "uri", "type": "string" }, "apn" : {

"description": "The Authorisation Provider through which an Access Token was obtained.", "type": "string" }, "sid" : {

"$ref": "http://openconnectivityfoundation.github.io/core/schemas/oic.types-schema.j son#/definitions/uuid"

},

33

ГОСТ Р 71437—2024

"dec" : {

"description": "Last Error Code during Cloud Provisioning (0: No Error, 1: Error response from the OCF Cloud, 2: Failed to connect to the OCF Cloud, 3: Failed to refresh Access Token, 4~254: Reserved, 255: Unknown error)", "enum": [ 0, 1, 2, 3, 255 ] , "readonly": true }, "id" : { "$ref":

"https://openconnectivityfoundation.github.io/core/schemas/oic.common. properties.core- schema.json#/definitions/id" }, "if" : {

"description": "The OCF Interfaces supported by this Resource", "items": { "enum": [ "oic.if.rw", "oic.if.baseline" ] , "type": "string", "maxLength": 64 }, "minitems": 2, "uniqueitems": true, "readonly": true, "type": "array" } }, "type" : "object", "required":["cis", "sid"] }, "CoAPCloudConfUpdate" : { "properties": { "cis" : { "description": "URL of OCF Cloud", "format": "uri", "type": "string" }, "apn" : {

"description": "The Authorisation Provider through which an Access Token was obtained.", "type": "string" }, "at" : {

"description": "Access Token which is returned by an Authorisation Provider or OCF Cloud.", "type": "string" "sid" : {

"$ref": "http://openconnectivityfoundation.github.io/core/schemas/oic.types-schema.j son#/definitions/uuid" } }, "type" : "object", "required":["cis", "at", "sid"] }

} }

34

ГОСТ Р 71437—2024

А.З.5 Определение параметров

В таблице А.4 приведены параметры ресурса типа oic.r.coapcloudconf.

Таблица А.4 — Определения параметров ресурса типа rt = oic.r.coapcloudconf

А.З.6 Запросы CRUDN

Операции CRUDN, которые поддерживаются для ресурса типа oic.r.coapcloudconf, определены в таблице А.5.

Таблица А.5 — Операции CRUDN для ресурса типа rt = oic.r.coapcloudconf

35

ГОСТ Р 71437—2024

Библиография

[1] ИСО/МЭК 30118-1:2021

Информационные технологии. Спецификация OCF (Организация для разработки открытых стандартов в области Интернета вещей). Часть 1. Базовая спецификация

[5] Безопасность облака OCF Организации для разработки открытых стандартов в области Интернета вещей, версия 2.2.0

[6] IETF RFC 8323 Система авторизации: использование токена на предъявителя OAuth 2.0

[7] IETF RFC 6750 Платформа авторизации OAuth 2.0: Использование токена на предъявителя

УДК 006.034:004.056.5:006.354 ОКС 35.200

Ключевые слова: спецификация OCF, спецификация служб «устройство—облако» общие технологии, Интернет вещей

Редактор Е.В. Якубова

Технический редактор И.Е. Черепкова

Корректор М.И. Першина

Компьютерная верстка Е.О. Асташина

Сдано в набор 11.06.2024. Подписано в печать 19.06.2024. Формат 60*84%. Гарнитура Ариал.

Усл. печ. л. 4,65. Уч.-изд. л. 3,72.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «Институт стандартизации» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.