5.5.1 Общие положения
Процессы, которые имеют место при регистрации устройства в облаке OCF и последующем взаимодействии клиента с этим устройством, приведены в 5.5.2 - 5.5.11.
Последовательность состоит из следующих обобщенных процессов:
- подготовка и создание учетной записи пользователя облака OCF;
- публикация ссылок на каталог ресурсов облака OCF;
- связь между клиентом и сервером через облако OCF;
Для получения удаленного доступа к устройству пользователь облака OCF должен подключить устройство к облаку OCF (см. [2]).
Для подготовки устройства пользователь облака OCF использует посредника. Посредник - это логическая функция, которая может выполняться на личном устройстве пользователя облака OCF (например, на телефоне) или где-либо еще. Посредник настраивается с помощью или посредством какого-либо стороннего процесса для получения URL-адреса облака OCF. В частности, посредником может быть приложение поставщика облачных услуг.
Пользователь облака OCF имеет учетные данные для аутентификации пользователя в облаке OCF через сервер авторизации. Учетные данные представляют собой имя пользователя/пароль или аналогичные данные.
По определенной схеме, например взаимодействуя с пользователем или используя сторонний механизм, посредник аутентифицирует пользователя облака OCF на сервере авторизации и запрашивает у него токен доступа.
Посредник регистрируется, предоставляя токен доступа в облако OCF, которое проверяет токен и создает идентификатор пользователя, с которым связан посредник. Все экземпляры посредника для одного и того же пользователя облака OCF будут связаны с одним и тем же идентификатором пользователя. Точно так же один и тот же идентификатор пользователя может использоваться для назначения нескольких устройств одному и тому же пользователю облака OCF.
Посредник подключается к устройству с помощью обычных процессов OCF. Затем посредник запрашивает у облака OCF токен доступа для предоставляемого устройства, обновляет на устройстве ресурс oic.r.coapcloudconf, используя полученный из облака OCF токен доступа, URI облака OCF и UUID облака OCF. Посредник может также указать имя сервера авторизации. Следует отметить, что упомянутый токен доступа допускается использовать только один раз для первоначальной регистрации устройства в облаке OCF.
После настройки посредником ресурса oic.r.coapcloudconf устройство устанавливает TLS-соединение с облаком OCF, используя для валидации сертификата облака OCF предоставленный URI и установленные производителем устройства сертификат производителя и сертификат(ы) привязки доверия. Сочетание сертификата производителя устройства и токена доступа пользователя облака OCF гарантирует, что взаимодействие между облаком OCF и устройствами OCF будет происходить в пределах домена пользователя облака OCF.
Для регистрации в облаке OCF устройство отправляет запрос на операцию UPDATE учетных записей в облаке OCF, который содержит токен доступа, предоставленный в ресурсе oic.r.coapcloudconf. Необходимо отметить, что облако OCF поддерживает уникальный экземпляр учетной записи для каждого устройства.
Если операция UPDATE успешно подтверждена, то облако OCF направляет ответ на UPDATE, в котором могут содержаться обновленные значения токена доступа и сведения о сроке действия этого токена. Кроме того, облако OCF также хранит идентификатор пользователя, с которым связано устройство. Все возвращаемые значения должны надежно храниться на устройстве. Возвращенный токен доступа в ресурс oic.r.coapcloudconf не записывается.
По окончании этих действий устройство зарегистрировано в облаке OCF.
Чтобы разрешить обмен информацией между устройством и облаком OCF, устройство отправляет запрос UPDATE в ресурс сеанса. После проверки облако OCF отправляет ответное сообщение, в котором указывается оставшееся время жизни соответствующего токена доступа. После этого устройству доступно активное соединение с возможностью обмена данными.
После установления TLS-соединения с облаком OCF устройство представляет (публикует) ресурсы в каталоге в облаке OCF. Они становятся доступными для просмотра или получения удаленного доступа (см. 6.1.3.2, 8.2, а также [2], 10.5).
Для получения доступа к серверу клиенты следуют процедуре, приведенной в 5.5.2, и регистрируются в облаке OCF аналогично.
Облако OCF обеспечивает взаимодействие между всеми устройствами пользователя облака OCF на основе того, что они имеют один и тот же идентификатор пользователя.
Когда клиент предпринимает попытку выполнить действия манипулирования ресурсами (CRUDN) по ссылкам, размещенным в облаке OCF, облако OCF направляет соответствующие запросы на нужное устройство. Устройство отвечает облаку OCF, которое затем передает ответ клиенту. Таким образом, взаимодействие происходит по схеме клиент -> облако OCF -> устройство -> облако OCF -> клиент (см. 8.3, 8.4 и [2], подраздел 10.5).
До или в момент истечения срока действия токена доступа устройство обновляет свой токен, отправляя запрос UPDATE ресурсу обновления токена (см. [2], подраздел 13.13).
Чтобы выйти из взаимодействия с облаком OCF, устройство отправляет на ресурс сеанса запрос UPDATE со значением false для статуса входа в систему (login). Эта операция не удаляет и не уничтожает какую-либо информацию о регистрации устройства. Устройство может повторно войти в облако OCF в любой момент до истечения срока действия токена доступа (см. [2], подраздел 13.12).
Для отмены регистрации в облаке OCF устройство отправляет ресурсу учетной записи сообщение запроса DELETE, указывая свой токен доступа. Облако OCF отправляет ответное сообщение, подтверждающее, что регистрация устройства была отменена.
Чтобы повторно подключиться к облаку OCF, устройство должно повторить процедуру, начиная с подготовки посредником (см. 5.5.4).
На рисунке 3 показана машина состояний, которая отражает последовательность операций, представленных в настоящем разделе (см. 8.5 и [2], подраздел 13.10).
![]() 6.1.1 Косвенное обнаружение при поиске ресурсов
Косвенное обнаружение - это когда третья сторона, отличная от обнаруживающего устройства и самого обнаруженного устройства, содействует процессу обнаружения. Третья сторона, а именно каталог ресурсов (RD), только предоставляет информацию о ресурсах от имени устройства, но не распоряжается ресурсами на этом устройстве.
На рисунке 4 облако OCF действует как каталог ресурсов для устройств A и D, которые принадлежат одной и той же учетной записи. Устройства A и D публикуют информацию о своих ресурсах в облаке OCF. Устройство C, которое также принадлежит той же учетной записи, что и устройства A и D, может запросить у облака OCF сведения о ресурсах устройств A и D.
![]() через каталог ресурсов
Косвенное обнаружение целесообразно в тех случаях, когда устройства находятся в разных сетях и требуется оптимизация обнаружения или маршрутизации. После того, как ресурсы обнаружены с помощью непрямого обнаружения, после запроса к каталогу ресурсов доступ к ресурсу осуществляется напрямую посредством запроса, отправленного в конечную точку, предоставленную каталогом ресурсов.
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.
Таблица 2
Таблица 3
Обнаруживаемый экземпляр oic.wk.rd должен допускать только безопасные соединения, такие как, например, конечная точка OCF со схемами подключения coaps или coaps+tcp. Для публикации ссылок в каталоге ресурсов /oic/res публикующее устройство отправляет в предварительно определенный URL /oic/rd запрос UPDATE со своими ссылками. Ответственность за то, что в каталоге ресурсов опубликованы корректные ссылки, доступные через его ресурс /oic/res, лежит на публикующем устройстве.
Чтобы найти ресурсы, размещенные на других устройствах, можно запросить каталог ресурсов через его ресурс /oic/res. Устройство при публикации ресурсов может предоставлять для размещения в каталоге ресурсов как полный, так и частичный перечень своих ресурсов. После публикации каталог ресурсов от имени опубликовавшего устройства отвечает на запросы на использование ресурсов. Следует отметить, что в открытом экземпляре /oic/res присутствуют только устройства, принадлежащие той же учетной записи, что и запрашивающее устройство. В общем случае при запросе ресурсов каталог ресурсов ведет себя точно так же, как любой другой сервер, отвечая на запросы к ресурсу /oic/res.
6.1.3 Операции каталога ресурсов
6.1.3.1 Обнаружение каталога ресурсов
На рисунке 5 устройство, ресурсы которого предполагается использовать совместно, сначала регистрируется в облаке OCF, в котором расположен каталог ресурсов, а затем публикует информацию о ресурсах.
![]() с использованием каталога ресурсов
Клиент, который выполняет обнаружение ресурсов через каталог ресурсов облака OCF, осуществляет это посредством одноадресного запроса к каталогу ресурсов. Каталог ресурсов, определенный в настоящем стандарте, не поддерживает использование многоадресных запросов для обнаружения экземпляров каталога ресурсов.
Общие положения
После выбора каталога ресурсов устройство может передать информацию о ресурсах в выбранный каталог ресурсов, т.е. опубликовать ссылки из собственного каталога ресурсов /oic/res в выбранный каталог /oic/res.
Публикующее устройство должно помечать все ресурсы, публикуемые в каталоге ресурсов, как доступные для обнаружения (см. [1], пункт 11.3.2). Минимальный набор ресурсов, которые публикующее устройство должно публиковать, - это обязательные базовые ресурсы /oic/d и /oic/p, а также ресурсы, которые определены как обязательные для данного типа устройства. Помимо этого обязательного набора публикующее устройство может также публиковать и дополнительные ресурсы. Публикующее устройство должно публиковать только те ресурсы, которые имеются в его собственном каталоге ресурсов /oic/res. Публикующее устройство не должно публиковать необнаруживаемые ресурсы или ресурсы, размещенные на каком-либо другом устройстве.
Публикующее устройство должно отвечать на запросы на обнаружение собственного ресурса /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-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
}
Первоначальный запрос каталога ресурсов UPDATE может быть удовлетворен или отклонен каталогом ресурсов. Если, например, запрос UPDATE включает в себя какие-либо ссылки, которые не могут быть разрешены, то запрос должен быть отклонен каталогом ресурсов с сообщением об ошибке, например "Неверный запрос". Если запрос удовлетворен, то каталог ресурсов должен отправить обратно на публикующее устройство ответ об успешном выполнении UPDATE. Информационное наполнение ответа должно включать в себя ту же информацию, что и исходный запрос UPDATE, со следующими возможными отличиями:
- для каждой ссылки каталог ресурсов должен включить в ответ параметр ins. Каталог ресурсов должен присвоить параметру ins уникальное значение, однозначно идентифицирующее данную конкретную ссылку в его массиве ссылок. Если публикующее устройство включило значение ins в запрос UPDATE, то каталог ресурсов может использовать его до тех пор, пока оно не будет соответствовать какому-либо существующему значению ins в его массиве ссылок;
- значение параметра ttl должно быть присвоено каталогом ресурсов и включено в ответ. Каталог ресурсов должен использовать значение, указанное в запросе UPDATE, но может также присвоить параметру и меньшее значение, если он не может обеспечить запрошенное значение ttl. По истечении времени, заданного параметром, каталог ресурсов должен удалить ссылки. Чтобы поддерживать ссылку в действительном состоянии, публикующее устройство должно обновить ttl, используя запрос UPDATE.
Каталог ресурсов должен добавлять новые ссылки в /oic/res и предоставлять их в ответ на корректный запрос ресурсов RETRIEV:
{
"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}
] ,
"ins": 11235
},
{
"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"}
] ,
"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, где компонент авторизации <deviceID> указывает на устройство, на котором размещен целевой ресурс.
Например, каталог ресурсов может вернуть клиенту следующее.
[
{
"anchor": "ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49",
"href": "/oic/res",
"rel": "self",
"rt": ["oic.wk.res"],
"if": ["oic.if.ll", "oic.if.baseline"],
"p": {"bm": 3},
"eps": [
{"ep": "coap://[2001:db8:a::b1d4]:77777"},
{"ep": "coaps://[2001:db8:a::b1d4]: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::b1d4]:77777"},
{"ep": "coaps://[2001:db8:a::b1d4]: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::b1d4]:33333"}
]
},
{
"anchor": "ocf://88b7c7f0-4b51-4e0a-9faa-cfb439fd7f49",
"href": "/oic/rd",
"rt": ["oic.wk.rd"],
"if": ["oic.if.baseline"],
"p": {"bm": 3},
"eps": [
{"ep": "coaps://[2001:db8:a::b1d4]: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::b1d4]:33333"}
]
{
"anchor": "ocf://dc70373c-1e8d-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-1e8d-4fb3-962e-017eaa863989",
"href": "/oic/p",
"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-1e8d-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-1e8d-4fb3-962e-017eaa863989",
"href": "/myLightBrightness",
"rt": ["oic.r.brightness"],
"if": ["oic.if.a", "oic.if.baseline"],
"p": {"bm": 3},
"eps": [
{"ep": "coaps://[2001:db8:b::c2e5]:22222"}
]
}
]
6.2.1 Общие положения
Ресурс CoAPCloudConf предоставляет информацию о конфигурации для подключения к облаку OCF. Данный ресурс может быть дополнительно включен в коллекцию Easy Setup (oic.r.easysetup) и таким образом использоваться в процессе простой настройки, как определено в OCF Wi-Fi Easy Setup.
Ресурс CoAPCloudConf должен предоставлять только безопасные конечные точки (например, CoAPS) (см. [1], раздел 10).
Ресурс CoAPCloudConf предоставляет информацию о конфигурации для подключения к облаку OCF. Это опциональный обнаруживаемый ресурс, который может быть дополнительно включен в коллекцию Easy Setup (oic.r.easysetup) и использоваться в процессе Easy Setup.
Ресурс CoAPCloudConf должен показывать только безопасные конечные точки (например, CoAPS) (см. [1], раздел 10).
6.2.2 Определение ресурса
Определение ресурса CoAPCloudConf приведено в таблице 4.
Таблица 4
Определение типа ресурса oic.r.coapcloudconf приведено в таблице 5.
Таблица 5
Если значение параметра clec устанавливается устройством, то его начальным значением должен быть "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). Возможно устройство находится в начальном состоянии. Устройство должно перейти в это состояние в результате сброса устройства (клиент с соответствующими привилегиями или настройка OBT pstat) в случае, если не заданы предварительные значения параметров настройки. Выполнение операции UPDATE для изменения свойств ресурса CoAPCloudConf возможно только в состояниях "не инициализировано", "готова к регистрации" или "не удалось" (uninitialized, readytoregister или failed).
Состояние readytoregister
Устройство было настроено посредником с заданием значений параметров cis, sid и at типа ресурса oic.r.coapcloudconf, но подключение к облаку OCF отсутствует, и устройство не находится в процессе подключения. Устройство может находиться в данном состоянии изначально. Устройство перейдет в это состояние из состояния uninitialized после того, как посредник настроит значения параметров cis, at и sid в oic.r.coapcloudconf. Устройство перейдет в это состояние в результате сброса устройства (задание клиентом параметра pstat), если заданы предварительные значения параметров настройки.
Состояние registering
Устройство перейдет в состояние registering после инициирования установления TLS-соединения с облаком OCF. Устройство должно перейти из состояния registering в состояние registered при получении ответа об успешном запросе UPDATE, отправленного на ресурс /oic/sec/account. Если на запрос UPDATE, отправленный на ресурс /oic/sec/account, получен ответ о неудачном запросе, то устройство должно перейти в состояние failed, если только устройство не повторит попытку регистрации самостоятельно, отправив запрос UPDATE на ресурс /oic/sec/account. В этом случае устройство должно оставаться в состоянии registering (см. 8.1.4).
Состояние registered
Устройство завершило регистрацию в облаке OCF, как определено в пункте 8.1.4. Если после этого регистрация устройства отменяется в соответствии с 8.5, то устройство переходит в состояние readytoregister.
Состояние failed
Во время процедуры регистрации устройство получило ответ от облака OCF о неудаче, как определено в 8.1.4, и не пытается автономно выполнить повторную попытку. Устройство может иметь какие-либо сторонние средства или схему вмешательства пользователя, которые для обеспечения возможности повторной попытки позволяют перевести устройство из состояния failed в состояние readytoregister или состояние uninitialized.
Значение параметра clec, если оно доступно, должно содержать конкретную причину сбоя, из-за которого устройство оказалось в состоянии failed.
6.2.4 Обработка ошибок
Параметр clec ресурса CoAPCloudConf (т.е. oic.r.coapcloudconf) используется для определения характера ошибки, возникшей в процессе настройки облака при попытке подключения к облаку OCF, с использованием информации, заполненной посредником в ресурс CoAPCloudConf. Это необязательный параметр, но если он предусмотрен реализацией, то его значение устанавливается устройством:
- устройство должно установить значение 1-го параметра clec, если оно получает ответ об ошибке от облака OCF;
- устройство должно установить значение 2-го параметра clec, если происходит сбой подключения к облаку OCF, например, отсутствие ответа, тайм-аут;
- устройство должно установить значение 3-го параметра clec, если ему не удается обновить токен доступа, например, если оно получает ответ об ошибке во время процедуры обновления токена.
Между устройством и облаком OCF устанавливается сессия TLS (см. [6]). Сессия устанавливается после настройки устройства, в соответствии с 8.1.2.3.
8.1.1 Общие положения
На рисунке 7 представлено взаимодействие между различными структурами в процессе регистрации устройства в облаке OCF. Сведения о процессе регистрации устройства в облаке OCF представлены в таблице 7.
![]() Таблица 7
8.1.2 Действия посредника
8.1.2.1 Общие положения
Посредник - это специализированная служба, которая используется для предоставления ресурса oic.r.coapcloudconf и обеспечения подключения автономного устройства к облаку OCF. Подробное описание посредника приведено в руководстве по простой настройке OCF Wi-Fi.
Посредник входит в состав OBT (инструмент адаптации) и поэтому может быть использован на любом устройстве, на котором внедрен OBT. Устройство может обмениваться данными с облаком OCF, если доверенный посредник авторизовал устройство. Устройство и посредник подключаются через DTLS, используя учетные данные из /oic/sec/cred.
В рамках подготовки устройства посредник в предоставляемом устройством ресурсе oic.r.coapcloudconf задает следующую информацию:
- значение URL-адреса облачного интерфейса OCF (cis);
- значение OCF облака OCF (sid) (для проверки подлинности облака);
- токен доступа (at), проверенный облаком OCF;
- необязательное значение: имя поставщика авторизации (apn), через которое был получен токен доступа.
Если в процессе регистрации и аутентификации устройства в облаке OCF возникает ошибка, то посредник, чтобы получить подсказку относительно причины ошибки, может получить значение параметра clec, если оно реализовано на устройстве ресурсом oic.r.coapcloudconf.
Посредник использует механизм авторизации пользователя, позволяющий облаку OCF проверять авторизацию пользователя облака OCF и получать идентификационные данные пользователя облака OCF. Поставщику авторизации должны доверять как пользователь облака OCF, так и само облако OCF. Для получения токена доступа в качестве формы авторизации от пользователя облака OCF через поставщика авторизации посредник может использовать OAUTH 2.0 (см. [4]) или другой механизм аутентификации пользователя. Такая авторизация преследует различные цели.
Во-первых, авторизация показывает согласие пользователя облака OCF на подключение посредника к облаку OCF. Во-вторых, авторизация используется для получения информации для привязки устройств к конкретному пользователю облака OCF.
Механизм авторизации пользователей используется для достижения следующих целей:
- получение токена доступа, подтвержденного облаком OCF;
- авторизация пользователя облака OCF через поставщика авторизации, что означает согласие на подключение к облаку OCF.
Если пользователь облака OCF использует еще и другого посредника, то возможно получение нового токена доступа от поставщика авторизации.
Чтобы установить TLS-соединение, посредник подключается к облаку OCF, используя предоставленный посредником сертификат.
При первом подключении посредник начинает процесс регистрации в облаке OCF. Для регистрации в облаке OCF посредник предоставляет облаку OCF токен доступа посредника, полученный от поставщика авторизации.
Затем облако OCF проверяет токен доступа у поставщика авторизации. Если поставщик авторизации успешно подтверждает токен доступа, то он возвращает информацию о пользователе облаку OCF, которому принадлежит токен доступа. Облако OCF генерирует уникальный токен доступа для посредника, который может быть как исходным токеном доступа от посредника, так и новым токеном доступа, и в таком случае при регистрации посредником этого пользователя облака OCF ему присваивается идентификатор пользователя (параметр uid ресурса oic.r.account). Идентификатор пользователя используется в дальнейшем в качестве уникальных идентификационных данных пользователя облака OCF. Все экземпляры посредника для одного и того же пользователя облака OCF будут связаны с одним и тем же идентификатором пользователя. Эта информация возвращается посреднику через TLS-соединение. Возвращенные токен доступа и идентификатор пользователя используются облаком OCF для идентификации посредника. В последующих взаимодействиях с облаком OCF посредник будет использовать именно этот возвращенный токен доступа.
При регистрации через одного и того же посредника все регистрируемые в облаке OCF устройства получают от облака OCF один и тот же идентификатор пользователя.
До начала взаимодействия посредника с облаком 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).
Подробная информация о заполнении записей ACE2 на устройстве для разрешения получения запроса CRUDN от посредника и облака OCF приведена в [2], пункт 7.5.2.
В таблице 8 приведена более подробная информация, связанная с процессом.
![]() Таблица 8
Более подробная информация по сопоставлению свойств между устройством и облаком OCF приведена в [2], пункт 7.5.2.
По завершении подготовки устройства (см. 8.1.2.3) и после перехода устройства в состояние RFNOP (если только оно еще не находится в RFNOP) устройство должно установить TLS-соединение с облаком OCF (см. [2], раздел 10).
Если аутентификация для установления сеанса TLS не была успешной, то параметр clec ресурса oic.r.coapcloudconf на устройстве и если это поддерживается устройством должно быть обновлено в соответствии со сбоем. Если аутентификация прошла успешно, то устройство и облако OCF устанавливают зашифрованное соединение в соответствии с согласованным набором шифров. Кроме того, если TLS-соединение потеряно из-за сбоя, параметр clec ресурса oic.r.coapcloudconf на устройстве, если это поддерживается устройством, должно быть обновлено до значения состояния сбоя (значение "2").
Если TLS-соединение потеряно из-за сбоя или закрыто облаком OCF, то оно может быть восстановлено посредством выполнения процедур аутентификации (см. [2], раздел 10). Устройство может попытаться восстановить TLS-соединение автоматически, либо для повторной попытки установления TLS-соединения устройству может потребоваться какое-либо действие пользователя.
Облако 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.
Облако OCF предоставляет каталог ресурсов, как это определено в 6.1. После регистрации устройства в облаке OCF устройство должно опубликовать свои ресурсы в каталоге ресурсов облака OCF в соответствии с вышеопределенными процедурами. Устройство и облако OCF поддерживают постоянное TLS-соединение, по которому передаются запросы устройства к облаку OCF.
Облако OCF обеспечивает внутреннюю связь между опубликованной информацией о конечной точке устройства и информацией о конечной точке, которую оно (облако OCF) предоставляет в ссылках в каталоге ресурсов облака OCF. Конечная точка, предоставляемая облаком OCF для каждого из опубликованных в нем ресурсов, принадлежит самому облаку OCF, а не публикующему устройству. Эти конечные точки используют схему coaps+tcp. Ссылки в каталоге ресурсов облака OCF идентифицируются только по учетной записи пользователя облака OCF (идентификатор пользователя). Например, зарегистрированные ссылки возвращаются клиенту исключительно с тем же идентификатором пользователя и не возвращаются какому-либо другому клиенту с другим идентификатором пользователя.
Некоторая неоднозначность возможна, когда разные экземпляры устройств от одного и того же поставщика публикуют свои ресурсы (например, несколько источников света). Эта ситуация связана с тем, что локальный параметр ссылки href, предоставляемый каталогом ресурсов, скорее всего, будет одинаковым в каждом из этих случаев. Чтобы избежать этой неоднозначности, каталог ресурсов должен добавлять в начало публикуемой ссылки href UUID публикующего устройства. Таким образом, для любого запроса, полученного облаком OCF, будет получен уникальный URI опубликованного ресурса.
На рисунке 9 приведен пример, представленного устройством UUID-идентификатора.
![]() Регистрируясь в облаке OCF, выступающее в роли клиента устройство выполняет те же процедуры, что и устройство, выступающее в роли сервера. Такой клиент связан с идентификатором пользователя таким же образом, как и сервер связан с тем же идентификатором пользователя.
Чтобы обнаружить ресурсы, опубликованные в облаке 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 каталогом ресурсов облака OCF. Таким образом и другие запросы CRUDN, инициированные клиентом, перенаправляются на сервер через облако OCF. Публикующее устройство обрабатывает перенаправленный запрос как запрос от облака OCF. Публикующее устройство авторизует запрос (см. [2]), используя UUID облака OCF, заданный в параметре sid ресурса oic.r.coapcloudconf. Публикующее устройство отправляет ответное сообщение в облако OCF, а облако OCF пересылает ответ клиенту, отправившему соответствующий запрос. На рисунке 11 показана маршрутизация запросов через облако OCF.
![]() Если облако OCF по какой-либо причине не может направить запрос клиента на сервер, оно может отклонить запрос с соответствующим ответом (например, Service Unavailable).
Чтобы отменить регистрацию в облаке OCF, устройство отправляет запрос DELETE на ресурс /oic/sec/account (см. [2], подраздел 13.11).
После завершения отмены регистрации устройства облако OCF удаляет ссылки на отмененное устройство из каталога ресурсов облака OCF.
Действия при переходе состояний устройства описаны в [2]. В настоящем разделе определены действия, необходимые для функциональности, определенной в настоящем стандарте.
В таблице 9 представлено краткое описание необходимых действий.
Таблица 9
При аппаратном сбросе устройство, если оно зарегистрировано в облаке OCF, должно отменить регистрацию в облаке OCF в соответствии с процедурами ресурсов безопасности (см. [2], подраздел 13.10).
Кроме того, при аппаратном сбросе ресурс CoAPCloudConf (oic.r.coapcloudconf) должен быть изменен в соответствии с таблицей 10 для тех параметров, которые включены в реализацию.
Таблица 10
(справочное)
А.1 Перечень определений типов ресурсов
Перечень ресурсов, определенных в настоящем стандарте, приведен в таблице А.1.
Таблица А.1
А.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":
"/template/go.php?url=https://github.com/openconnectivityfoundation/core/blob/e28a9e0a92e1704
2ba3e83661e4c0 fbce8bdc4ba/ LICENSE.md",
"x-copyright": "Copyright 2016-2019 Open Connectivity Foundation, Inc. All rights
reserved."
},
"termsOfService": "/template/go.php?url=https://openconnectivityfoundation.github.io/core/DISCLAIMER.md"
},
"schemes": ["http"],
"consumes": ["application/json"],
"produces": ["application/json"],
"paths": {
"/oic/rd" : {
"get": {
"description": "Resource to be exposed by any Device that can act as a
Resource Directory.\n1) 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"],
"sel": 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.\n1) 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-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://[2001:db8:a::b1d6]:1111", "pri": 2 },
{ "ep": "coaps://[2001:db8:a::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
}
}
],
"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-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://[2001:db8:a::b1d6]:1111", "pri": 2 },
{ "ep": "coaps://[2001:db8:a::b1d6]:1122" },
{ "ep": "coaps+tcp://[2001:db8:a::123]:2222", "pri": 3 }
],
"ins": 11235
},
{
"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"}
],
"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":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.common.
properties.core- schema.json#/definitions/n"
},
"sel" : {
"description": "A bias factor calculated by the Resource Directory",
"maximum": 100,
"minimum": 0,
"readOnly": true,
"type": "integer"
},
"id" : {
"$ref":
"/template/go.php?url=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": ["sel"]
},
"rdPublish" : {
"properties": {
"di" : {
"$ref": "/template/go.php?url=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":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.links.
properties.core- schema.json#/definitions/anchor"
},
"di": {
"$ref":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.links.
properties.core- schema.json#/definitions/di"
},
"eps": {
"$ref":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.links.
properties.core- schema.json#/definitions/eps"
},
"href": {
"$ref":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.links.
properties.core- schema.json#/definitions/href"
},
"if": {
"description": "The interface set supported by the published
resource", "items": {
"enum": [
"oic.if.baseline",
"oic.if.ll",
"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":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.links.
properties.core- schema.json#/definitions/ins"
},
"p": {
"$ref":
"/template/go.php?url=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,
"uniqueItems": true,
"type": "array"
},
"title": {
"$ref":
"/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.
links.properties.core- schema.json#/definitions/title"
},
"type": {
"$ref":
"/template/go.php?url=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"]
}
}
}
А.2.5 Определение параметров
В таблице А.2 определены параметры ресурса типа oic.wk.rd.
Таблица А.2
А.2.6 Запросы CRUDN
В таблице А.3 определены операции CRUDN, которые поддерживаются для ресурса типа oic.wk.rd.
Таблица А.3
А.3.1 Введение
Ресурс CoAPCloudConf предоставляет информацию о конфигурации для подключения к облаку OCF.
А.3.2 Пример URI
/CoAPCloudConfResURI
А.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":
"/template/go.php?url=https://github.com/openconnectivityfoundation/core/blob/e28a9e0a92e17042ba3e8366
1e4c0fbce8bdc4ba/LICEN SE.md",
"x-copyright": "Copyright 2018-2019 Open Connectivity Foundation, Inc. All rights
reserved."
},
"termsOfService": "/template/go.php?url=https://openconnectivityfoundation.github.io/core/DISCLAIMER.md"
},
"schemes": ["http"],
"consumes": ["application/json"],
"produces": ["application/json"],
"paths": {
"/CoAPCloudConfResURI?if=oic.if.rw" : {
"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"],
"apn": "github",
"cis": "coaps+tcp://example.com:443",
"sid" : "987e6543-a21f-10d1-a112-421345746237",
"clec": 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",
"cis": "coaps+tcp://example.com:443",
"sid" : "987e6543-a21f-10d1-a112-421345746237"
}
}
],
"responses": {
"200": {
"description" : "",
"x-example":
{
"apn": "github",
"cis": "coaps+tcp://example.com:443",
"sid" : "987e6543-a21f-10d1-a112-421345746237",
"clec": 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-10d1-a112-421345746237",
"clec": 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",
"cis": "coaps+tcp://example.com:443",
"sid" : "987e6543-a21f-10d1-a112-421345746237"
}
}
],
"responses": {
"200": {
"description" : "",
"x-example":
{
"apn": "github",
"cis": "coaps+tcp://example.com:443",
"sid" : "987e6543-a21f-10d1-a112-421345746237",
"clec": 0
},
"schema": { "$ref": "#/definitions/CoAPCloudConf" }
}
}
}
}
},
"parameters": {
"interface-all" : {
"in" : "query",
"name" : "if",
"type" : "string",
"enum" : ["oic.if.rw","oic.if.baseline"]
}
},
"definitions": {
"CoAPCloudConf" : {
"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":
"/template/go.php?url=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": "/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.types-
schema.json#/definitions/uuid"
},
"clec" : {
"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":
"/template/go.php?url=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": "/template/go.php?url=https://openconnectivityfoundation.github.io/core/schemas/oic.types-
schema.json#/definitions/uuid"
}
},
"type" : "object",
"required":["cis", "at", "sid"]
}
}
}
А.3.5 Определение параметров
В таблице А.4 приведены параметры ресурса типа oic.r.coapcloudconf.
Таблица А.4
А.3.6 Запросы CRUDN
Операции CRUDN, которые поддерживаются для ресурса типа oic.r.coapcloudconf, определены в таблице А.5.
Таблица А.5
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/17/gost_79261.html
На правах рекламы:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||