摘要

  • Open Cloud Mesh 工作组已经采纳集成协议工作，draft-ietf-ocm-integration-protocol-00 于 2026 年 9 月 11 日出现。它仍是会继续修改的 Internet-Draft，不是 RFC。
  • 三种模式把共享状态、资源访问和撤销时效分配给 OCM Server 与 Protocol Server；令牌签发还可进一步交给 Token Server。
  • 草案要求接收端无需知道这些委派。Daniel Kade 建议发送方另存一份受访问控制的委派责任图；这项建议不属于 IETF 或 OCM 规范要求。

工作组接手的是问题，不是最终答案

Datatracker 历史显示，工作组 -00 版本在 9 月 11 日发布，并取代个人草案系列。主席公布结果的邮件把两份获采纳文档称作后续工作的起点，明确说它们还会演变。因此，当前事实是 OCM 工作组接手文本；不是 IETF 已批准标准，更不是产品已广泛部署。

工作组第 00 版所做的核心拆分很具体。面对联邦网络，OCM Server 仍代表发送方；在它背后，一个或多个 Protocol Server 可以实际提供 WebDAV、SSH/SFTP 或交互式 Web 应用。它们可以使用不同软件，也可以位于不同基础设施。

拆分还能再向前一步。令牌端点可以委派给单独的 Token Server。在草案描述的一种部署里，OCM Server 只保留发现、共享记账、通知和邀请，资源访问与令牌签发都在别处完成。对外身份没有改变，可信执行面却已经扩大。

与个人草案第 01 版相比，首个工作组版本新增威胁模型。它假定发送与接收 OCM Server、已配对的 Protocol Server 以及受委派的 Token Server 没有失陷，并能正确执行本地策略。这个边界很重要：加密机制可以对付传输途中的篡改，却不能让已失陷的可信端自动恢复可信。

三种模式，三种“撤销已经生效”的含义

预配置模式先通过签名后通道把 Share 信息交给 Protocol Server，由后者保存 Share Record。共享结束时，撤销请求要求停止服务并释放相应资源。需要为每个共享创建会话或计算环境的应用更适合这种模式；草案也只在这一模式下支持 SSH。

自包含模式不设置逐共享的后通道。OCM Server 把授权所需信息放进签名 JWT 的 ocm_ip 声明，Protocol Server 无需保存共享状态。代价是令牌签发后不能提前撤回，只能等它到期。草案禁止同一共享把自包含路径与预配置路径混用，以免旧令牌在 Share Record 已撤销后仍悄然有效。

内省模式通过符合 RFC 7662 的端点逐次检查凭据。它为仍直接提交旧式 sharedSecret、尚不能执行令牌交换的接收端保留兼容性，也重新引入逐请求依赖。若正面结果允许缓存，撤销要到缓存过期后才会被看见。

因此，“支持 OCM-IP”不足以说明运营风险。模式选择决定状态放在哪里、哪个组件必须在线、哪些元数据会流动，以及停止共享究竟由一条撤销消息、一个过期时间，还是一次新的内省结果来界定。

对端透明，不等于本地无人知情

草案的 Transparency Requirement 面向接收方：接收服务器不应被要求实现、甚至知道 OCM-IP。公开端点可以由 OCM Server、反向代理或另一主机上的 Protocol Server 提供；OCM 层不发布让远端识别这种安排的能力标志。

发送方内部却有明确配置。OCM Server 与 Protocol Server 由运营者在带外配对，内容至少包括负责的协议和资源类型、使用哪种集成模式、域名、接口地址与 JWKS 地址。Protocol Server 必须保存已配对 OCM 域名的允许列表，并拒绝未配对的签发者。

后通道依赖 HTTP Message Signatures 与公开的 JWK 集合，访问凭据依赖签名 JWT。签名验证回答“这把密钥是否作出过该断言”，允许列表与共享状态回答“该断言在这里是否有权力”。

它们不会自动回答谁批准了更换 Protocol Server、为何延长令牌寿命、上个月使用的是哪把密钥，也不会证明撤销后某个笔记本会话确已销毁。草案自己也承认责任的重量：Protocol Server 是发送方可信计算基的一部分；Token Server 则持有令牌签名权和签发所需的共享、身份信息。

ocm_ip 目前仍是拟申请名称

草案请求 IANA 在文本成为 RFC 后，把 ocm_ip 分别登记为 JWT 声明和 OAuth 令牌内省响应成员。截至本次核查，IANA JWT 注册表与OAuth 参数注册表都没有这一精确条目。

这不是执行迟缓，而是流程仍处于文档阶段。工作组采纳决定由谁继续打磨提案，不会提前完成 IANA 操作。试验性实现应标明所依据的草案版本，不能把未来请求写成现行分配。

为幕后委派留一张责任图

Daniel Kade 提议由发送方维护受保护的委派责任图。每条记录把 OCM Server、Protocol Server 与 Token Server 连接到其实际角色、协议与资源范围、集成模式、端点和密钥标识、生效时间、批准变更的人或流程、撤销与资源清理结果、事件联系人和证据留存位置。

这不是 IETF 或 OCM 要求，也不应原样塞进令牌或展示给所有对端。若有公开收据，只需给出不透明记录编号、角色类别、生效区间和已核验结果。内部主机名、个人身份、私钥和敏感拓扑继续受权限保护。

责任图只记载，不授权。组件更换时，新记录链接旧记录而非覆盖历史；预配置撤销要把“请求已送达”与“资源已释放”分开；自包含令牌到期也不能被写成所有副本均已停止使用的观测证明。

这种分工延续了 Heng Lu 在 The Policy Mirror 中强调的界线：行动者、规则和证据不能互相冒名。Minimum Initial Specification则允许公共规范保持小而明确，同时让本地治理保存更丰富的上下文。对端无需理解内部拼装，运营者也不应因此失去自己的责任链。

来源

  1. OCM 集成协议，工作组第 00 版
  2. 当前 Datatracker 记录
  3. Datatracker 文档历史
  4. OCM 主席公布采纳结果
  5. 个人草案第 01 版
  6. Open Cloud Mesh 工作组
  7. IETF 126 OCM 会议纪要
  8. OCM 基础协议，工作组第 06 版
  9. RFC 9421 — HTTP 消息签名
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — OAuth 2.0 令牌内省
  12. RFC 7519 — JSON Web Token
  13. IANA JWT 注册表
  14. IANA OAuth 参数注册表
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification