Hi @soup-oss, thanks for filing this. The regulatory gap is real and the envelope shape lands close to work already in production.

Two pointers in case they are useful as prior art:

OVERT 1.0 (Glacis Technologies, published 2026-03-25, https://overt.is) defines a related primitive: signed, schema-closed envelopes a relying party can verify offline. Apache-2.0 open standard with a royalty-free patent covenant for conformant implementations. The shape rhymes with SEP-2787 but the design choices differ:

• Encoding: canonical CBOR per RFC 8949 rather than JSON. Smaller wire size and stricter canonicalisation for signature stability across implementations.
• Crypto: Ed25519 signatures over HMAC-SHA256 content commitments. The content commitment lets the request payload stay local while only the HMAC crosses the trust boundary, which matters for privacy and for the EU AI Act Article 12 evidence chain when arguments contain PII or trade secrets.
• Schema: closed 9-field shape with IEEE-754 float rejection. Helps interoperability across multiple emitters.
• Counter: monotonic counter across the emitter process so gaps are detectable on the verifier side.
• Phase 3: the IAP role notary-signs the Provisional Receipt and anchors it in a transparency log, which complements rather than replaces an inline ack callback.

Vaara (https://github.com/vaaraio/vaara, Apache 2.0) ships an MCP proxy that emits OVERT 1.0 Base Envelopes per tools/call, resources/read, and prompts/get since v0.24.0 (released 2026-05-20). Working examples with real upstream MCP servers in examples/github-mcp-proxy-demo/, examples/sap-mcp-proxy-demo/, and examples/goose-mcp-proxy-demo/. The proxy is transparent to both the MCP client and the upstream server, so it works with any stdio MCP server without protocol changes (matches your design constraint).

For the SEP's open design questions:

1. Emitter location. SEP-2787 implies a client-side emitter. The proxy pattern puts the emitter between client and server, which has the benefit that no MCP client needs to change to gain attestation. The trade-off is that the proxy must be deployed. Both shapes are valid and probably both belong in the spec landscape.
2. Argument handling. Your inline-or-resource-URL design is one way. The HMAC-commitment route in OVERT keeps the payload entirely local. The verifier never sees the args, only the commitment they were bound to. For regulated deployments where arguments contain personal data this side-steps a category of disclosure risk.
3. Cryptographic algorithm choice. JWT-family (HS256/ES256/RS256) optimises for ecosystem familiarity. Ed25519 (used in OVERT) gives smaller signatures, no ASN.1/DER awareness needed, and constant-time implementations are simpler to audit. Worth weighing against the JWT-tooling familiarity benefit.

Glacis also ships a Python SDK at https://github.com/Glacis-io/glacis-python (Apache 2.0) as the reference implementation by the standard's authors.

Reference verifier CLI is vaara overt verify RECEIPT.cbor --pubkey-file PUB.bin. The verifier reads only the wire format and takes no dependency on Vaara's emitter, so any OVERT-conformant implementation can route its conformance check through it. Test cases are available if useful for the SEP.

Apache 2.0 throughout, no commercial product.

Thanks for the careful read.

The pre-execution attestation vs post-execution evidence split is exactly the boundary worth making explicit. OVERT 1.0 separates these via the Phase 3 IAP layer, where the relying party notary-signs a Provisional Receipt and anchors it in a transparency log, distinct from the inline ack pattern in SEP-2787. That feels like the cleaner place to land: pre-execution envelope is one primitive, execution receipt is a different primitive composed on top.

On argument handling, OVERT keeps the payload entirely local via an HMAC-SHA256 content commitment. The verifier never sees the args, only the commitment they were bound to. For regulated deployments with PII or trade-secret arguments this side-steps a whole disclosure category. The args_digest / args_ref / args_projection shape maps to the same intent. The digest case is essentially what OVERT does.

Canonicalization: OVERT uses canonical CBOR per RFC 8949 with IEEE-754 float rejection. Stricter than JCS / RFC 8785, but the underlying point is the same: pin the bytes so signatures verify identically across implementations. Whichever the SEP lands on, a normative schema plus explicit canonicalization rules will save reviewers from parser folklore.

On toolCalls as a signed plan bundle vs multi-server workflow: real ambiguity worth resolving in the SEP. OVERT envelopes are per-interaction, which sidesteps the question, but the SEP's bundle shape probably needs an explicit statement on partial-execution semantics and per-verifier replay windows.

The framing of a "stable evidence boundary" lands well. That's the right altitude: bind a tool call to identity, target, args commitment, intent, nonce, key version, and stop there. Outcome receipts and policy decisions compose on top, in separate layers.

Follow-up after sitting with the review longer. Four concrete proposals, bundled so the envelope shape settles in one pass rather than drifting across threads.

On the source of each fact: the cleanest path is to annotate every envelope field with its trust surface. Issuer-asserted fields are set by the attestation issuer (subject, intent, time, nonce, key_version, args commitment). Verifier-asserted fields are set by the MCP server verifier (allow/reject/error reason, observed nonce). Payload-derived fields come deterministically from the request payload (args_digest, args_projection). Planner-declared fields are set by the client or agent upstream of the issuer (declared_purpose, requested_capability). The schema can either tag fields with a source annotation or group them under named blocks. The invariant is that no field gets sourced from "envelope" as an undifferentiated whole.

On argument handling: the current args: string field is overloaded with both inline JSON and resource references. An explicit three-way shape reads cleaner. args_digest is a hash commitment over canonical bytes, privacy-friendly default, payload stays local. args_ref is a content-addressed reference, digest plus retrieval URI. args_projection is a redacted or transformed projection of the args, with its own digest. Implementations pick one per call. The audit invariant becomes "this call was bound to this exact commitment" and inline payload storage is opt-in. OVERT 1.0 does this via its HMAC content commitment.

On canonicalization: the current "sorted keys, no whitespace" rule is too loose for cross-stack conformance. A normative reference to RFC 8785 (JSON Canonicalization Scheme) pins behaviour for numbers, Unicode escaping, duplicate keys, floats, and NaN, the places where language stacks silently disagree. A small JSON Schema accompanying the canonical form makes conformance testing tractable. CBOR per RFC 8949 with IEEE-754 float rejection is the stricter alternative. JCS keeps the JSON ecosystem familiarity at some cost. Either is defensible. The SEP needs to pick one and reference it normatively.

On scope: the optional ack field probably belongs in a follow-up extension rather than this SEP. The stable evidence boundary worth standardizing here is binding a tool call to identity, target, args commitment, intent, nonce, key version. Execution receipts and policy decisions compose on top in separate layers. This keeps the surface tight and lets downstream audit, replay, and receipt systems compose around a clear primitive.

Hi @vaaraio , thank you for this incredible, high-signal feedback.

The work you’ve done with OVERT 1.0 and Vaara is amazing prior art. The privacy-first approach of using HMAC content commitments is a game-changer for handling PII under frameworks like the EU AI Act.

My primary goal with this SEP is ensuring MCP gets a native cryptographic attestation layer so developers can build secure infrastructure around agent intents. Whether the spec leans toward JWT for ecosystem familiarity or adopts a harder-nosed CBOR/commitment model like OVERT, getting this boundary into the protocol is what matters.

I see you’ve opened a related PR, I'll keep an eye on the discussion and try to help how we can align these two shapes

On test vectors: that's the right call. tests/test_attestation_sep2787.py in the reference impl covers the conformance surfaces (signature verification across HS256/ES256/RS256, all three args-commitment shapes, JCS canonicalization invariants, envelope tampering rejection, TTL handling with clock-skew tolerance). Apache 2.0, ready to lift into a standalone normative test-vector artifact.

On implementation neutrality: vaara.attestation.sep2787 is the SEP-2787 envelope only. It does not embed, reference, or imply any downstream receipt system, transparency log, or signed-chain model. A second independent implementation of the same schema interops with this verifier without taking any position on what happens post-execution. The same package ships vaara.attestation.overt as a separate module for the CBOR-based OVERT 1.0 shape, and the two are wire-independent. The mapping in docs/sep2787-overt-mapping.md is a translation table, not a runtime dependency. OVERT 1.0 by Glacis Technologies (Glacis-io/glacis-python) is the empirical parallel: different org, different wire format, same logical layer.

Reference implementation: vaaraio/vaara#139.

@Rul1an agreed. Authorship of the first implementation and ownership of the conformance surface belong in different places. The vectors should live with the SEP. A second implementation validating them is the right gate.

The four conformance dimensions you named (canonical bytes, signature input, verification result, rejection cases) are precisely what tests/test_attestation_sep2787.py exercises today. These can be extracted into a vector set and filed against this PR or a sibling location the SEP wants to maintain. Vaara's repo keeps the implementation, the SEP repo owns the normative artifact.

What format would work best on your side?

@Rul1an v0 fixture set ready against your layout. 40 KB zipped.

Six positive cases: HS256, ES256, RS256 round-trips, plus one fixture each for the digest, ref, and projection args commitment shapes. Each carries unsigned_envelope.json, canonical_signing_input.bin, canonical_signing_input.hex, signed_envelope.json, and expected.json.

Seven negative cases: tampered planner_declared block, tampered issuer_asserted block, expired TTL (signature valid, clock past iat + exp + skew), unsupported alg (HS512), IEEE-754 float in canonical input, invalid args commitment kind, HS256 envelope against an ES256 verifier.

Keys are pinned. hs256_secret.bin is 32 raw bytes. ES256 and RS256 keys are PKCS8 / SPKI PEM. ES256 signatures are raw r||s (64 bytes), not ASN.1 DER. HS256 and RS256 are deterministic so a second implementation re-signing reproduces the stored signature_hex exactly. ES256 signing is randomised, so the ES256 case verifies the stored signature against the pinned public key rather than bit-for-bit reproduction.

The bundle includes _check_independent.py, a verifier that imports only the stdlib plus cryptography and rfc8785. It reads the fixtures from disk and walks the four conformance dimensions with no reference to the reference implementation. Output is six positive OKs, two negative OKs on the pure signature cases, and five SKIPs on verifier-policy cases that depend on the verifier's own clock or schema validator.

Origin and license are in README.md and MANIFEST.json. Apache-2.0, derived from tests/test_attestation_sep2787.py at commit 3d7af54 of vaaraio/vaara. SEP maintainers own the final normative artifact location.

sep-2787-vectors-v0.zip

@Rul1an Filed as #2789, layout under test-vectors/sep-2787/v0/.

normative/ covers signed-envelope round-trips across HS256/ES256/RS256, the three args-commitment shapes (digest, ref, projection), tampering rejection on the planner_declared and issuer_asserted blocks, and IEEE-754 float rejection at the canonicalisation boundary. Nine cases, pass/fail against the SEP-2787 wire format today.

verifier-policy/ covers TTL expiry past iat + exp + skew, unsupported-alg rejection (HS512), schema rejection of unknown args-commitment kinds, and HS256-against-ES256-verifier alg-mismatch. Four cases that depend on an explicit validator-policy paragraph in the SEP before they become normative.

_check_independent.py reads the fixtures from disk and walks the conformance dimensions with no reference to any Apache-2.0 throughout. SEP maintainers own the final layout, including whether the artifact lives at test-vectors/sep-2787/v0/, a sibling path, or in a separate repo. The gate stays the one you named: one independent implementation reads the SEP-owned fixtures and produces the same canonical bytes and signature verification results.

@Rul1an On the argument-commitment binding: the reference impl now wires this as Step 5 in v0.37.1, released a few minutes ago. verify_args_commitment covers the three commitment shapes against the spec text.

For args_ref: resolve via a caller-supplied resolver (the verifier does no network IO), hash the content, match both the stored digest and the canonicalized runtime arguments.

For args_projection: recompute the projection digest, then report projection_match as a tri-state. True for identity projections, False for redacted or summarized projections, where the verifier accepts the signed projection but makes no completeness claim, per your reading.

For args_digest (Vaara's commitment-only shape): recompute the JCS-canonical hash of the runtime arguments and compare to the bound commitment.

Returns ArgsCommitmentResult(ok, reason, projection_match) with reason set to args_commitment_mismatch on failure, matching the spec's error-reason enum.

Composed after the existing signature and TTL checks once the tools/call arguments are in hand. Files: src/vaara/attestation/_sep2787_verifier.py plus 11 tests in tests/test_attestation_sep2787.py.

On the conformance-vector thread: the receipt-verification failure modes coming up here are mostly already normative cases, and they sit in the SEP's own test-vectors tree where a verifier can run them with nothing external in the loop.

In #2789 the SEP-2787 v0 vectors carry the negatives directly: 07-tampered-planner-declared and 08-tampered-issuer-asserted for signature and field tamper, and 09-ieee754-float-in-canonical-input for a non-canonical JCS payload, alongside the HS256/ES256/RS256 positives and a stdlib-only _check_independent.py walker. The receipt layer carries its own negatives in the reference vectors: a broken back-link and a result-commitment mismatch, checked by the same independent walker.

Two of the modes raised here aren't cased yet: an unknown alg identifier, and a replay that substitutes a payload field rather than the verifier time. Both are small. I'll add the alg case to the #2789 set and the replay-substitution case to the receipt vectors, so the negative coverage for this surface is complete and lives in one place implementers already pull from.

Keeping the conformance artifact in the test-vectors tree is the same instinct as keeping v1 thin: an implementer should be able to check an envelope against fixtures in the repo, offline, without taking a dependency on any running service.

Thank you for the suggestion, very useful idea. I have a question: would it be more flexible to have an open-ended list of supported algorithms?

Another idea is to support signing server responses, but it’s a separate SEP.

@kpavlov Thank you. On algorithms — we kept it narrow intentionally. Open-ended algorithm lists sound flexible but create a canonicalization problem: issuer and verifier need to agree on the same name implementation mapping. A small named set with test vectors is more portable. Future SEPs can extend.

One downstream-consumer note: keep correlation handles out of the execution-receipt debate, but preserve them somewhere in the request-attestation surface.

Offline transcript, OTLP, and audit systems need to place an attested tools/call back into the agent tree. The useful handles are:

• session id or run id
• turn id
• tool call id
• parent/child agent lineage when present
• issuer/verifier ids already in the envelope

Those fields do not need to prove execution outcome. They only make the signed request joinable with the local conversation/trace record that produced it. Without that, consumers can verify an attestation but still lose where it sits in the workflow.

Generated with ax.

@Necmttn Thank you for your suggestion, added to the SEP

@Rul1an Noted, thank you for the feedback. We also decided to make the reference field less opinionated to keep the attestation proposal thin.