Agent Card signature verification (spec §8.4) is missing from the Java SDK

未关闭
  • 哪里不对？
#1,299 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
技术栈
java
领域
backend-api-design, security

调研方向

Start by reading the Java SDK’s AgentCardSignature record and A2ACardResolver, then compare the Python signing interoperability vectors and canonicalization vectors named in the issue. Before implementation, agree on the verification scope, shared module location, and resolver integration; the issue also flags unresolved canonicalization details in spec issue #2122. Done means Java verifies the agreed interoperable cases and rejects the specified invalid signatures.

由索引模型根据 Issue 内容生成。

描述

The A2A spec defines JWS signatures over the Agent Card in §8.4, and the other SDKs implement them:

  • a2a-python — src/a2a/utils/signing.py plus _jcs.py for RFC 8785 canonicalization
  • a2a-js — src/signature.ts
  • a2a-go — a2acrypto/

In a2a-java there is nothing behind it. AgentCardSignature in spec is a data record that carries protected, signature and header, and A2ACardResolver fetches a card and deserializes it with no verification step and no hook to add one. So a Java client cannot tell a signed card from an unsigned one, and the signatures field it parses is decoration.

That matters most where the card is fetched over a channel the client does not fully control, or served by a registry rather than the agent itself — which is the case §8.4 exists for.

What I would like to agree on before writing anything

  1. Scope of a first slice. Verification only — verify(AgentCard, PublicKey) / a JWKSet-backed resolver — with signing left for later, or both at once?
  2. Where it lives. A new spec-adjacent module, or http-client next to A2ACardResolver? It needs to be usable from the gRPC and REST transports too, which argues for somewhere neutral.
  3. How it plugs into A2ACardResolver. Opt-in strategy object, default no-op? I would rather not change the default behaviour of a card fetch in a patch release.
  4. Dependencies. ES256 is reachable through the JDK's own JCA (SHA256withECDSAinP1363Format), and RFC 8785 canonicalization is a few hundred lines, so this can land with no new dependency. The alternative is nimbus-jose-jwt. I lean to no new dependency; say the word if you would rather have the library.

On interop testing. a2a-python publishes language-neutral vectors — tests/utils/signing_interop_vectors.json (MUST-ACCEPT and MUST-REJECT cases with expected canonical bytes and a published test key) and jcs_vectors.json. Those make the whole thing verifiable offline with no network and no credentials, and they pin us to the same canonical bytes the other SDKs produce.

One caveat worth stating up front: spec issue #2122 notes that §8.4.1 canonicalization is under-determined and that two SDKs disagree on parts of it. I would scope the first slice to the vectors that do not depend on that ambiguity, and leave the disputed cases until the spec settles, rather than encoding one SDK's reading into Java.

Happy to take this on if the direction is right — I would rather agree on 1–3 first than send a PR that guesses.

主要语言
Java
星标
510
派生
196
平均合并
2 天 4 小时
30 天内合并 PR
57

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

a2aproject/a2a-java 的其他 Issue

查看 a2aproject/a2a-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。