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

オープン
  • 何か問題がありますか？
#1,299 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み PR（30日）
57

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

a2aproject/a2a-java のほかの issue

a2aproject/a2a-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。