Proposal: optional causal context binding for AetherProof receipts

[safal207]

Hi @pulkit6732 — following our discussion in karpathy/autoresearch#599, I looked through AetherProof’s receipt model. The existing signed preimage already gives a strong authenticity and tamper-evidence boundary around model root, input commitment, output hash, timestamp, log sequence, hardware evidence, and log anchor.

One optional extension that could make the receipt easier to integrate into agent runtimes is a small causal-context envelope, without changing the core verification model.

For example:

{
"action_id": "act_042",
"run_id": "run_017",
"parent_event_id": "evt_991",
"policy_decision_id": "dec_204",
"evidence_refs": ["mem_12", "file_88"],
"purpose": "tool_authorization | experiment_verification | answer_generation"
}

The invariant would be:

«A cryptographic receipt proves the signed claim is authentic and unmodified; the causal envelope proves which runtime decision and evidence context the claim belongs to.»

This could be implemented in a backward-compatible way as either:

1. an optional canonical "context_commitment" field included in the signed preimage; or
2. a namespaced extension object whose canonical hash is included in the signed preimage.

Benefits:

• binds a receipt to one exact agent action or experiment step;
• prevents a valid receipt from being replayed in a different causal context;
• connects runtime policy decisions to hardware-backed evidence;
• keeps AetherProof provider-neutral and offline-verifiable;
• gives agent frameworks a stable bridge from decision receipts to execution attestation.

A minimal test case could be:

• same output and same hardware evidence, but different "action_id" → different signed receipt;
• same receipt reused under a different "policy_decision_id" → verifier rejects the context mismatch.

I’m happy to draft a compact fixture/schema or a small compatibility test if this direction fits the project.

[pulkit6732]

Aleksey , this is the right extension and the invariant you've stated is exactly correct.
The distinction between authenticity boundary (what the signed preimage currently covers) and causal boundary (what the context envelope would add) is the precise gap that makes replaying valid receipts in wrong contexts possible today. The replay attack you're implying same receipt, different policy_decision_id is a real threat in agentic pipelines and the current schema doesn't prevent it.
Option 2 (namespaced extension whose canonical hash is included in the signed preimage) is the right implementation path. It keeps the core verification model unchanged existing verifiers see a valid receipt while new verifiers can additionally check context integrity. Backward-compatible by construction.
The field set you've proposed maps cleanly onto what I'd call the agent chain layer: each hop in a multi-agent pipeline carries its own receipt, and parent_event_id is what lets you Merkle-aggregate them to a single root without losing the causal structure. purpose as an enum (tool_authorization | experiment_verification | answer_generation) is especially useful it lets a verifier confirm not just that the output is authentic but that it was produced for the declared function.
I'll open a schema branch for this. The minimal test cases you described (same output + different action_id → different receipt; same receipt under different policy_decision_id → context mismatch) are exactly the right fixtures. If you want to draft the canonical JSON schema for the extension object, I'll integrate it and we can co-author the spec note

[safal207]

@pulkit6732 Thank you — I drafted the canonical extension schema and an interoperability note so we have something concrete to review together.

Schema:
https://github.com/safal207/Liminal/blob/main/schemas/agent-chain-context-v0.1.schema.json

Spec draft:
https://github.com/safal207/Liminal/blob/main/docs/interop/AETHERPROOF_AGENT_CHAIN_CONTEXT_V0_1.md

The draft follows your namespaced-extension direction and defines RFC 8785 canonicalization, a SHA-256 context commitment, the proposed agent-chain fields, and the replay/conformance fixtures.

I also documented one compatibility nuance from the current v1.1 implementation: adding an extension hash to the main signed preimage requires a receipt-version-aware verifier. The note therefore defines two profiles:

1. native receipt v1.2 — preferred, with "signed_extensions_hash" appended to the canonical preimage;
2. optional legacy chained binding — preserves a v1.1 receipt byte-for-byte and signs a separate context-binding artifact.

My preference is the clean v1.2 profile. I left the unresolved design choices as explicit co-author questions at the end of the note.

Happy to adapt this draft to your schema branch and co-author the final spec.

[pulkit6732]

Aleksey , this is exactly the right quality of work for where this needs to go.
I've read both documents. The v1.2 native profile is the correct direction appending signed_extensions_hash to the canonical preimage keeps the trust boundary clean and makes context integrity first-class rather than bolted on. The legacy chained binding is worth documenting for backward compatibility but should not be the recommended path forward.
On the co-author questions at the end of the spec . I'll go through them explicitly in the schema branch this week. My immediate positions:
RFC 8785 canonicalization is the right call — deterministic, widely implemented, IETF-aligned
purpose should be an open enum with a registered values registry rather than a closed set — keeps it extensible without breaking conformance
The replay fixture (same receipt, different policy_decision_id → verifier rejects) is the critical conformance test this should be the mandatory test case in the spec
I'll create the schema branch today and open a PR against it. Let's finalize v0.1 together and then I want to discuss submitting this as a companion document to an IETF individual draft I'm preparing on the core receipt format.
This is moving fast — thank you for the rigour.

[safal207]

@pulkit6732 Thank you — I incorporated your three immediate positions into concrete artifacts so the schema branch can start from an aligned base.

Updated schema:
https://github.com/safal207/Liminal/blob/main/schemas/agent-chain-context-v0.1.schema.json

"purpose" is now extensible but registry-bound through the signed "purpose_registry" field.

Initial machine-readable registry:
https://github.com/safal207/Liminal/blob/main/registries/agent-chain-purpose-v0.1.json

Mandatory policy-decision replay fixture:
https://github.com/safal207/Liminal/blob/main/fixtures/aetherproof-agent-chain-context-replay-v0.1.json

Co-author decision log:
https://github.com/safal207/Liminal/blob/main/docs/interop/AETHERPROOF_V0_1_COAUTHOR_DECISIONS.md

I also drafted an early companion-document outline for the IETF discussion:
https://github.com/safal207/Liminal/blob/main/docs/interop/AETHERPROOF_IETF_COMPANION_OUTLINE_V0_1.md

The mandatory fixture makes the critical split explicit:

• core cryptographic verification: "VALID"
• runtime expects another "policy_decision_id"
• context verification: "CONTEXT_MISMATCH"

For the registry model, unknown syntactically valid purposes remain schema-valid, but a verifier requiring registered semantics returns "UNSUPPORTED_PURPOSE". This keeps the format extensible without making purpose semantics ambiguous.

I’m ready to map these artifacts into your schema branch and work through the remaining questions on receipt versioning, parent-reference typing, actor typing, and the normative status of the legacy profile.

[pulkit6732]

Since you drafted against the pipe-joined preimage, AetherProof's signing preimage changed. It is now an injective, length-prefixed encoding — each field is serialized as : and concatenated. This was a security fix: the old "|".join(...) was non-injective, so a | inside any field could shift boundaries and let two different receipts share one preimage (and thus one signature). Length-prefixing closes that.

Why this matters for your extension: appending signed_extensions_hash as one more length-prefixed field is now provably unambiguous — there is no delimiter to collide with, so Profile A is clean by construction. This strengthens your preferred direction.

Already implemented on main (receipt.py): a signed_extensions field whose per-extension SHA-256 commitment is appended to the preimage. Empty extensions → the receipt stays v1.1, byte-identical; non-empty → v1.2. Tests in tests/security/test_v12_extensions.py.

[safal207]

@pulkit6732 I reviewed the v1.2 implementation on main. The length-prefixed preimage and signed extension commitment are a strong base.

I found one important boundary we should make explicit before describing the current aggregation as selectively disclosable.

Today the receipt signs:

root = SHA256(concat(sorted(per_extension_hashes)))

Verification recomputes that root from the complete signed_extensions map. If one namespace or extension body is omitted, the aggregate changes. A verifier cannot validate one disclosed extension against the signed root unless it also receives either:

• every other extension commitment; or
• a Merkle inclusion proof.

So the current implementation provides multi-extension integrity, but not yet standalone selective disclosure.

There is also an interoperability detail to freeze: the documentation says to sort the resulting commitments lexicographically, while the current code iterates over sorted namespace keys. With multiple extensions, those two orders are not guaranteed to match.

I suggest two options:

1. Keep v1.2 minimal: retain the current aggregate and describe disclosure as all-or-nothing.
2. Define a selective-disclosure profile using a domain-separated Merkle root and inclusion proofs.

For v1.2, I recommend option 1. Merkle selective disclosure can remain part of the later Signet L3 profile.

The immediate conformance gate should be a two-extension cross-implementation vector containing:

• exact canonical bytes for each namespace and body;
• exact per-extension hashes;
• the normative sorting rule;
• the expected aggregate hash;
• the final length-prefixed signing preimage.

I can draft that fixture and align the LIMINAL companion specification with the chosen rule.