摘要

  • OpenCAPIF Release 5 让不同的 CAPIF 核心功能可以跨域共享服务 API。
  • 互联需要对端身份、双向 TLS、提供方分享设置和针对调用方的可见性规则。

API 邻居家的门终于找到了。Release 5 到门口先翻登记簿。

ETSI 于 10 月 26 日发布 OpenCAPIF 5.0.0。核心变化是 CAPIF Interconnection：各自运行的 CAPIF 部署能够跨组织发现并分享服务 API。一个 CAPIF 核心功能（CCF）下的调用方，可以使用另一个 CCF 后面的 API。新闻稿用一句话讲清了目标，Release 5 的实现则把“如何认识邻居”拆成一串具体动作。

连接由本地 CCF 管理员发起。CCF-A 通过双向 TLS 联系 CCF-B，并提交自己的 CCF 标识、域名、证书颁发机构信息和公钥。对端保存这份身份信息，再返回自己的身份。双方随后同步符合条件的 API。先认人，再递目录；这套顺序给跨域分享装上了门牌和门锁。

每条 API 是否出门，由提供方设置。它必须标记 isShareable = true，并在 capifProvDoms 中列出获准接收的域。API 来源不能是当前对端，已有发布路径中也不能重复包含该对端。发送给邻居的副本会被标成不可再次分享，避免 API 绕一圈又回到原处。跨域目录因此有去向，也有边界。

Open Discover 解决入网前的一件小事：想找的 API、版本或 endpoint 到底在不在？调用方拿到 Register Service 的有效令牌后，可以先查询再决定是否 onboarding。开发者可以先看货架，再去办会员卡。

Visibility Control 决定不同人看到的货架是否相同。提供方和管理员可以按提供方、API 或 AEF 设置选择器，给特定调用方开例外，选择默认允许或拒绝，控制规则启停并设置有效期。Discover Service 会对每次查询应用当前规则。API 的存在和 API 对某个调用方可见，是两件可以分开管理的事。

Release 5 还调整了重名规则：不同 API Exposing Function（AEF）可以发布同名 API，同一个 AEF 的重复名称仍会被拒绝。名称与实际暴露服务的功能关联，不必全平台只留一份。

3GPP 在 Release 16 引入 CAPIF 互联，并规定 CAPIF-6/6e 参考点及安全程序。其规范留出部分实现细节；OpenCAPIF 将自己的具体流程称为 SDG 的实现提案，并放在 3GPP 架构之内。Release 5 的价值就在于把这些空白落实成可检查的顺序：身份如何交换，API 何时同步，哪些副本不得继续转发。

项目新增 31 项测试：互联 11 项、可见性 12 项、Open Discover 6 项、AEF 间同名 API 2 项。数量说明了工程工作落在哪些功能上。对运维人员来说，关键是每一步都有记录：对端是谁、哪条 API 获准出境、谁看得见，以及关系终止后副本是否撤干净。

Sources