Кратко

  • Рабочая группа Open Cloud Mesh приняла работу над интеграционным протоколом; draft-ietf-ocm-integration-protocol-00 появился 11 сентября 2026 года. Это изменяемый Internet-Draft, а не RFC.
  • В подготовленном, самодостаточном и интроспективном режимах по-разному размещаются состояние, зависимость от сервера и момент отзыва. Выпуск токенов тоже можно поручить отдельному Token Server.
  • Принимающая сторона не обязана видеть делегирование. Daniel Kade предлагает отправляющему оператору вести защищённую карту ролей, изменений и результатов; проект OCM такой карты не требует.

Группа получила текст в работу

История Datatracker фиксирует 11 сентября первую версию WG и замену индивидуальной серии. В сообщении о результате председатель называет принятые документы отправными точками, которым ещё предстоит меняться. Решение определяет коллективного владельца дальнейшей работы, но не означает утверждения стандарта IETF или наличия внедрения.

Версия WG 00 отделяет федеративную роль от конкретного протокола доступа. Перед федерацией OCM Server остаётся отправляющим сервером. За ним один или несколько Protocol Server обслуживают WebDAV, SSH/SFTP либо веб-приложение. Их программное обеспечение и инфраструктура могут отличаться.

Отдельному Token Server разрешено передать и endpoint выдачи токенов. В облегчённой схеме OCM Server сохраняет обнаружение, учёт Shares, уведомления и приглашения, тогда как доступ к ресурсу и выпуск удостоверений работают в других компонентах. Внешнее имя не меняется, но набор доверенных исполнителей расширяется.

По сравнению с индивидуальной версией 01 первая версия WG добавляет модель угроз. Она предполагает, что OCM Servers, спаренные Protocol Servers и делегированный Token Server не скомпрометированы и правильно проводят локальную политику. Подписи защищают от вмешательства в канал; они не исправляют скомпрометированный доверенный endpoint.

Отзыв зависит от выбранного режима

При подготовленной интеграции OCM Server заранее передаёт сведения о Share по подписанному обратному каналу. Protocol Server хранит Share Record, а при завершении получает запрос отзыва и освобождает связанные ресурсы. Только этот режим поддерживает SSH; он также нужен приложению, которое создаёт отдельную сессию или вычислительную среду для каждого Share.

При самодостаточной интеграции входного API и состояния Share нет. Необходимые сведения помещаются в утверждение ocm_ip подписанного JWT. Упрощение имеет цену: выпущенный токен нельзя отозвать до истечения срока. Проект запрещает смешивать этот путь с подготовленным для одного Share, чтобы старый токен не пережил удаление записи.

При интроспективной интеграции предъявленное удостоверение проверяется через endpoint по RFC 7662. Режим совместим с принимающими серверами, которые по-прежнему отправляют прежний sharedSecret, но возвращает зависимость каждого некэшированного запроса от OCM Server или Token Server. Положительный кэш отодвигает действие отзыва до своего истечения.

Следовательно, отметка «поддерживает OCM-IP» почти ничего не говорит о жизненном цикле. Нужны режим, срок токена, предел кэша, местонахождение состояния и подтверждение того, что выделенный ресурс действительно снят.

Партнёр видит интерфейс, а не внутреннюю сборку

Требование прозрачности адресовано принимающей стороне. Она не должна реализовывать OCM-IP или знать о нём. Объявленный endpoint может обслуживать сам OCM Server, обратный прокси или Protocol Server на другом хосте. OCM не вводит признак, по которому удалённый партнёр обнаружит эту схему.

Внутри отправляющего домена связь задаётся явно. Операторы выполняют спаривание вне протокола и настраивают протоколы, типы ресурсов, режимы, домены, API и адреса JWKS. Protocol Server обязан вести список разрешённых OCM-доменов и отклонять неспаренных издателей.

Обратный канал применяет HTTP Message Signatures и опубликованные JWK Sets; доступ опирается на подписанные JWT. Проверка связывает утверждение с ключом, а спаривание и состояние Share определяют допустимый объём власти.

Этого недостаточно, чтобы узнать, кто одобрил замену сервера, зачем увеличили срок токена, какой ключ был предшественником или была ли сессия приложения уничтожена после отзыва. Проект включает Protocol Server в доверенную вычислительную базу отправителя. Token Server получает полномочие подписи и данные о Share и личности. Такая передача требует собственного доказательства.

Запись ocm_ip ещё не выделена IANA

Проект просит зарегистрировать ocm_ip как утверждение JWT и член ответа OAuth-интроспекции после превращения документа в RFC. На момент проверки ни реестр JWT IANA, ни реестры параметров OAuth не содержали точной записи ocm_ip.

Так и должно быть на этой стадии. Принятие WG запускает совместную разработку, а не исполняет раздел IANA Considerations. Экспериментальная реализация должна указывать версию проекта и не выдавать запрошенное имя за уже назначенное стандартное значение.

Сохранить карту делегирования внутри

Daniel Kade предлагает защищённую карту ответственности за делегирование. В ней OCM Server, Protocol Server и Token Server связываются со своей ролью, протоколами и ресурсами, режимом, идентификаторами endpoint и ключа, периодом действия, лицом или процессом одобрения, результатом отзыва и очистки, контактом для инцидентов и местом хранения подтверждающих журналов.

Это редакционное предложение, не требование IETF или OCM. Полную карту не следует помещать в токен либо отдавать каждому партнёру. Публичная квитанция, если она нужна, ограничивается непрозрачным ID, классом роли, периодом и проверенным результатом. Внутренние имена, персональные данные, закрытые ключи и чувствительная топология остаются под контролем доступа.

Карта документирует, но не наделяет полномочием. Замена компонента создаёт новую запись со ссылкой на прежнюю. В подготовленном режиме доставка отзыва и освобождение ресурса отмечаются отдельно. Для самодостаточного токена истечение срока не подменяет наблюдение о прекращении доступа.

Это соответствует The Policy Mirror Heng Lu: участник, правило и свидетельство не могут выступать друг за друга. Minimum Initial Specification позволяет оставить общий протокол небольшим и дополнить его более подробным локальным учётом. Партнёр получает стабильный интерфейс, а оператор не теряет историю того, что находится за ним.

Источники

  1. OCM Integration Protocol, версия WG 00
  2. Текущая запись Datatracker
  3. История документа
  4. Сообщение о результате принятия
  5. Индивидуальный предшественник, версия 01
  6. Рабочая группа Open Cloud Mesh
  7. Протокол OCM на IETF 126
  8. Базовый протокол OCM, версия WG 06
  9. RFC 9421 — HTTP Message Signatures
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — OAuth 2.0 Token Introspection
  12. RFC 7519 — JSON Web Token
  13. Реестр JWT IANA
  14. Реестры OAuth IANA
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification