A2A签名Agent Card：密钥信任引导、可运行验证与授权边界

wiki/ai/sources/a2a-signed-card-trust-bootstrap.md

分类：ai / sources · 更新：2026-09-24 09:22

A2A签名Agent Card：密钥信任引导、可运行验证与授权边界

结论与用户价值

知识轴：A2A / harness-runtime / sandbox-security。 Agent Card签名能证明“这份能力/端点声明未被未持钥者改写”，但前提是客户端先知道信任哪组密钥。让Card自己提供一个任意密钥地址，再用该地址的密钥验证它，不建立身份信任。 A2A-Agent2Agent-Protocol 的发现链应拆成“可信来源→Card完整性→允许使用的端点→调用授权”，不能把签名通过当成整条委托链通过。

对Hermes接入第三方agent，这比“支持A2A”的标签更实用：在向发现的endpoint交付任务或凭据前，先核Card来源、密钥来源、目标与授权；对wiki，也提供了一个可以真正运行的Card验收案例，而不只是协议说明。

来源、新鲜度与实际执行

官方仓库 a2aproject/a2a-python，固定SHA f3ac82489dd84ce9dcd3802357cb4e987ffdbb74；提交时间 2026-09-21T21:21:14Z，本轮09-24读取。提交新增sample/tests/docs，不是签名核心代码首次实现，也不是新release。
读取sample、签名实现、Card resolver及对应测试；归档固定仓库tar与GitHub API回执。获取时 2,155 stars，只作项目标识，不作安全或质量证据。
本机实际运行上游 test_signing.py、test_card_resolver.py、test_agent_card_signing_smoke.py：55 passed，4 warnings。smoke启动真实loopback HTTP server，接受真实签名Card，拒绝端点被改写、签名被剥离、密钥来源不受信任三种情况。
运行位于scratch、使用sandbox-exec限制外网与写入范围；未提供生产凭据。4个warning来自既有HS384测试fixture的短HMAC key，不能把这个fixture复制进生产；本sample使用ES256。未跑完整SDK套件、真实远端delegation、任务stream/push或企业多租户部署。^[raw/notes/ai-radar-evidence-checks-2026-09-24.md]

机制一：验的是规范化Card，不是随意重新序列化的JSON

签名实现去除signatures字段，按当前实现清理空值，再对Card做JCS规范化；签名层签的是规范化UTF-8字节。若先转换成普通dict再交给另一套JSON序列化，非ASCII转义、排序等差异可能改变被签名内容。验证端重建相同payload，再以显式允许的算法验JWS。supportedInterfaces中的URL属于这一声明面，sample改写它后验证失败。^[raw/articles/a2a-signed-card-trust-bootstrap-2026-09-24.md]

这与MCP-Gateway-Runtime的schema/Card hash相邻但不等价：hash用于版本/漂移识别；可信密钥上的签名用于完整性与来源验证；两者都不自动确认后端仍健康、具备宣传的能力或允许当前用户执行。

机制二：异步获取可信JWKS，同步验证只做内存查找

create_signature_verifier接受同步key_provider(kid, jku)。sample先异步抓取客户端固定的JWKS URL集合，按URL和kid建立内存映射；验证时不跟随Card里任意jku发请求，并固定ES256算法。否则同步网络访问会阻塞事件循环；当服务端与客户端在同一事件循环时，还可能把自己堵死。^[raw/articles/a2a-signed-card-trust-bootstrap-2026-09-24.md]

sample以调用者提供的base URL推导可信JWKS地址，适合演示；它没有解决base URL是谁审批的、HTTPS证书/目录信任如何建立、跨组织key轮换/撤销如何生效。生产应把这些责任放在registry/onboarding policy，而非让agent根据Card内容临时决定信任根。

机制三：修改语义、异常语义与可选验证

signer会原地向Card追加signature。sample先复制、启动时签一次，避免每次读取Card都堆积签名。
SDK verifier的策略是“至少一个签名有效”，不是“全部签名有效”或多方会签。sample provider用PyJWKError表达某个key不可用，让验证器继续检查其他signature；任意普通异常未必具有相同语义。
Card resolver的签名验证是调用者显式传入的可选步骤。能够fetch/parse Card，不代表已经verify；sample明确把verifier传给get_agent_card，失败不返回可信Card。^[raw/articles/a2a-signed-card-trust-bootstrap-2026-09-24.md]

可执行实践：把发现验收插在任务委托之前

registry登记owner / approved origin / trusted JWKS / allowed algorithms / endpoint policy；Card声明不能自授这些权限。
抓取并验证Card；记录内容hash、kid、信任配置版本及验证时间；无签名/坏签名/不可信key分别失败，不自动降级到未验Card。
另验实际调用URL、租户/用户授权、token audience、工具副作用范围。参照corti-a2a-binding-parity-and-credential-forwarding按binding核凭据，不跨origin盲传。
在密钥轮换、缓存过期、旧Card重放与多signature组合上补测试。签名接受测试与task生命周期/业务验收分账，沿用Agent-Benchmarks的逐claim证据习惯。

边界与待补证

loopback sample证明了这组实现与选定正反例，不证明未知Card解析输入、任意JWKS网络路径或生产PKI安全。签名也不提供自动的freshness、密钥撤销、运行能力证明、用户同意或跨agent任务owner隔离。下一项有价值的实验不是增加更多“支持签名”描述，而是可信key轮换期间，旧Card与新Card在缓存客户端上分别何时被拒绝/接受。

写入记录

2026-09-24 09:14 CST：新增固定SHA签名/信任引导深读，记录55项上游测试与loopback正反例；明确可选验证、key来源、修改/异常语义及未验证的生产授权边界。