You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Publish the agent card signing conformance fixture as a standalone suite #93
pkg/crypto/interop_test.go carries an agent card signed by an implementation independent of this one, following A2A specification 8.4 directly, plus the canonical payload that signer computed and the matching public JWK.
It exists because canonicalization is the part of card signing that implementations get wrong quietly: the signature fails, and the failure looks like a key problem rather than a serialization problem. A fixture signed elsewhere is the only cheap way to tell the difference.
Nothing about that fixture is specific to this repository, and as far as I can tell the A2A ecosystem has no shared conformance vector for card signing. Everyone implementing 8.4 is deriving the same edge cases independently, with no way to check themselves.
Proposal
Extract it into a standalone repository that any implementation can run against, in any language:
One or more signed cards with their expected canonical payloads and public keys
Cards that exercise the constructs that break naive implementations:
an optional field explicitly set to a default, which 8.4.1 requires to survive canonicalization
characters that encoding/json and similar encoders escape but RFC 8785 emits literally
non-ASCII object keys, where RFC 8785 sorts by UTF-16 code unit rather than code point
the worked example published in 8.4.1, as a canonicalization-only vector
Negative vectors: tampered cards that must fail, malformed signature entries that must be skipped rather than throw
A plain JSON manifest so the suite is consumable without a Go toolchain
Why bother
Two reasons, in order.
The first is that it is genuinely useful to anyone implementing 8.4, and it costs us almost nothing because the fixture already exists.
The second is that contributing a conformance suite is a more credible way to be known for agent trust than saying we work on agent trust.
Prior art to check first
Before building this, confirm the A2A project does not already have conformance vectors planned or in progress, and if there is an appetite for it upstream, offer it there rather than standing up a parallel repository. A vector suite that lives in the spec repository is worth more than one that lives in ours.
Activity