Summary

  • 新草案拟用 /.well-known/agent-capabilities 公布代理可用流程、授权服务器和调用入口。
  • 没被任何公开流程列出的操作默认关闭；即使旧的授权实例包含该操作，资源服务器也不得执行。草案同时警告，替换静态文件可以在不改应用代码时误导代理。

一扇门的钥匙曾经获批，门牌却在夜里被换掉。按照 IETF 新发布的场景发现与授权草案，服务方会把代理能力写进源站的 JSON 文件：有哪些流程、请求该走哪个调用面、去哪个授权服务器建立许可。代理据此规划动作。某项操作若不在任何公开流程里，就属于关闭状态；资源服务器不得执行，即使批准过的授权实例仍写着它。授权服务器则应拒绝包含该操作的实例。

关门当然可以是合法运营决定。草案第 8.6 节也把另一面摊开：攻击者若取得源站静态内容的写入权，可以放置或替换能力文件，把之后发现这个站点的代理引向攻击者选定的调用面，或者令真实流程消失。应用代码可以一行不变。作者建议像管控应用发版一样管控这份文件。RFC 8615早已提醒，管理员常忽略 .well-known 路径；如今这里可能放的是代理的操作边界。

原生应用也不能只相信打包时的副本。草案允许把能力文件装进安装包供离线发现，但要求在每次会话第一次远程操作前检查关联源站的版本；两者冲突时必须采用源站版本。源站删掉的操作，旧安装包仍列着也不得执行。版本号看起来没变，权限的实况却已变。

文件还列出授权服务器发行者与调用面。展示名称和徽标只是展示信息，身份绑定靠源站与经过认证的传输；若服务同时发布 OAuth 受保护资源元数据，两处授权服务器列表必须一致。这提供了一个可核对的冲突点。

IETF 文档记录将其列为 11 月 2 日更新的个人草案。现在缺的是具体部署的文件变更记录和执行日志；它们才能证明这道开关是否真在生产请求中生效。