Protocol composition: audit receipts for agent actions carrying libzk-verified anonymous credentials

[tomjwxf]

Opening this as a scope-check discussion, not a formal proposal. I am the author of draft-farley-acta-signed-receipts, a per-action audit-receipt format for AI-agent governance. Your team is authoring draft-google-cfrg-libzk. The two drafts sit in complementary layers of the same problem space, and I wanted to flag a composition worth thinking about before either draft stabilizes.

What each draft provides today

libzk proves properties of a legacy identity credential (mdoc, JWT, W3C VC) without revealing the credential. The prover shows "this ECDSA-signed document exists and satisfies predicate P," the verifier checks the proof, and the holder's identity is not disclosed.

draft-farley-acta-signed-receipts attests to a per-action decision by an AI agent. The receipt binds (principal, action, resource, context, decision) under an Ed25519 signature. Receipt chains link via previousReceiptHash so a session's decisions are tamper-evident end-to-end.

Where they compose

Today a receipt's principal field is a plain entity UID. In many governance contexts the identity we actually care to bind is a privacy-preserving assertion, not a raw subject DID or a plaintext credential. Example: an agent acting for a holder who has proven via libzk that they are over 18 and a resident of EU member state X, without disclosing the holder's specific identity.

A composition lets the receipt's principal reference a libzk proof of predicate-over-credential rather than a bare entity UID. Auditors verify:

1. The libzk proof is well-formed and satisfies the predicate (libzk verifier, already specified).
2. The receipt's Ed25519 signature covers a payload that commits to the libzk proof hash as part of principal.
3. The receipt chain is intact across the session.

Neither draft needs to change structurally. libzk continues to produce its proofs. The receipt format already accepts arbitrary principal shapes; a bytes commitment to a libzk proof fits.

The win: auditable agent governance that preserves the privacy guarantees libzk is built to provide. The alternative today is to either expose the holder's identity in the receipt, or to skip receipt signing entirely, and both choices force a compliance trade-off the composition removes.

What I am asking for

Not an immediate action. Three specific questions for the Longfellow team:

1. Is the libzk proof format stable enough that a downstream receipt format can safely reference it by content-hash commitment? If yes, would a short informational section in the libzk draft describing the composition shape be welcome, or would you prefer the composition live entirely in draft-farley-acta-signed-receipts without touching libzk's text?

2. For the receipt-side identity commitment, is there a preferred canonical form? I have been using JCS (RFC 8785) for everything the receipt signs. If libzk has an internal canonical form for proof artifacts, aligning would let a single verifier check both in one pass.

3. Is there interest in a joint informational IETF draft describing the composition (separate from both libzk and acta), or is a cross-reference from acta into libzk sufficient? I am agnostic on venue; the question is what the Longfellow team would find useful versus intrusive.

Non-asks

• Not proposing changes to the libzk protocol, proof system, or implementation.
• Not proposing Longfellow adopt any specific receipt format, signing primitive, or verifier.
• Not a product pitch; draft-farley-acta-signed-receipts is individual-submission, its reference verifier (@veritasacta/verify) is Apache-2.0, and the receipt format is intentionally vendor-neutral. Four independent implementations currently cross-verify against shared fixtures.

Prior art in this pattern

The composition of "auditable record + privacy-preserving credential" is not novel at the pattern level (see EU AI Act Article 12 logging requirements composed with GDPR pseudonymization, for example). What is novel is the cryptographic shape: a signed audit trail whose principal is itself a ZK proof rather than a plaintext identity. Both libzk and acta are young enough that the composition can be designed in rather than retrofitted later.

Happy to drop this back to acta if the Longfellow team prefers the composition live entirely downstream. Flagging it here because libzk is authoritative on the credential side and the receipt side is easier to adjust than the ZK side.

Cc: @tgeoghegan @divergentdave (active on the libzk spec PRs)

Thanks.

[tgeoghegan]

I haven't studied your proposal in-depth but my first question is: why do you mandate Ed25519 and only Ed25519? Longfellow concerns itself with proving from ECDSA over P256 (which, by the way, is not the same thing as Ed25519; you'd have to do some work on Longfellow to get it to prove EdDSA over Curve25519) because it aims for compatibility with existing issued credentials. If you don't have that constraint (i.e., you'd be issuing new credentials for entities participating in your protocol), then (1) you could choose a signature scheme that's easier to prove statements from and more importantly (2) you really, really should pick something post-quantum.

Major industry players like Google and Cloudflare are aiming to migrate away from classical crypto by 2029, so new work proposed at IETF today should not be ossifying around classical signature schemes. ML-DSA is the most obvious choice, but you can check out work in places like CFRG or LAMPS to find guidance on algorithm choices.

[tomjwxf]

Thanks @tgeoghegan for the thoughtful feedback.

On the data flow: to clarify, the composition I proposed does not require verifying the receipt's signature inside a ZK circuit. The receipt commits to the libzk proof by content hash. libzk proves predicates over existing P-256 credentials (your layer), the receipt attests the agent's action separately (our layer), and the binding is a hash reference. The curves never interact.

On Ed25519: fair point. It was a pragmatic v1 choice (deterministic, compact, cross-language library ubiquity), not an architectural commitment. I will update the draft to define the signature scheme via IANA-registered algorithm identifiers. Ed25519 as MTI, ML-DSA-65 as the recommended option for new deployments.

On PQ: agreed that new IETF work should not ossify classical. The chain layer (SHA-256) is already PQ-safe. The outer signature will be updated for ML-DSA.

Related work: separately, your feedback on PQ agility prompted me to explore commitment-based selective disclosure for receipt fields. Conceptually aligned with SD-JWT's salt-hash pattern (draft-ietf-oauth-selective-disclosure-jwt), but adapted for chained audit logs. Each field is independently committed asSHA-256(salt || field_value), the outer signature covers the commitment vector, and selective disclosure works by revealing individual salts.

See working sketch at : https://github.com/VeritasActa/commitment-receipts

Two questions:

1. Context binding: my understanding is that to prevent a valid libzk proof from being replayed into a different receipt, the proof needs to bind to the specific receipt's commitment vector. Does libzk support passing an external challenge or context hash as a public input?

2. PQ transition: is there a preferred hybrid classical+PQ construction the Longfellow team is tracking, or is general CFRG composite guidance best?

Appreciate any thoughts on the above.

Best,
Tom

[tomjwxf]

Hey Tim, just updated: draft-01 just landed on datatracker — https://datatracker.ietf.org/doc/draft-farley-acta-signed-receipts/01/

Three things from the prior thread are now in spec text:

Algorithm agility via JOSE/JWS names: EdDSA as MTI, ML-DSA-65 as the recommended PQ option, ES256 supported for ECDSA P-256 compatibility (§algorithm-agility)
Commitment-mode receipts using SHA-256(salt || value) per-field commitments organized as an RFC 6962-style Merkle root with explicit domain separation (§commitment-mode)
ZK context binding: when a receipt's principal references a ZK proof, the proof MUST bind to committed_fields_root as its context hash (§zk-context-binding). One normative sentence in -01; happy to expand into a fuller subsection in -02 if you'd find that useful for the libzk side.