KYA 与 KYAPay：怎样理解 Agent 携带的身份和支付声明

零售商收到一个自动化购买请求。知道它来自哪个 Agent 平台当然有用，但商户还可能需要知道：它代表哪位客户，是否同时携带适用的支付权限。这些是不同的声明，需要分别验证。

KYA 与 KYAPay 希望让这些信息以共同格式传递。商户仍要决定信任哪些声明，以及它们能支持什么操作。

资料边界： 本文于 2026 年 11 月 1 日核对项目官方材料与 2026 年 10 月的 Internet-Draft。本文为资料分析，没有进行商户开户、令牌验签测试或付款演示。所引草案是进行中的工作，不代表 IETF 背书或最终标准。

协议与服务商要分开看

项目的关于页面将 KYA 描述为识别 Agent、被代理用户与意图的方式，KYAPay 在此基础上增加支付凭证。标准化页面则链接了令牌格式、令牌消费与交换等相关工作。

Skyfire 参与协议开发，也提供示例实现。项目仓库将核心令牌材料与示例 API 分开，并说明后续规范工作。因此，评估 Skyfire 服务仍是一项独立的产品评估：账户、商业条款、结算支持和实际可用性，不能仅从协议名称推导出来。

当前令牌草案使用 kya+jwt、pay+jwt 和 kya-pay+jwt 区分身份、支付及组合令牌。接收方需检查签发者、签名、类型、目标受众与时间信息，支付令牌还需要对应的支付检查。

声明消费过程概念图，非商户接入实测。令牌签发或验证成功，不等于付款已经完成。

身份令牌即使写明客户，也不能直接当作支付授权。反过来，支付凭证也未必包含商户需要的全部身份属性。验收策略应围绕实际令牌职责和必要证据制定。

接入审查首先要问：商户接受哪些签发者，这份信任名单怎样维护？一个陌生签发者的数学签名有效，不代表商户已经决定信任它的声明。

接着再检查令牌与本次请求的关系：目标受众、环境、服务、客户账户，以及适用时的金额。沙箱凭证不能因为使用同一个解析器，就变成生产购买。可选声明缺失时，应保留“未提供”，不要用推测补齐后标成“已验证”。

令牌消费草案定义 HTTP 请求头传递方式，也讨论了 bearer 令牌与持有证明绑定。接入方必须明确实际强制执行哪种模式。仅附带令牌，不能证明当前请求方还持有某个绑定的签名密钥。

令牌草案明确区分完整性与保密性：拿到签名 JWT 的一方，可以读取其中声明。文档要求受保护传输和限制披露，并禁止把卡主账号（PAN）或静态卡校验值放进所定义的结算字段。

产品团队应把它落实为数据流审查，而不是只写进隐私说明。列出可能接触令牌的边缘服务、源站、日志系统和客服工具。能存安全关联编号时，不要把完整凭证写进分析事件；排错也应避免将用户身份与支付材料复制到模型对话里。

令牌消费草案同样将该请求头视为敏感、与请求相关的凭证。如果由中间层验签，需要约定向源站传什么验证结果，并防止不受信任客户端直接伪造同样的结果字段。

实用的验收计划应包含：令牌已过期、受众错误、签发者不受信任、类型不支持，以及身份有效但缺少付款权限。还应按实际使用的 bearer 或持有证明模式测试重复请求。

付款提交后超时，应保留尝试编号并查询支付结果。重新取得令牌，不应自动触发第二次扣款。同样，凭证到期也不会自动撤回已经完成的付款。

这些是建议测试和操作规则，不是某个 KYAPay 服务商已通过的结果。编写测试样例前，应锁定令牌配置与接收端版本；较早发布材料里的示例，不应静默覆盖后续草案的字段定义。

当 Agent 请求需要携带被代理主体的声明，或同时携带支付信息时，KYA/KYAPay 值得评估。它与 Web Bot Auth 相邻，后者关注 HTTP 请求签名认证，但两者携带的证据和支持的决定并不相同。

我们的建议是，只传递具体交易需要的声明，明确签发者信任，并独立记录支付结果。官方入口见 KYA/KYAPay 目录条目，协议兼容与服务商开户应分别验收。