Summary

  • 修订版 01 把发行者签名的 JWT Credential 放进 Authorization: DPoP，继续使用 RFC 9449 的 htu、htm、jti、nonce 与 ath。
  • 线上的字节与证明可以完全有效，却不能说明服务器收到的是访问令牌还是凭证；验证器必须依据受信任的 iss 与获准的 typ 分流。
  • 针对一次请求的持钥证明不能补出缺失的 aud，也不能证明凭证状态仍新鲜、所有 claims 都适合披露、该操作已获授权或业务结果已经发生。

同一条线路出现了语义岔路

草案没有另造一套出示协议。Holder 把完整 Credential 放在访问令牌原来的位置，再提交单独的 DPoP proof。ath 仍是对收到的 Credential 字符串之 US-ASCII 字节计算 SHA-256；服务器验证 proof 的签名、时间、方法、URI、jti 唯一性和必要的 nonce，并把 proof 的公钥与 cnf.jkt 或 cnf.jwk 的指纹对上。

这些步骤回答的是“这把被确认的私钥是否为这次请求出示了这串值”。它们没有回答“这串值应按哪套权威规则解释”。RFC 9068 的 JWT 访问令牌要求 aud，类型为 at+jwt。新草案则要求部署为 Credential 定义另一种 typ，且不得使用 at+jwt 或 ID Token 类型。一个同时接收两者的服务器必须以已配置的 iss 和 typ 选择验证分支。

如果系统只把 DPoP 结果做成一个绿色布尔值，错误并不会表现为密码学失败。它会表现为一份结构完整、签名正确的对象被送进了错误的政策解释器。

请求地址不是发行者受众

htu 与 htm 把 proof 绑定到服务器实际收到的方法和 URI。这是请求级持有证明。aud 则由 Issuer 在发行时设置，限制哪些验证器可以接受这份可重复使用的 Credential。Holder 选择发送目的地，并不会获得替 Issuer 写入受众的权力。

草案允许省略 aud。此时，只要多个资源服务器都信任同一 Issuer，Credential 就可能被提交给它们中的任何一个。共同信任一个身份提供者，并不等于共同接受同一 claims 词汇或同一业务权限。每个服务器仍要依据自己的授权政策作出决定；草案明确禁止仅凭 Credential 有效就推断访问获准。

长寿命把时钟移交给状态

Credential 可能比访问令牌活得更久，因此草案建议携带 status。有状态引用时，验证器必须读取并拒绝无效状态；对没有状态的长寿命 Credential，部署也可以直接拒绝。

状态列表缓存不是中性的性能参数。缓存多久，撤销可能延迟多久。发行者签名、眼前这次 DPoP proof 与一份旧状态列表各有自己的时间边界，谁也不会自动刷新另外两项。请求路径不必每次联络 Issuer，降低了延迟与直接跟踪，但状态拉取仍可能暴露使用模式。

完整出示意味着完整暴露

这不是选择性披露。每个 Verifier 都会看到整个 JWT，稳定签名还能让不同 Verifier 关联多次出示。Authorization 报头也可能进入服务器访问日志或中间代理。TLS 保护传输过程，却不会删掉多余 claim，也不能追回已经写入日志的副本。

如果验证器需要发现 Holder 有哪些凭证、只索取部分 claims，或在出示时取得自然人同意，就应使用 OpenID4VP 等协商型协议。新方案适合软件已经知道目标服务器和可接受 Credential 的情形。即使是 SD-JWT VC，在这里也只能以不带 disclosures 的发行者签名 JWT 使用。

Lu Heng 的最小初始规范提醒我们：复用一个最小共同机制，并不等于把所有政策集中到这个机制里。运行代码优先要求保存实际运行产生的证据——接受的类型、Issuer、audience 分支、状态年龄、授权版本与资源结果——而不是把同样的报头当作同样的现实。

Sources and limits

这些来源没有证明 OAuth 工作组采纳、IETF 共识、RFC 发布、实现、互操作、AI agent 部署、真实发行或撤销事件、授权决定或服务结果。既有 RFC 9449 文章保留通用发送者约束主题；本文只处理修订版 01 中“线路相同、权威模型不同”的岔路。