RFC Proposal: Composable Zero-Knowledge Proofs for TRACE by Trivo25 · Pull Request #162 · agentrust-io/trace-spec

Trivo25 · 2026-08-11T16:08:14Z

What this changes

Adds an informative RFC proposing composable zero-knowledge proofs for TRACE.

The RFC describes ZK and TEE as peer assurance mechanisms that provide different properties and can be used independently or composed depending on the required security, privacy, verification and deployment properties.

In particular, the RFC covers:

ZK-based computation integrity
TEE-based runtime integrity and confidentiality
composition of TEE-authenticated evidence with ZK proofs
privacy-preserving verification and selective disclosure
externally verified, proof-gated downstream actions
external receipts, transparency and evidence durability

The proposal is proof-system neutral and does not require a specific ZK proving system.

This PR is intentionally informative. It does not modify the TRACE wire format, schema, existing trust levels or conformance requirements. Follow-up changes can define normative fields and verification requirements after the assurance model is agreed.

Relates to #161

Type of change

Editorial (typo, link fix, clarification — no normative effect)
Non-breaking spec change (new optional field, new platform profile, informative addition)
Breaking spec change (requires 14-day comment period and Project Lead sign-off)
Schema change
Example addition

Spec section

No normative section of spec/trace-v0.2.md is modified by this PR.

The RFC is relevant to the specification's trust and verification model and proposes an assurance model that can inform future normative changes related to ZK evidence and its composition with existing TEE-backed TRACE evidence.

Checklist

DCO sign-off on all commits (git commit -s)
CHANGELOG.md updated (for any normative change)
Breaking changes marked with  in spec text
Backward compatibility statement included (for breaking changes)

This PR is informative and non-breaking, so no CHANGELOG.md update, breaking-change marker or breaking-change compatibility statement is required.

Signed-off-by: Florian <florian@technotro.com>

imran-siddique

The orthogonal assurance model is the right abstraction, and the non-goals are unusually clear. I left four comments on points that should be tightened at the model level before the representation is deferred to follow-up work. These are distinct from the schema/trust-level/TCB concerns already documented on #161.

Signed-off-by: Florian <florian@technotro.com>

imran-siddique

The four inline points are addressed in the latest commits: the RFC now separates computation integrity from zero-knowledge privacy, requires same-values binding, binds proof-gated actions to request context, and correctly describes the mixed TEE + ZK hardware dependency.

Two issue-level blockers remain before I can sign off:

Compatibility still claims behavior the current verifier cannot provide. The RFC says the proposal is additive and that a verifier without ZK support “should continue to evaluate the existing TRACE evidence.” Since #156, the record schema is closed with additionalProperties: false; an unknown ZK member causes whole-record rejection. Please rewrite Compatibility to say that a named schema member plus verifier support is required, and define the unsupported-mechanism behavior rather than promising graceful degradation that does not exist.
The current trust-level model cannot remain unchanged as written. A ZK-only profile must currently use runtime.platform: software-only and is capped at Level 0 by TR-RTE. That linear result does not express independently verified computation assurance. The informative RFC need not solve the replacement model, but it must acknowledge the required follow-up change to §7 / TR-RTE rather than state that existing levels remain unchanged or must be preserved.

Please also remove the duplicated consecutive definition of “assurance profile.”

Once those statements match the implemented conformance behavior, the assurance-model direction is sound.

imran-siddique · 2026-08-12T16:50:39Z

Flagging a state mismatch before this goes further: this PR is still the pre-review draft. Its head, florian/zk-trace, is the original 332-line RFC with no MUST in it. The five changes you applied are on florian/zk-trace-review-fixes, which is 410 lines and still sits behind an open PR against your own fork. Merging #162 as it stands would land the version we all agreed needs rewriting.

Could you merge Trivo25#1 into florian/zk-trace so this PR picks the changes up? Nothing else needs to move for that.

One item from the #161 thread is still open and is not in the review-fixes branch either.

A ZK-bearing record still carries eat_profile: tag:agentrust-io.com,2026:trace-v0.2. Spec §2 says a v0.2 verifier MUST require exactly that URI and MUST NOT accept both, and verify_record enforces it before any cryptographic work. So a correct v0.2 verifier meets a record that truthfully claims v0.2, carrying semantics v0.2 does not define, and rejects it. That is the failure the profile URI exists to prevent, arriving through the front door.

This is the same shape as lywinged's compatibility finding, one layer up. #156 closed the additive path at the schema, and the profile URI closes it again at the version identifier. Both point the same way: composable assurance needs its own profile URI rather than an extension inside v0.2, and the RFC should say so in Compatibility rather than leaving a reader to assume a ZK block can ride along.

The direction is still right and the model holds. This is about the RFC describing the constraints as they actually are today.

RFC: Address assurance-model review feedback

Signed-off-by: Florian <florian@technotro.com>

Trivo25 · 2026-08-12T17:03:51Z

Flagging a state mismatch before this goes further: this PR is still the pre-review draft. Its head, florian/zk-trace, is the original 332-line RFC with no MUST in it. The five changes you applied are on florian/zk-trace-review-fixes, which is 410 lines and still sits behind an open PR against your own fork. Merging #162 as it stands would land the version we all agreed needs rewriting.

Could you merge Trivo25#1 into florian/zk-trace so this PR picks the changes up? Nothing else needs to move for that.

One item from the #161 thread is still open and is not in the review-fixes branch either.

A ZK-bearing record still carries eat_profile: tag:agentrust-io.com,2026:trace-v0.2. Spec §2 says a v0.2 verifier MUST require exactly that URI and MUST NOT accept both, and verify_record enforces it before any cryptographic work. So a correct v0.2 verifier meets a record that truthfully claims v0.2, carrying semantics v0.2 does not define, and rejects it. That is the failure the profile URI exists to prevent, arriving through the front door.

This is the same shape as lywinged's compatibility finding, one layer up. #156 closed the additive path at the schema, and the profile URI closes it again at the version identifier. Both point the same way: composable assurance needs its own profile URI rather than an extension inside v0.2, and the RFC should say so in Compatibility rather than leaving a reader to assume a ZK block can ride along.

The direction is still right and the model holds. This is about the RFC describing the constraints as they actually are today.

see 1b56d15

lywinged · 2026-08-12T17:35:39Z

Two small things in support of the direction 1b56d15 settles on, both from running it on 5367970.

The profile check also runs before schema validation, not only before the cryptographic work — so the distinct-profile decision changes which error a relying party sees, and it is already load-bearing today:

eat_profile = ...:trace-v0.2      + zk_assurance member
  -> Additional properties are not allowed ('zk_assurance' was unexpected)

eat_profile = ...:trace-v0.2-zk   + zk_assurance member
  -> record profile 'tag:agentrust-io.com,2026:trace-v0.2-zk' is not
     'tag:agentrust-io.com,2026:trace-v0.2'. Verification is refused rather
     than attempted

A ZK-bearing record under its own profile URI tells a relying party "I do not implement this profile" rather than "this record is malformed". Since eat_profile is a const in the schema, every deployed v0.2 verifier already declines a new profile URI correctly, with no change to any of them.

On the named-member shape, since Compatibility now points at it: I tried it — zk_assurance alongside delegation and tool_transcript, with proof_system, program_id, input_commitment, proof.

existing suite            345 passed
record without the block  verifies
record with the block     verifies
malformed program_id      rejected (fails closed)
tampered zk block         rejected - the record signature already covers it

The last line is the concrete form of the integrity argument the section makes. One trap that is not obvious and cost me a run: schema/trace-claim.json and src/agentrust_trace/schema/trace-v0.2.json have to be changed together, or test_packaged_schema_matches_the_normative_schema fails.

Trivo25 · 2026-08-12T17:55:42Z

Two small things in support of the direction 1b56d15 settles on, both from running it on 5367970.

The profile check also runs before schema validation, not only before the cryptographic work — so the distinct-profile decision changes which error a relying party sees, and it is already load-bearing today:
eat_profile = ...:trace-v0.2      + zk_assurance member
  -> Additional properties are not allowed ('zk_assurance' was unexpected)

eat_profile = ...:trace-v0.2-zk   + zk_assurance member
  -> record profile 'tag:agentrust-io.com,2026:trace-v0.2-zk' is not
     'tag:agentrust-io.com,2026:trace-v0.2'. Verification is refused rather
     than attempted
A ZK-bearing record under its own profile URI tells a relying party "I do not implement this profile" rather than "this record is malformed". Since eat_profile is a const in the schema, every deployed v0.2 verifier already declines a new profile URI correctly, with no change to any of them.

On the named-member shape, since Compatibility now points at it: I tried it — zk_assurance alongside delegation and tool_transcript, with proof_system, program_id, input_commitment, proof.
existing suite            345 passed
record without the block  verifies
record with the block     verifies
malformed program_id      rejected (fails closed)
tampered zk block         rejected - the record signature already covers it
The last line is the concrete form of the integrity argument the section makes. One trap that is not obvious and cost me a run: schema/trace-claim.json and src/agentrust_trace/schema/trace-v0.2.json have to be changed together, or test_packaged_schema_matches_the_normative_schema fails.

Thanks for testing! I added a quick disclaimer 34e3bf6

Trivo25 · 2026-08-14T05:58:25Z

Hey @imran-siddique @lywinged! I think all comments should now be addressed, let me know how you would like to continue 🙏

lywinged · 2026-08-14T06:43:03Z

Hey @imran-siddique @lywinged! I think all comments should now be addressed, let me know how you would like to continue 🙏

Thanks for turning all of that around so quickly - the revisions read well.
Both points I raised are in at 34e3bf6:

ZK evidence as an explicit signed TRACE member rather than a detached
envelope, so its integrity is bound to the record signature (line 398).
Profile rejection ordered before schema and cryptographic verification,
so an existing v0.2 verifier fails closed on an unsupported profile
rather than reporting a malformed v0.2 record (line 408).

Nothing further from me - I'm satisfied on my side.

One thing I'd put to @imran-siddique rather than to you, since it came out
of his review: line 280 carries MUST, and it is the only uppercase RFC 2119
keyword in the file, while line 394 states the RFC is informative. Both
readings are reasonable and I don't think it's yours to guess - either the
program_id rule is meant to bind, or the keyword lowercases. Small either
way. (Mentioning it because I've opened a repository-level guard for
requirement keywords outside the spec, and it would flag that line - I'd
rather you heard it from me than from CI.)

How to continue is Imran's call. Happy to pick up any of the follow-up work
once he's set the direction.

imran-siddique

The substantive compatibility and assurance-model revisions are now present. One blocker remains after #175 landed: this RFC declares itself informative but line 280 carries its only uppercase RFC 2119 MUST. Please lowercase that statement (or move a binding requirement into the normative spec through the spec-change process). On the next branch update, the new repository guard will enforce this distinction mechanically.

Trivo25 · 2026-08-14T18:09:13Z

The substantive compatibility and assurance-model revisions are now present. One blocker remains after #175 landed: this RFC declares itself informative but line 280 carries its only uppercase RFC 2119 MUST. Please lowercase that statement (or move a binding requirement into the normative spec through the spec-change process). On the next branch update, the new repository guard will enforce this distinction mechanically.

24bed3a

imran-siddique

All prior assurance-model and compatibility findings are addressed on the current head. The RFC now separates computation soundness from zero-knowledge privacy, requires same-values and request-context binding, treats TEE/ZK as orthogonal mechanisms, acknowledges the required conformance-model follow-up, and requires a distinct future EAT profile under the current closed-schema/versioning rules. It remains informative: the repository keyword audit finds no uppercase RFC 2119 requirements. Local evidence: python -m pytest -q -> 339 passed, 1 skipped. Approved.

8380993 ("unhide ten pages", 2026-08-19) added ten nav entries, one of them docs/rfcs/composable-zk-assurance.md, which had landed in agentrust-io#162 three days earlier without one. agentrust-io#184 merged four days after that sweep and did not touch mkdocs.yml, so docs/rfcs/a2a-delegation-profile.md is the eleventh page in the same state. Nothing in agentrust-io#184's description, comments or reviews mentions the nav. It is not unreachable — CHANGELOG.md links it, examples/delegation-link/README.md links it, it is in sitemap.xml, and the search index carries 13 entries. What it has no path from is the navigation. Measured by reproducing the deployed build rather than a local one: .docs_build assembled as docs.yml assembles it, the same sed applied to docs_dir, --strict added. baseline rc=0, no warnings; 2 pages link to it (CHANGELOG, and itself) with nav rc=0, no warnings; 49 pages link to it (all of them, via the sidebar) The RFC's page grows 87KB -> 93KB from the sidebar; its rendered <article> is byte-identical across the two builds (sha256 4d5b3cf2d6e94551, 35201 chars). sitemap.xml and the search index are identical in both. llms.txt is untouched by design: the llmstxt plugin takes an explicit sections list that names no RFC at all. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>

47 nav entries, 48 built pages. docs/rfcs/a2a-delegation-profile.md is the page they do not cover. The same fix has been applied once already: 8380993 ("Adopt-the-shared-design-system-and-unhide-ten-pages", 2026-08-19) added ten nav entries, one of them docs/rfcs/composable-zk-assurance.md, which had landed in agentrust-io#162 three days earlier without one. agentrust-io#184 merged four days after that sweep and did not touch mkdocs.yml. Nothing in agentrust-io#184's description, comments or reviews mentions the nav. It is not unreachable — CHANGELOG.md links it, examples/delegation-link/README.md links it, it is in sitemap.xml, and the search index carries 13 entries. What it has no path from is the navigation. Measured by reproducing the deployed build rather than a local one: .docs_build assembled the way docs.yml assembles it, the same sed applied to docs_dir, --strict added. baseline rc=0, no warnings; 2 pages link to it (CHANGELOG, and itself) with nav rc=0, no warnings; 49 pages link to it (all of them, via the sidebar) Nothing else moves. 49 files differ, none added, none removed, no page loses a link. 48 gain exactly one — the sidebar entry. The forty-ninth is the RFC's own page, +17: its table of contents, which the theme renders only for a page it navigates to. The rendered <article> is byte-identical across both builds (sha256 4d5b3cf2d6e94551, 35201 chars); sitemap.xml and the search index are identical in both. llms.txt is untouched by design: the llmstxt plugin takes an explicit sections list that names no RFC at all. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>

47 nav entries, 48 built pages. docs/rfcs/a2a-delegation-profile.md is the page they do not cover. The same fix has been applied once already: 8380993 ("Adopt-the-shared-design-system-and-unhide-ten-pages", 2026-08-19) added ten nav entries, one of them docs/rfcs/composable-zk-assurance.md, which had landed in #162 three days earlier without one. #184 merged four days after that sweep and did not touch mkdocs.yml. Nothing in #184's description, comments or reviews mentions the nav. It is not unreachable — CHANGELOG.md links it, examples/delegation-link/README.md links it, it is in sitemap.xml, and the search index carries 13 entries. What it has no path from is the navigation. Measured by reproducing the deployed build rather than a local one: .docs_build assembled the way docs.yml assembles it, the same sed applied to docs_dir, --strict added. baseline rc=0, no warnings; 2 pages link to it (CHANGELOG, and itself) with nav rc=0, no warnings; 49 pages link to it (all of them, via the sidebar) Nothing else moves. 49 files differ, none added, none removed, no page loses a link. 48 gain exactly one — the sidebar entry. The forty-ninth is the RFC's own page, +17: its table of contents, which the theme renders only for a page it navigates to. The rendered <article> is byte-identical across both builds (sha256 4d5b3cf2d6e94551, 35201 chars); sitemap.xml and the search index are identical in both. llms.txt is untouched by design: the llmstxt plugin takes an explicit sections list that names no RFC at all. Signed-off-by: Louielunz <48041247+lywinged@users.noreply.github.com>

docs: propose composable ZK assurance for TRACE

9bee12e

Signed-off-by: Florian <florian@technotro.com>

Trivo25 mentioned this pull request Aug 11, 2026

RFC Proposal: Composable Zero-Knowledge Proofs for TRACE #161

Closed

2 tasks

imran-siddique reviewed Aug 11, 2026

View reviewed changes

Comment thread docs/rfcs/composable-zk-assurance.md Outdated

Comment thread docs/rfcs/composable-zk-assurance.md

Comment thread docs/rfcs/composable-zk-assurance.md Outdated

Comment thread docs/rfcs/composable-zk-assurance.md Outdated

Trivo25 added 7 commits August 12, 2026 12:47

fix optional privacy concerns of the proof system

d617329

same-binding values

0d8cddf

enforce proof and context verification in gateway

1d4de64

fix tee assumptiojns

120d560

docs: tighten composable ZK assurance model

e649744

Signed-off-by: Florian <florian@technotro.com>

docs: clarify ZK conformance and TCB requirements

1bcba06

Signed-off-by: Florian <florian@technotro.com>

docs: clarify assurance and EAT profile terminology

2ff6309

Signed-off-by: Florian <florian@technotro.com>

imran-siddique requested changes Aug 12, 2026

View reviewed changes

Trivo25 added 2 commits August 12, 2026 23:54

Merge pull request #1 from Trivo25/florian/zk-trace-review-fixes

4174eb7

RFC: Address assurance-model review feedback

docs: require distinct EAT profile for ZK assurance

1b56d15

Signed-off-by: Florian <florian@technotro.com>

docs: clarify fail-closed behavior for unsupported ZK profiles

34e3bf6

lywinged mentioned this pull request Aug 14, 2026

test(docs): a requirement keyword outside the spec must name its source #175

Merged

imran-siddique requested changes Aug 14, 2026

View reviewed changes

docs: remove normative MUST from informative ZK RFC

24bed3a

Trivo25 force-pushed the florian/zk-trace branch from 913b8b7 to 24bed3a Compare August 14, 2026 18:08

imran-siddique approved these changes Aug 16, 2026

View reviewed changes

imran-siddique merged commit 0b5ca91 into agentrust-io:main Aug 16, 2026
1 of 2 checks passed

lywinged mentioned this pull request Aug 23, 2026

docs(nav): the one page on the site with no nav entry #205

Merged

9 tasks

Uh oh!

Conversation

Trivo25 commented Aug 11, 2026

What this changes

Type of change

Spec section

Checklist

Uh oh!

imran-siddique left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

imran-siddique left a comment

Choose a reason for hiding this comment

Uh oh!

imran-siddique commented Aug 12, 2026

Uh oh!

Trivo25 commented Aug 12, 2026

Uh oh!

lywinged commented Aug 12, 2026

Uh oh!

Trivo25 commented Aug 12, 2026

Uh oh!

Trivo25 commented Aug 14, 2026

Uh oh!

lywinged commented Aug 14, 2026

Uh oh!

imran-siddique left a comment

Choose a reason for hiding this comment

Uh oh!

Trivo25 commented Aug 14, 2026

Uh oh!

imran-siddique left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants