AgentCard signing example cannot be verified as published

[aeoess]

Section 8.4 publishes a canonicalization example, a JOSE protected header and an ES256 signature. I checked the canonicalization example independently against the proto presence rules and that part reproduces.

The signature example is not independently checkable, though. There is no verification key published with it, and the jku points to example.com. It also does not say which payload the signature covers. The canonical form in 8.4.1 is for a small fragment, and 8.4.2 only says "given a canonical Agent Card payload".

That means an implementation can test canonicalization, but cannot verify the published signature against anything.

Could the example include the public verification key used for the signature, and state the exact payload it was computed over?

One related detail: the same signature also appears on the full sample AgentCard in 8.5, but the canonical payload for that full card is not published.

For a golden test I think the useful split is:

• canonical JSON must equal the published canonical form
• the published signature must verify with the published test key
• generated ES256 signatures should verify, rather than requiring byte equality unless the signing procedure also fixes the ECDSA nonce

I reproduced this against spec main afda8316.

[eriknewton]

Good catch. The #2219 appendix (jcs_edge_v1) already carries the canonical-form half of your test as a pinned, hash-verified vector set; one implementer ran it independently this week and the result discriminated as designed. It stops short of signature verification. Your three-part split (canonical form, verification against a published test key, generated signatures verified without byte equality) fits that appendix as a follow-on: a published key plus the covered payload, stated. One question before I draft it: should the published test key live in the profile beside the vectors, or in the spec body next to 8.4? I lean profile.

[aeoess]

I think next to 8.4. The issue I hit is that the worked example can't be verified from the spec on its own, so the key and the exact signed payload should live with the example in 8.4.2.

A machine-readable copy alongside the broader edge corpus in the profile appendix would be useful too, but putting it only there would still leave the spec example unverifiable by itself.

[eriknewton]

Agreed: the key and the exact covered payload go in the spec body beside the 8.4.2 example, so the worked example verifies on its own, with a machine-readable copy in the profile appendix beside the vectors. I will draft it that way as the follow-on to the #2219 appendix and raise the placement at Tuesday's TSC alongside the depth bound.

[chgaowei]

Agree: the worked example needs a published verification key and the exact covered payload beside §8.4.2, not only in an edge appendix.

One profile we run in production binds Agent Card / description keys through a resolvable W3C DID (did:wba, fetched over ordinary HTTPS). Verifiers resolve the DID document to the current key rather than trusting a signer-supplied jku. The method stays a profile choice; the join key is kid → DID document → key. Happy to try a golden vector whose issuer/kid resolves via did:wba once the test key lands. Not claiming A2A conformance.

https://github.com/agent-network-protocol/AgentNetworkProtocol

[sanskarjaiswal2001]

Agree on putting the key next to 8.4.2. A few things I noticed while reading through 8.4:

• Unless someone still has the private key behind the current signature, we'll have to re-sign with a fresh test key. Might as well publish the private half too, so people can test signing and not only verification.
• If we sign the 8.5 sample card and use that as the 8.4.2 example, one payload covers both sections and fixes the 8.5 gap.
• Publishing the intermediate steps (canonical JSON, base64url payload, signing input) would make it much easier to tell where a failure comes from.
• 8.4.2 step 1 and 8.4.3 step 3 say "remove properties with default values", but 8.4.1 keeps explicitly set optional fields like streaming: false. A golden vector will hit that right away.

Also related: #2099 changes 8.4.2 and 8.4.3 so that jku is only a hint and verifiers get keys from their own trusted store (with kid picking the key). The new example should probably follow that, so the test key is shown as one the verifier already trusts and not one fetched from jku. That also lines up with the kid → DID flow @chgaowei mentioned. Both touch the same text, so landing #2099 first would avoid conflicts.

[aeoess]

Checked both against main.

There is a conflict around default values. AgentCapabilities.streaming is optional bool in a2a.proto, so 8.4.1 keeps an explicit false in the payload, while 8.4.2 step 1 and 8.4.3 step 3 say to remove properties with default values. A golden vector will pass or fail depending on which rule an implementation follows, so the wording should be settled before the example is re-signed.

Agree on landing #2099 first. Right now 8.4.3 step 2 lets the key come from jku, which the signer chooses. Showing the test key as one the verifier already trusts keeps the example from teaching readers to fetch keys from a URL the signer picked.

And yes to publishing the private key and the intermediate steps. For a test vector that only helps, and the canonical JSON, payload and signing input are what make a failing implementation debuggable.

[eriknewton]

Confirmed against main. 8.4.1 rule 1 keeps an optional field that was explicitly set, and its worked example prints the canonical payload with both flags in it. 8.4.2 step 1 and 8.4.3 step 3 both say to remove properties with default values, with no carve-out for the optional keyword. A verifier that follows 8.4.3 literally strips the two flags the signed payload contains, so the signature on the spec's own example cannot verify.

That makes this a contradiction inside one section rather than a disagreement between implementations, which I think makes it decidable in one ruling: have both procedures defer to 8.4.1 rule 1. I am raising it at today's TSC alongside the depth bound and the key placement.

[eriknewton]

Data point from a2a-go #441, merged today at 012cc749. @aeoess found there that a card Go signs with description: "" or skills: [] fails verification in Python: Go canonicalizes the received JSON as is and keeps those REQUIRED fields, while Python rebuilds the card and drops them. The Go maintainer's reply reads Python as non-compliant, which is the 8.4.1 rule 1 reading. Go's new golden vector is generated by a2a-python and contains no empty REQUIRED fields, so Go's tests agree with Python on every case they cover and never exercise this one. The field-presence vectors held back in a2a-tck #228 cover it once 8.4 is ruled.