摘要

  • Open Cloud Mesh 通知接收方已获资源访问权，但 OCM 层有意停在 WebDAV、SSH 或应用操作开始之前。
  • 最新 OCM 集成草案把证据边界写得很清楚：收到共享通知、拿到有效凭据和完成资源操作，是三份不同的记录。

邮件说有人共享了一个文件夹，远端服务也列出了它。接收者点击后，请求却失败了。

这并不自动说明第一条消息造假。它说明运维系统把一条控制面声明，当成了后续所有动作都已完成的收据。

9 月 11 日发布的 draft-ietf-ocm-integration-protocol-00，正好把这条边界展开。Open Cloud Mesh 负责联邦协调：发送服务器告诉接收服务器，某个接收方已获得资源访问权。真正的访问随后由 WebDAV、SSH 或特定应用协议完成。集成草案允许 OCM 服务器把这些协议工作委派给另一台 Protocol Server，而接收端无需知道内部部署发生了变化。

它分开的不是产品模块，而是现实层：行政声明与运行结果不是一件事。

通知只是继续流程的入口

Share Creation Notification 携带双方身份、providerId、协议端点、权限和其他后续交换所需信息。它可以告诉接收端下一步去哪里，却不包含那一步的执行结果。

providerId 把后通道里的 Share 状态连接到前通道凭据。草案却特别强调：它是标识符，不是凭据。接收服务器本来就能从通知中看到它，单凭这个值不得获得访问权。授权必须来自经过验证的访问令牌；在兼容旧式 shared secret 的 introspected 模式中，则要由 OCM 服务器回答该凭据是否仍然 active。

即使令牌有效，它回答的也只是有限问题。签名可以证明发行者，并保护声明不被篡改。Protocol Server 仍须检查 issuer、audience、subject、有效期、配对关系与 Share 状态，然后执行权限。存储或应用还必须真正完成操作。有效授权不能让不存在的文件出现，不能把旧版本变成新版本，也不能把失败的 WebDAV 请求改写成成功传输。

通知不是授权，授权不是执行，执行也不是接收者的最终结果。

草案主动排除一种假成功

Provisioned integration 最能说明设计者知道这个风险。OCM 服务器先通过签名后通道向 Protocol Server 发送 Share Provisioning Request。后者验证请求、保存 Share Record 并确认成功。只有完成这些步骤，OCM 服务器才可以向接收端发出 Share Creation Notification。

这个次序是强制的。若 provision 失败，OCM 服务器不得创建 Share；否则，接收方会收到一个实际上无法访问资源的共享通知。

规则消除的是一个具体坏状态：“协议服务器拒绝 provision，系统却仍宣布共享成功。”它并不证明未来每次访问。密钥可能轮换，令牌交换可能失败，令牌可能过期，身份绑定可能不一致，资源可能移动，Protocol Server 可能离线，底层协议可能返回错误，接收端应用也可能在完成前退出。

因此，这份收据的准确名字只能是“通知发出前 provision 已成功”，不能升级成“接收方已访问资源”。

三种模式，三只不同的钟

草案定义 provisioned、self-contained 和 introspected 三种集成模式。它们可以生成外观相同的 OCM 通知，却拥有不同的后续证据和撤销机制。

Provisioned 模式在 Protocol Server 保存 Share Record，并支持明确的撤销请求。Self-contained 模式把 Share 信息放进签名的 ocm_ip JWT claim；服务器没有逐 Share 的后通道状态，已经发出的令牌会持续有效到过期。Introspected 模式每次查询凭据是否 active，但正面的 introspection 响应可以缓存，所以撤销要等缓存失效才完全生效。

这三只钟决定了“14:00 撤销共享”究竟意味着什么。第一种模式要看 Share Record 的撤销收据；第二种要看最后一枚有效令牌的最长寿命；第三种要看正面 introspection 缓存的失效时刻。同一个邀请界面下面，可能运行着三套不同控制系统。

这不意味着对所有对端公开内部委派拓扑。草案有意让委派式服务与 OCM 服务器直接提供协议看起来相同。真正需要的是运营者在受保护的本地记录中写明：该 Share 使用何种模式，哪项生命周期动作实际完成。

最后一公里由访问协议回答

前通道最终落到 WebDAV、SSH 或具体应用。草案要求 Protocol Server 返回的错误使用相应访问协议的语义。这是一个诚实的界面：OCM 不替底层协议声称自己知道结果。

对 WebDAV，可靠记录可以包括 HTTP 状态、方法、ETag 或内容版本，以及响应体是否完整。对 SSH，通过身份验证与会话建立，不等于用户想执行的命令或文件操作完成。对 Web 应用，成功打开授权页面，也不等于后台计算任务已完成。

完整收据链至少连接五层：Share 通知；令牌发行或 introspection；Protocol Server 授权判定；底层协议响应和资源版本；接收端应用结果。仪表盘可以压缩展示，但必须保留每个事实来自哪一层。

来源