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

Đang mở
  • Có gì không ổn?
#1,299 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend-api-design, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
510
Fork
196
Merge trung bình
2 ngày 4 giờ
Pull request đã merge (30 ngày)
57

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của a2aproject/a2a-java

Tất cả issue của a2aproject/a2a-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.