standards: datatracker review comment on draft-sharif-agent-audit-trail

[ojongerius]

Context

The IETF Internet-Draft draft-sharif-agent-audit-trail (Sharif / CyberSecAI, filed 29 March 2026, expires September 2026) specifies an agent audit log format with the same core mechanics as Agent Receipts: RFC 8785 canonical JSON with SHA-256 hash chaining, optional ECDSA/Ed25519 signatures.

It is the most consequential single standards effort for Agent Receipts' three-year positioning (per the May 2026 landscape — #554). The independent convergence on the same primitives validates the design choice; the divergences are where Agent Receipts can contribute substantively to the IETF record.

A single substantive review comment on datatracker — under my name, with disclosure — is a high-leverage, one-time action. Unlike AIVS contributions (which require sustained presence), this is one carefully written comment posted once.

What the comment should cover

• Acknowledge independent convergence on RFC 8785 + SHA-256 hash chain. Cite Agent Receipts v0.3.0 spec §1.4 and §4 as a worked implementation of the same primitives.
• Note the two material divergences:
  1. W3C Verifiable Credentials envelope (vs draft-sharif's bespoke signed JSON). Argument: VC tooling already exists; receipts are independently verifiable with general-purpose tooling rather than a bespoke verifier.
  2. Out-of-agent signing model (vs draft-sharif allowing in-agent signing). Argument: if the audited component holds the signing key, it can mint, backdate, or selectively omit its own records. Cite the daemon-process-separation post.
• Comment on one or two specific draft points where v0.3.0 experience is relevant:
  • Parameter hashing semantics (we hit and resolved canonicalization edge cases in cross-SDK testing — [security] Cross-SDK canonicalisation conformance test vectors #474, v0.3.0 alpha end-to-end test plan #519).
  • Peer-credential capture (the daemon captures OS-attested caller identity via SO_PEERCRED / LOCAL_PEERCRED; worth considering as an optional field in draft-sharif for in-process scenarios).
  • HPKE envelope for selective disclosure (parameters_disclosure in v0.3.0 — addresses a gap draft-sharif does not yet cover for sensitive-parameter handling).
• Disclosure: maintainer of Agent Receipts, one of the comparable specifications in the space.
• Tone: peer technical contribution, not competitive positioning. The honest stance is that draft-sharif and Agent Receipts coexist (per the planned ADR on adjacent audit-record formats — see follow-up issue) rather than compete.

Required

• Draft 400–600 words of review comment.
• Reference Agent Receipts v0.3.0 spec sections by URL (post-docs(site): update public spec to v0.3.0 — current site shows v0.1.0/v0.2.x #553 site update).
• Reference the daemon-process-separation post.
• Disclosure line.
• Post on datatracker.ietf.org against the current draft revision.
• Record the comment URL here.

Acceptance criteria

• Comment posted on datatracker before draft expiry (September 2026).
• Comment is a substantive technical contribution, not a pitch.
• Cross-link from this issue to the posted comment.
• If the draft is revised in response, note the response here.

Hard deadline

2026-09-01 — the draft expires in September; commenting before then ensures the comment is on the active revision rather than against an expired draft. Internal target: 2026-07-15 (mid-July), to leave buffer for any back-and-forth and to land while the AIVS contributions (#556 / #557 / #558) are still in active conversation.

Dependencies

• Soft-blocked by docs(site): update public spec to v0.3.0 — current site shows v0.1.0/v0.2.x #553 (spec site v0.3.0 promotion) — the comment will link to v0.3.0 spec sections; the site needs to reflect them.
• Soft-blocked by blog: v0.3.0 release post — anchor for standards-room positioning #555 (v0.3.0 release post) — the release post is the canonical "here is what v0.3.0 ships" artifact this comment will reference.
• Soft-blocked by ADR on adjacent-format posture (filed separately — coexist position) — informs the tone of the comment.

Related

• AIVS CG contributions: standards: AIVS CG contribution on #10 (two canonicalization schemes in one document) #556, standards: AIVS CG contribution on #11 (fabrication / timeliness / key authenticity) #557, standards: AIVS CG contribution on #17 (re-confirm topic before drafting) #558
• May 2026 landscape (publication): docs(blog): publish May 2026 landscape post + living landscape doc #554
• v0.3.0 release post: blog: v0.3.0 release post — anchor for standards-room positioning #555
• Spec site update: docs(site): update public spec to v0.3.0 — current site shows v0.1.0/v0.2.x #553