摘要

  • 2026 年 10 月 2 日发布的《Using KYAPay Tokens》第 01 版把消费令牌的一方从 “verifier” 改称 “recipient”，并明确写出：身份识别不等于准入。令牌即使完全验证通过，也只是给接收方提供可信上下文；允许、限速、升级认证或拒绝仍是本地决定。
  • 这次验证不能替代后续证据。持有 bearer token 不等于持有私钥，签发时的人类授权不等于持续控制，带有支付参数的凭据也不等于商户接受、清算或最终结算。

draft-skyfire-oauth-using-kyapay-tokens-01 最值得注意的变化，表面上只是一个名词：消费 KYAPay 令牌的角色不再叫验证者，而叫接收方。

验证者听起来像一个只负责回答真假的部件。接收方则处在行动发生前的权力位置。它可能是目标资源服务器，也可能是边缘服务、机器人管理器、欺诈系统、账户劫持防护或客户身份系统。它们可以面对同一份签名断言，完成相同的密码学验证，却作出不同的本地选择。

第 01 版在导言中把这条线写得很清楚。KYA 令牌可以携带签发者对人类委托人、代理运行平台和代理实例的断言；PAY 令牌还可以携带支付上下文。验证通过后，接收方对“签发者声称谁在这次请求背后”有了更好的答案，但它没有收到一条必须开门的命令。

新稿直接说，identification 与 admission 不同。令牌进入网站自己的策略引擎。接收方可以放行，可以限制速率，可以要求更强的人类认证，也可以拒绝。普通浏览与账户恢复、大额购买、权限提升所需的保证强度不应相同。把它们压成一个“已验证代理”的绿灯，恰恰会丢掉草案要求保留的层次。

这两份文件目前仍是个人互联网草案。冻结的 Datatracker 记录没有 stream、预期标准级别或正式标准级别。OAuth 邮件列表是讨论场所，不是工作组采纳证明。草案中提出的 HTTP 字段和 JWT claim 登记，在 IANA 实际登记前仍只是请求。

共同处理流程的价值在于把几个坐标显式拆开。接收方先决定是否信任签发者，再检查 JWT 的头部、签名、过期时间、签发时间、令牌标识、audience 和运行环境。它还要识别令牌类型，判断人类、平台和代理各自的保证信息。请求里出现 KYAPay-Token 字段本身，不能算人类在场证据。

即便这些步骤全部成功，呈现方式仍是另一层。规范默认讨论 bearer token：在有效期内，拿到它的人就可能呈现它。缩短寿命、使用 TLS、绑定 audience 并记录 jti 重放，都能收窄风险，但不能证明发送者控制着代理的私钥。

配套 token 第 02 版允许放入 cnf。它可以指向确认密钥，使令牌具备 sender-constrained 的条件，但前提是外层协议要求实际密钥证明，而且接收方真的验证该证明。签名对象里出现一个密钥引用，不等于证明动作已经发生。因此第 01 版把身份断言与 possession proof 当成不同层，并把强化路径描述为演进方向。

时间又增加一条边界。草案承认，有效令牌证明的是签发时存在授权，不证明人在整个寿命期间始终掌控代理。签发后主机可能失陷，平台可能被取消登记，人的授权也可能撤回。第 01 版没有定义撤销机制。动作对陈旧授权越不容忍，接收方就越需要新鲜挑战或独立控制。

签发者信任同样属于本地政策。正确签名只证明被选中的密钥签过这份令牌，不能证明其身份核验、代理登记、平台控制或底层 verifier 证据达到接收方自己的风险阈值。草案把大规模 issuer trust 称为开放问题，并承认当前要靠带外关系。这使信任列表的版本本身也成为决策收据的一部分。

支付语境不能吞掉这些限制。配套格式可以绑定目标、金额和币种，并携带单笔交易范围的支付凭据和一次性 cryptogram。这样做减少被截获凭据的复用价值，也方便欺诈系统核对请求参数。但它不证明商户已经接受，不证明网络完成授权和清算，不证明结算不可逆，更不证明商品交付。

因此，一份可审计收据至少应保存十个坐标：具体草案与 token profile；签发者与密钥集版本；签发者引用的身份核验证据与保证级别；令牌原文哈希；签名及注册 claim 检查；audience 与环境结果；重放存储结果；bearer 或密钥证明结果；接收方策略版本和升级认证结果；最终应用动作。涉及支付时，再追加真实存在的授权、清算、结算和撤销记录。

这不是反对互操作身份断言。相反，只有不把断言扩大成命令，它才更容易被多个独立系统安全采用。共享格式可以让各层看到一致的人、平台和代理坐标，减少仅凭 IP 地址或 User-Agent 猜测的需要。共享证据并不要求共享行动权。

Heng Lu 的“最小初始规范”支持这种安排：公共层只定义必要 claim 与验证不变量，让风险阈值和动作政策保持本地、可解释。“运行代码优先”要求继续观察实际执行：签名令牌不会替应用行动，将来的登记状态也不会证明请求成功。“现实分层”则防止把签发者断言、密码学结果、私钥证明、策略决定和用户结果合成一个“已授权”。

所以，recipient 不是一次文字润色。它准确指出下一项权力在哪里。签发者可以作证，令牌可以传输，验证器可以检查；接收方仍管理自己的接口，而应用必须留下自己真正做了什么的记录。

来源