摘要

  • draft-ietf-oauth-attestation-based-client-auth 第 11 版于 2026 年 9 月 3 日发布，OAuth 工作组在 9 月 8 日启动 Last Call，意见截止到 9 月 22 日。
  • 服务器提供质询并非强制。质询能活多久、能出现在一份还是多份 Client Attestation PoP JWT 中，完全由服务器本地策略决定；客户端必须使用最新值，但可以重复使用。
  • 一次性策略会在第二次使用时返回 use_attestation_challenge 和新值；客户端应只重试一次，不能无限循环。DPoP 组合模式则沿用 RFC 9449 的 nonce 机制。
  • 第 11 版新增了方法和算法元数据，却没有公布质询消费与重放语义。Daniel Kade 建议由部署 profile 声明 freshness policy；这是编辑分析，不是 IETF 现行要求。

Last Call 审查的是草案，不是既成标准

OAuth 工作组 Last Call 通知要求参与者在 9 月 22 日前明确支持或说明反对理由。Datatracker 条目显示，第 11 版是工作组当前文本，状态为 In WG Last Call。这是形成共识的一道真实关口，但它还不是 RFC，更不等于整个 IETF 已经批准这套做法。

草案要解决的是“某一个软件实例是谁”以及“它此刻是否掌握对应私钥”。Client Attester 先签发 Client Attestation JWT，把对实例的判断与实例公钥绑定。实例访问授权服务器或受保护资源时，再出示持钥证明。前一份对象承载第三方声明，后一份对象证明请求者确实控制私钥。

在普通模式下，持钥证明是一份 Client Attestation PoP JWT，内含签发时间和唯一 jti。接收方还可以自己提供一个不透明质询，让证明带上服务器掌握的时效信息。质询可以随错误响应返回，也可以藏在此前的一次响应中，或由公开的 challenge endpoint 主动领取。只要客户端已经收到质询，它就必须采用最新的一枚。

第 11 版正文随后把两项关键决定留在本地：质询的寿命，以及同一枚质询能否用于多份 PoP JWT。客户端被明确允许复用；只接受一次的服务器则会拒绝第二次使用。于是，一台允许短时间复用的服务器与一台逐次消费的服务器都符合草案，却可能无法在第一次交互前达成一致。

这项自由有现实理由。一次一值能提供更紧的控制，但要保存状态，也会放大并发协调成本。短窗口复用便于横向扩展，却必须依靠 jti 或其他机制分辨一份证明是否真的被重放。问题不在于允许两种部署，而在于不透明字符串无法告诉客户端自己拿到的是哪一种合同。

被拒后有规则，被拒前没有说明

草案把错误路径写得很具体。授权服务器若缺少预期质询，或不接受收到的值，就返回 HTTP 400 和 use_attestation_challenge；受保护资源使用 HTTP 401。两类响应都必须在 OAuth-Client-Attestation-Challenge 头中附上一枚新值。客户端收到后应重新生成证明并重试一次，同时不得无休止重试。

这能阻止错误循环，却不能消除一次本可避免的失败。设想应用先从 endpoint 取回质询，然后让多个进程并发请求 token。复用策略可以接受多份各自拥有新 jti 的证明；一次性策略只会让最快的一份通过，其他请求随即拿到新质询。规范告诉客户端如何收拾残局，却没有告诉它是否应该在发出请求前串行化整个队列。

第 11 版的安全章节也表明，“启用了质询”并不能概括实际防护。第一种实现保存滑动窗口内见过的 jti，从而识别同一份 PoP JWT 再次出现。第二种实现从 challenge endpoint 发值，并保存已经见过的质询；服务器能用自己挑选的值获得更强的重放检测，但要承担额外往返和状态表。

第三种实现采用自包含质询，不记录见过的值。它容易扩展，却只保证请求处于可接受的时间范围内，不能阻止该窗口中的重放。草案还允许把质询绑定到特定 Client Instance session，只检查该会话当前期待的值。相同的字段名背后，可能是状态表、时间封装或会话状态，安全含义并不一样。

质询之所以保持可选，是为了降低最低实现门槛。jti 仍然是强制字段，也是默认后备方案；服务器还应检查 iat 或质询所表达的时间窗口。这些底线有用，但“存在服务器质询”仍然不自动等于“一次性”，也不自动等于“能够防止窗口内重放”。

DPoP 组合模式走另一条时效通道

草案还允许用一份 RFC 9449 定义的 DPoP 证明同时完成两项工作：证明客户端实例持有对应私钥，并为访问 token 提供发送方约束。第 11 版明确规定，这个组合模式只使用 DPoP nonce。

因此，nonce 缺失或不被接受时返回的是 use_dpop_nonce 和 DPoP-Nonce，不是普通模式下的 use_attestation_challenge。同一个 challenge endpoint 可以预先交付 DPoP nonce，减少一次失败往返，但共用入口不意味着两种值可以混用。SDK 若把它们塞进同一缓存，就会抹掉本次修订刚刚划清的规范边界。

第 10 至 11 版官方差异把这项调整列为明确变化，同时记录了质询可选性、错误时必须给出新值以及 endpoint 可返回 DPoP nonce。失败后的线缆行为更清楚了；恰恰因此，失败前缺少什么也更容易看见。

元数据能发现能力，却看不见消费规则

第 11 版依照 RFC 7591 的通用数据模型增加客户端元数据。双方可以宣布支持的签名算法和持钥证明方法，包括 attestation_pop_jwt 与 dpop_combined。服务器还能公开 challenge endpoint。客户端在进行密码运算前，已经可以排除一部分不兼容组合。

它仍无法排除最容易改变调度方式的冲突。元数据没有说明质询是否必需、寿命属于哪一档、可以复用还是收到成功响应即被消费、服务器是否保存见过的值、自包含值是否仅提供时效性，或某条规则究竟对应普通模式还是 DPoP 组合模式。策略变化后，运维人员甚至没有一个 epoch 可与第二次使用错误的激增相对照。

服务器没有必要公开精确秒数或内部存储结构。风险与负载可以推动参数动态变化。不过，single-use、reusable、session-bound 这类外部可观察分类并不会泄露算法；witnessed-state 与 freshness-only 也能防止审计者把两种保证混为一谈。

Daniel Kade 建议在部署 profile 中增加一份小型 freshness-policy。它按证明模式分别声明：服务器时效值是支持还是强制、可以从哪些通道取得、寿命等级、消费方式、重放防护类别、允许的自动重试次数，以及策略版本。一份签名发现收据还可以把这项声明绑定到客户端实际读取的元数据版本。

这不是第 11 版的规范要求，也不是 OAuth 工作组已经形成的共识。草案本身允许不同生态为其制定 profile。最适合先试验的正是这一层：保留基础协议的本地选择，同时让需要确定行为的生态不再靠厂商私有异常来描述规则。

来源