Cross-verification proposal: QWED attestation verdicts against independence failure vectors

[andysalvo]

We maintain substrate-attestation, a conformance fixture suite for verifier-issued trust evidence in the A2A ecosystem. We just shipped ambiguous_issuer_binding vectors that test what happens when two attestations from non-independent issuers are composed.

Reading your codebase, QWED's crypto.py issues JWT attestations with issuer_id binding and jti replay prevention. Your trust_boundary.py enforces per-pair allowlists. Both are sound for single-hop verification.

The gap we're testing: what happens when TWO QWED interceptors, each issuing valid JWT attestations, are composed by a downstream consumer? If both interceptors share infrastructure or use the same signing keys, a naive consumer treats two passing attestations as independent confirmation when they're actually one opinion from one source.

Our ambiguous_issuer_binding fixtures (4 vectors) test this:

• amb-001: shared infrastructure, different issuer_ids -- should REJECT composition
• amb-002: same verification engine, different wrappers -- should REJECT
• amb-003: circular attestation (A cites B cites A) -- should REJECT
• amb-004: genuinely independent composition -- should ACCEPT

Proposal: run these vectors against QWED's attestation pipeline and share the results. We'll add the outcome to our conformance matrix as a new entry. No byte-matching, no hash confirmations -- just a test that can fail.

If this is interesting, we can also run QWED's own test suite through our conformance harness in the other direction.

[rahuldass19]

Hi Andy Salvo (@andysalvo),
I appreciate the issue, it's a sharp observation.

But it sits just outside what QWED-A2A (and the whole QWED ecosystem) is meant to do. QWED-A2A verifies individual messages and emits an attestation per verdict, that's the whole job. It deliberately doesn't aggregate trust or compose attestations, and it isn't going to start: the moment you're weighing how independent two issuers are, you're in probabilistic/confidence-scoring territory, and QWED is built specifically to avoid that (deterministic checks, Z3/SMT, no "how much do we trust this" math).

So independence and composition are real concerns, they just belong to the downstream consumer/orchestrator deciding how to treat multiple attestations, not to the verification boundary issuing them.

Happy to keep this open as a discussion if it's useful to you or others thinking about the same layer.

[andysalvo]

That's exactly the boundary we were hoping to find. QWED issues deterministic verdicts; the composition question belongs downstream. We're building that downstream layer -- the part that takes multiple attestations from independent verifiers and measures whether they actually compose into a stronger trust signal or just echo the same source.

One question that would help our design: what's the minimal attestation metadata QWED emits that a downstream compositor should rely on? Specifically: issuer ID, verdict scope, message hash, timestamp -- is there anything else in the JWT claims that a composition layer should treat as load-bearing?

Appreciate the clarity. Leaving this open as reference.

[rahuldass19]

Here's what's actually in the token today (from crypto.py), so you're building against what's real rather than what I might describe loosely:

Standard JWT claims

• iss — issuer ID
• sub — SHA-256 hash of the verified payload (the message hash)
• iat / exp — issued-at and expiry (5-minute window, one hop's lifetime)
• jti — unique trace ID, also used for replay prevention

qwed_a2a block

• verdict — forwarded / blocked / unverifiable
• engine — which verification engine produced the verdict
• sender / receiver — the agent pair
• deployment_id — the logical deployment that issued it
• session_id — optional, caller-supplied
• version

Header

• kid — key ID ({issuer_id}#signing-key-v1)
• typ — qwed-a2a-attestation+jwt
• alg — ES256

For a compositor specifically, the two I'd treat as load-bearing for independence are deployment_id and kid. Two tokens with different iss but the same deployment_id or kid are almost certainly the same source wearing different labels that's your amb-001/amb-002 case, detectable from claims we already emit. iss alone isn't sufficient for an independence judgment, since nothing stops one deployment from signing under multiple issuer IDs.

One honest caveat: these claims are stable for current use, but we haven't frozen them as an interop contract so I wouldn't hard-code against the exact shape yet. If a real composition use case firms up, that's a good reason to talk about versioning the claim set properly.

[andysalvo]

This is exactly what we needed. deployment_id and kid as the load-bearing independence signals makes the composition rule concrete: if two tokens share either, the compositor treats them as one source regardless of iss.

We'll build a draft compositor against this claim set and share it. Two things that would help:

1. Is there a JWKS endpoint or key manifest we can resolve kid against, or is key exchange out-of-band for now?
2. Would it be useful to treat this as a draft-1 contract? We can pin our compositor to a declared schema version so neither side breaks silently if claims evolve.

No rush on either. We'll prototype against the shape you described and post what we learn.

[rahuldass19]

Good, glad deployment_id + kid give you a concrete rule.

On your two questions:

1. JWKS / key resolution - out-of-band today.
There's no JWKS endpoint or published key-distribution mechanism. The A2A surface only exposes /a2a/intercept, /a2a/health, and /a2a/metrics - no key-serving route. Each service verifies against its own key pair, so the current model assumes same-key/same-deployment verification rather than cross-issuer public-key resolution. Flagging that explicitly because it shapes what your compositor can resolve: composing tokens from genuinely separate deployments has no published-key path to verify against right now. Key exchange is out-of-band.

2. Draft-1 contract - not yet, and I'd rather not pin it prematurely.
The claim set is stable for current use, but freezing it into a declared interop contract is a commitment I don't want to make off the back of a single prototype. A contract implies versioning guarantees, deprecation handling, and back-compat on our side, worth doing when there's a real composition use case with more than one consumer, not before.

That said, you don't need a frozen contract to avoid silent breakage: we already emit a version field in the qwed_a2a block. Pin your compositor to expect version: "1.0" and treat anything else as "schema changed, re-check" that gives you the break-detection you're after without either side committing to a contract yet.

If a real use case firms up and there's appetite for a published key path and a versioned claim schema, that's a proper design conversation worth having. Keep us posted on what the prototype turns up.

[andysalvo]

The compositor prototype is public at github.com/andysalvo/crest-compositor. Pinned to version: "1.0" as you suggested.

What it does today:

• Validates QWED-format JWT structure (header typ/alg, claim shape, expiry, jti replay)
• Extracts deployment_id + kid as independence signals
• Composes multiple attestations: consensus-verified if independent, independence-unverifiable if not
• 16 adversarial tests passing (shared deployment_id, shared kid after rotation, circular evidence refs, mixed verdicts, N-way partial collisions)

What it cannot do without a key path:

• Cross-deployment signature verification (requires pre-shared keys, no JWKS discovery)
• The independence check works on claim-level signals, not cryptographic proof of distinct signers

This is an honest limitation. The compositor trusts the claims if the token parses correctly, but cannot prove the signing key actually belongs to the claimed deployment without out-of-band key exchange.

If anything looks wrong against your actual token shape, that is exactly the feedback we need.

[rahuldass19]

Nice, thanks for building it in the open and for being upfront about the limitations (the "trusts claims, can't prove the signer without out-of-band keys" caveat is exactly the right thing to state loudly).

Two things against our actual token shape, since you asked:

1. Verdict values. QWED-A2A emits forwarded / blocked / unverifiable - not PASS. Your README example mixes verdict="PASS" and verdict="forwarded"; the QWED adapter should expect the three-value set. PASS may be valid for other verifiers, but it isn't a QWED verdict.

2. evidence_refs isn't a QWED claim. Your circular-reference check (the amb-003 case) keys off evidence_refs, but QWED tokens don't carry that field — it's part of your substrate_attestation shape, not ours. So circular-evidence detection won't apply to QWED-issued tokens as-is. Worth being explicit in the adapter about which signals are QWED-native (deployment_id, kid) vs. supplied by your own format.

One small framing note: I'd avoid calling it a "QWED JWT claim spec" for now - we don't publish a claim specification and the claim shape isn't a frozen interoperability contract. More accurate to say "based on the claims QWED-A2A currently emits, per issue #28."

Otherwise this is a reasonable consumer of the boundary. Keeping the issue open as reference.

[andysalvo]

Thanks Rahul. All three taken; the adapter and docs are updated (crest-compositor).

1. Verdict values. The adapter now enforces an allowlist of forwarded / blocked / unverifiable. Anything outside it, including PASS, is rejected as non-QWED with an explicit error. The README example that mixed PASS and forwarded is removed.

2. evidence_refs. Agreed, it's ours, not yours. The adapter no longer reads evidence_refs from QWED tokens, and every attestation now carries a source_format. The circular-reference check is scoped to substrate-attestation and does not run on qwed-a2a attestations, so the amb-003 case no longer claims to apply to QWED-issued tokens. For the fields this adapter consumes, the boundary is explicit in code: deployment_id, kid, and verdict are QWED-emitted; evidence_refs and the circular-reference analysis are crest-supplied.

3. Framing. Adopted your wording: documented as "based on the claims QWED-A2A currently emits, per issue #28," not a spec or a frozen contract. Also corrected the docs to state the no-JWKS / out-of-band-keys reality plainly.

We recorded the fix as a public correction (CCR-2026-001) referencing this issue. If the corrected behavior matches what QWED-A2A actually emits, a note here closes the loop, no pressure either way. Thanks for the careful read; keeping #28 open as reference like you said.

[rahuldass19]

That matches what QWED-A2A emits: forwarded / blocked / unverifiable as the verdict set, deployment_id and kid as the QWED-native signals, and evidence_refs correctly treated as crest-supplied rather than QWED-issued.

Just to be precise, this confirms the three points discussed in this thread, not a broader review or endorsement of the compositor itself.

Thanks for the careful follow-through. Happy to leave #28 open as reference.