Background
The EOV I-D defines a signed receipt that an agent's harness issues at each action boundary. The receipt binds: invocation ID, agent identity, action type, input/output/context hashes, model version, context epoch, and an Ed25519 signature. Auditors use receipts to verify that a specific action was taken, by that specific agent, under that specific authorization — without trusting the agent's self-report.
The draft's design touches six independent bodies of IETF work. Posting to each WG serves two purposes: finding the right canonical home for the eventual RFC track, and stress-testing each design decision against the relevant community.
RATS — Remote ATtestation procedureS
Question: How do the Evidence / Attestation Result / Relying Party roles from RFC 9334 map to EOV? Specifically: does RFC 9334's separation of Attester and Verifier hold when the same harness both generates and self-attests the receipt?
Proposed mapping: the raw action record is Evidence; the signed receipt is the Attestation Result; the auditor or downstream system is the Relying Party. This fits the passport model from RFC 9334 — but the model assumes Attester and Verifier are typically separate entities.
Also raised: whether EAT (RFC 9528) profiles apply to software agents vs hardware platforms, and whether CoRIM reference manifests could carry model_version and context_epoch for model-substitution detection.
COSE / JOSE — Encoding and signing
Question: Should EOV receipts use COSE_Sign1 or JWS compact serialization as the normative encoding? And what is the right integer label set for a registered COSE profile?
The benchmark run alongside this session answered the size question: COSE_Sign1 with integer-key CBOR labels is 48.8% smaller than JWS compact for a representative EOV receipt. The size gain requires a registered label set — without one, CBOR with string keys saves only 9.2%.
This creates a concrete dependency: EOV needs a COSE label registry entry before COSE can be the normative encoding. That is the kind of question COSE WG is equipped to answer.
SCITT — Supply Chain Integrity, Transparency and Trust
Question: Can EOV receipts be submitted to a SCITT transparency log? The receipt structure matches SCITT's claim model: a signed statement about a subject (the action), issued by an identified issuer (the agent harness), with independent verifiability.
SCITT (RFC 9591) provides the append-only log infrastructure. EOV provides the per-action claim format. The natural integration point is a harness that both signs the receipt and optionally submits it to a SCITT log for organizational auditing.
SPICE — Secure Patterns for Internet CrEdentials
Question: The EOV receipt references the agent's credential via credential_ref (a URI or hash pointing to the issuing authority's record). Does SPICE's selective disclosure / credential binding work apply here?
SPICE addresses credential presentation and privacy-preserving disclosure. For EOV, the question is whether the credential_ref field should be a bare URI, a hash commitment, or a selective-disclosure token that reveals only the necessary binding properties to an auditor.
secdispatch — Where does this belong?
The secdispatch post is the routing question: which working group should own AI agent execution receipt standardization? The candidate homes are RATS (attestation framework), SCITT (transparency log infrastructure), a new WG, or an individual submission track.
secdispatch is the right place to resolve this before the I-D spends more time in an ambiguous home. A routing decision from the list would clarify whether to target RATS adoption, SCITT integration, or a new chartered effort.
What the responses reveal
Early signals: RATS and SCITT are the most natural homes. The COSE label registry dependency is concrete and tractable. The secdispatch routing is the gating question — without a WG home, the I-D can advance as an individual submission but cannot move to standards track.
The most important open design question that the WG dialogue surfaced: the self-attestation problem. RFC 9334 assumes Attester and Verifier are different parties. In most agentic deployments, the same harness generates and signs the receipt. Whether this is an accepted variant or a model violation is unresolved and worth a direct RATS list question.