Prove it

Conformance

A specification you cannot test is an opinion. This page maps every spec on this site to the artifacts that prove an implementation conforms: byte-pinned fixtures, reference verifiers, parity gates, and machine-readable profiles — or an honest statement that no suite exists yet.

Note

How the fixture suites keep themselves honest

Each suite pins fixture bytes in a MANIFEST.sha256, and CI re-runs on every push: both reference verifiers must reproduce each fixture's pinned verdict, the fixture generator must reproduce the committed bytes exactly, a parity gate must show the Go and Python verifiers agree per fixture on verdict and reject category, and a conformance.json profile — derived from the fixtures themselves, so it cannot drift — must match. Negative fixtures are valid in every respect except the one defect they pin, so skipping a single verification step is caught.

CHECKER

Check a payload in your browser

Paste an ATX credential, AIP transcript, DID Document, ATP proof or tree head, or grant reference — structure validates against the published schemas, signatures verify with real crypto, and every failure cites its clause.

SELF-CERTIFY

Declare a conformance level

Walk the AIP, ATP, or ABGS ladder requirement by requirement and produce a publishable attestation JSON — a precise claim, not a badge.

Tip

The schemas resolve

The JSON Schemas the spec repositories publish are served on this site at their $id URLs — specs.opena2a.org/schemas/<spec>/… — as byte-exact vendored copies, hash-pinned in schemas/MANIFEST.json and drift-gated against the pinned upstream commits in CI. A validator that dereferences a $id gets exactly the bytes the spec repo ships. The neighbouring a2a-idf interop suite (Node+Python verifiers over hybrid identity documents) lives at a2a-idf-conformance — it tests A2A-project identity-document interop rather than an opena2a-family spec, so it sits beside this matrix rather than in it.

The matrix

Spec	Version · status	Governance	Conformance surface	Try it
did:opena2a Decentralized Identifier Method	0.1.0-draft Registered with W3C (did-extensions merged 2026-07-04)	W3C W3C DID method registry (merged 2026-07-04)	via atx-conformance, atp-conformance, aip-conformance: all three suites exercise did:opena2a identifiers in their byte-pinned fixtures; no dedicated DID suite.	Lab lesson
AIP Agent Identity Protocol	1.0.0-draft Filed as IETF Internet-Draft (draft-fane-opena2a-aip-00)	OpenA2A IETF (individual Internet-Draft, filed 2026-07-06)	aip-conformance — 4 byte-pinned fixtures (1 accept, 3 reject), verifiers in Go + Python. AIP §5.1 challenge-response transcripts. conformance.json via atx-conformance: §6.4 AgentTrustCredential is covered transitively (ATX is that credential). via atp-conformance: §5 signed authorize responses share the ATP trust-proof signing form.	Lab lesson
ATX Agent Trust eXtension	1.0.0 Published; v1.1 issued in production	OpenA2A	atx-conformance — 20 byte-pinned fixtures (7 accept, 13 reject), verifiers in Go + Python. v1.0 and v1.1 credentials, incl. degenerate declaredPurpose pins and fold-aware strict-parse rejection of duplicate and case-variant members; plus a Go/Python/TypeScript JCS byte-agreement gate (jcs-vectors). conformance.json	Lab lesson
ATP Agent Trust Protocol	1.0.0-rc1 Release candidate	OpenA2A	atp-conformance — 13 byte-pinned fixtures (7 accept, 6 reject), verifiers in Go + Python. discovery, trust proofs (baseline + hybrid), Signed Tree Head, §5.4/§5.5 transparency proofs, §8.1 revocation body. conformance.json live-endpoint scripts — level1/level2 curl scripts against a running authority; complementary to the offline fixtures.	Lab lesson
AAP Agent Authorization Protocol	0.2.0-draft Filed as IETF Internet-Draft (draft-fane-opena2a-aap-00)	OpenA2A IETF (individual Internet-Draft, filed 2026-07-06)	aap-conformance — 17 byte-pinned fixtures (5 accept, 12 reject), verifiers in Node + Python. the §9 token canonical form (AIT/CGT/DA/BAC, compact + JWS General); ACCEPT tokens reuse the spec repo's generated bytes, and the reject set pins the closed-header, suite-registry, BAC-window, and scope-subset rules. conformance.json Secretless end-to-end broker conformance — the reference implementation carries an in-repo broker conformance test for the runtime CPI flows the offline fixtures do not cover.	Lab lesson
AIM Agent Identity Management	1.0.0 Reference implementation	OpenA2A	via the three suites above: as the reference implementation, AIM is what the suites were built against; its TypeScript verifier (@opena2a/atx-verify) is gated on the ATX fixtures in its own CI.	—
ATM AI Agent Threat Matrix	1.1.0 Published (June 2026)	OpenA2A	evidence audit + machine-readable matrix — a taxonomy, not a protocol: conformance means citing techniques accurately; every technique carries an evidence tier.	—
AIIS AI Injection & Infrastructure Signatures	0.2.1 Active	OpenA2A	JSON Schema + test fixtures — signatures validate against schema/aiis-v0.1.schema.json; tests/fixtures hold match/no-match cases.	—
ABGS Agent Behavioral Governance Specification	1.0.0-draft Draft	OpenA2A	conformance.md (3 levels) via hackmyagent scan-soul — requirements-based levels audited by a scanner (keyword detection); no byte-pinned fixture suite yet — manual audit confirms detections are substantive.	—
ai-safety.txt Domain AI-safety declaration	draft-00 Filed as IETF Internet-Draft (draft-fane-ai-safety-txt-00)	OpenA2A IETF (individual Internet-Draft, filed 2026-07-06)	—	—
OASB Open Agent Security Benchmark	0.3.2 Stable	OpenA2A	OASB is itself the harness — 222 attack scenarios that measure tools; a tool proves coverage by running the benchmark, not by passing fixtures.	—
OTel OTel Semantic Conventions for Agent Identity	Draft / proposal Proposed upstream (OTel #180)	OpenTelemetry OpenTelemetry semantic conventions (proposed, under discussion)	attribute registry (YAML) — conventions, not a protocol: conformance means emitting the registered attributes; upstream review is the gate.	—

Prove your implementation conforms

The fixture suites are SDK-independent: a second-party verifier with only the spec and the public test keypairs must reproduce every ACCEPT and REJECT byte-for-byte. To claim conformance for your own implementation:

Clone the suite for the spec you implement (fixtures are byte-pinned; do not edit them).
Run your verifier over fixtures/and compare against each fixture's expected block — verdict and reject category. The reference verifiers show the exact contract.
Match the reference output. Every fixture must agree; a single divergence is a conformance failure, not a rounding error.
Record it. Each suite's COSIGNERS.mddescribes how to cosign the fixture manifest (Sigstore keyless) and open a PR adding your implementation to the suite's table.

The whole loop, using ATP as the examplebash

git clone https://github.com/opena2a-standards/atp-conformance
cd atp-conformance

# the reference contract: both verifiers, 7 pass / 0 fail
( cd verifiers/go && go run . ../../fixtures )
( cd verifiers/python && pip install -r requirements.txt && python3 verify.py ../../fixtures )

# cross-implementation agreement, machine-readable
python3 scripts/parity/parity.py --json parity-report.json

# now point YOUR verifier at fixtures/ and match every expected block

Caution

What a suite does not prove

Passing fixtures proves your verifier honors the wire contract. It does not prove your issuance is secure, your keys are managed well, or your deployment enforces what the credential says. Each suite's conformance.json lists exactly what is covered, what is covered transitively by a sibling suite, and what is not covered at all — read the notCovered block before citing a badge.