Verifier-side requirements and failure semantics for agent evidence (input to candidate themes 3 and 6)

Two of the candidate themes from the 29 July meeting — Remote Attestation for Agentic AI, and Agent Identity and Trust Stack — share a gap that is worth naming while the charters are still being drafted: both are currently framed from the producer side (how an agent proves identity, how a runtime is attested), and stay thin on the consumer side — what a relying party MUST check before acting on that proof, and what happens when a check fails.

From building and operating open verifier tooling in this space (tyche-institute/eatf-verifier, Apache-2.0; reproducible negative-case suites for agent evidence), two concrete proposals for the charter text:

1. Verifier obligations as first-class deliverable content. Whatever TR/TS these groups produce, the appraisal side should be specified as distinct, individually testable checks — identifier control; freshness/replay; authorization scope for the requested operation; attestation appraisal for deployments that need it — with normative failure semantics (which cases MUST reject, and whether failure classes are distinguishable). Interoperability breaks less when implementations verify differently than when they fail differently: one rejects, another logs and proceeds.

2. Negative conformance vectors alongside the spec. Deterministic frozen test cases — correctly-signed but out-of-mandate actions, replayed or expired delegations, malformed evidence against fail-open verifiers — so implementers can prove their enforcement layer rejects what it must. We would be glad to contribute a starter set aligned to whatever schema the groups adopt.

Both proposals fit either theme; if the September consolidation merges these themes into fewer groups, the verifier-side content survives the merge intact.

Anton Sokolov, Tyche Institute
(participant; interest in both topics registered with the secretariat 16 Aug)