Network Working Group B. Zambo Internet-Draft Zambo Intended status: Informational 27 October 2026 Expires: 30 April 2027 AER-1 Receipts as Audit Records for WIMSE AIMS draft-zambo-aer1-wimse-mapping-01 Abstract The WIMSE AI Identity Management System (AIMS) framework requires deployments to produce durable audit logs covering authorization decisions and subsequent remediations, requires those audit records to be tamper-evident, lists the minimum fields an audit event records, and calls for reconstruction of complete execution chains across service boundaries. AIMS deliberately specifies no audit record format. This document supplies one candidate: it maps each AIMS audit requirement onto the AER-1 execution receipt, field by field, shows how AER-1 hash-chained timelines and workflow receipts reconstruct an execution chain, and defines an optional carriage of AER-1 receipts as SCITT statements for deployments that operate a transparency service. The mapping changes no AER-1 field, digest construction, or verification rule, and it states plainly what a receipt does not prove. Implementation Status This section records implementation status following [RFC7942]. It will be removed before publication as an RFC. The AER-1 vocabulary mapped here is specified in [AER1], now at draft-zambo-aer1-26, with a published conformance corpus of 126 vectors and 129 checks (kit v1.5.7) at https://zambo.dev/aer1/ corpus.json. A reference implementation is deployed at https://zambo.dev/mcp and issues a receipt for every tool call it receives, including calls it rejects before execution, which is the behavior Section 3 of this document maps to the AIMS requirement to log authorization decisions. Independent implementations built from the draft text alone include Node.js, Java, and Perl verifiers, and an independent production validator is operated by WhiteMagic Labs at https://api.whitemagic.dev/aer1/verify. A cross-implementation interoperability matrix for AER-1 is regenerated nightly; at the time of writing it reports zero disagreements across the listed implementations. Zambo Expires 30 April 2027 [Page 1] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mapping AIMS Audit Events to AER-1 Receipts . . . . . . . . . 4 4. Execution Chain Reconstruction . . . . . . . . . . . . . . . 6 5. Carriage as SCITT Statements . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Zambo Expires 30 April 2027 [Page 2] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 1. Introduction Section 11 of the WIMSE AIMS framework [AIMS] makes monitoring and observability a security control. It requires that "deployments MUST produce durable audit logs covering authorization decisions and subsequent remediations", that "Audit records MUST be tamper-evident and retained according to the security policy of the deployment", and it enumerates the minimum content of an audit event. It further states that implementations should let operators "reconstruct a complete execution chain of an agent task, including delegated authority, intermediate calls, and resulting actions across service boundaries". AIMS defines the requirement and the minimum field list; it does not define a record format, a digest construction, or a verification procedure. AER-1 [AER1] defines exactly those three things for one agent tool call: a JSON receipt record (Section 3 of [AER1]), a SHA-256 output commitment over canonical bytes (Section 4 of [AER1]), and a verification procedure any third party can run (Section 6 of [AER1]). AER-1 receipts chain into hash-linked job timelines (Section 7 of [AER1]) and bind into workflow receipts with a Merkle root over the step sequence (Section 8 of [AER1]). This document is a mapping, not a new format. Section 3 maps each AIMS Section 11 audit requirement to the AER-1 construct that satisfies it, including the points where AER-1 records more than AIMS asks and the points where a deployment must supply a binding AIMS assumes. Section 4 covers execution chain reconstruction. Section 5 defines optional carriage of receipts as SCITT [SCITT] statements, building on the external anchoring that [AER1] already permits in its Section 10. Section 6 states the limits of the mapping. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Terms from [AER1] (receipt, canonical bytes, output commitment, provenance class, execution context) and from [AIMS] (Agent, Tool, System, delegated subject) are used with the meanings those documents give them. Zambo Expires 30 April 2027 [Page 3] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 3. Mapping AIMS Audit Events to AER-1 Receipts AIMS Section 11 requires an audit event to record, at a minimum, the seven items in the left column below. The right column names the AER-1 construct that carries each item. +================================+================================+ | AIMS Section 11 audit field | AER-1 carrier | +================================+================================+ | Authenticated agent | The "tool" member's caller | | identifier | scope and the receipt's | | | provenance class (Sections 3 | | | and 5 of [AER1]); the | | | execution_context member | | | records the framework and | | | model that issued the call | | | (Section 3.2 of [AER1]). | +--------------------------------+--------------------------------+ | Delegated subject (user or | The caller scope recorded in | | system), when present | the "tool" member, bound by | | | the deployment to its subject | | | identifiers (see the note | | | following this table). | +--------------------------------+--------------------------------+ | Resource or tool being | The "tool" member (name and | | accessed | version), and the | | | execution_context "source" | | | member naming the system the | | | call acted upon. | +--------------------------------+--------------------------------+ | Action requested and | The receipt record itself. | | authorization decision | AER-1 requires a receipt for | | | every call received, including | | | a call rejected before | | | execution; the rejection | | | receipt records the requested | | | tool, the arguments as | | | received, and the error | | | returned (Section 3 of | | | [AER1]). | +--------------------------------+--------------------------------+ | Timestamp and transaction or | The "created_at" member | | request correlation | (RFC 3339) and the receipt | | identifier | "id" (a UUID); correlation | | | across calls and services is | | | carried by the chain linkage | | | of Section 7 of [AER1] and | | | the workflow membership of | Zambo Expires 30 April 2027 [Page 4] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 | | Section 8 of [AER1]. | +--------------------------------+--------------------------------+ | Posture assessment or risk | execution_context extension | | state influencing the | members (Section 3.2 of | | decision | [AER1]). Posture is context: | | | it sits outside the hashed | | | core and MUST NOT change the | | | meaning of the core members. | +--------------------------------+--------------------------------+ | Remediation or revocation | A remediation or revocation | | events and their cause | is itself an action taken | | | through a tool or system; the | | | receipt issued for that action | | | records it, ordered among the | | | events it remediates by the | | | chain rules of Section 7 of | | | [AER1]. | +--------------------------------+--------------------------------+ Delegated subject. AIMS assumes deployments have subject identifiers; AER-1 carries the caller scope under which a call was made and the provenance class that states who ran or reported the action. A deployment adopting this mapping binds its subject identifiers to caller scopes in its own configuration, the same place AIMS Section 12 puts the rest of the deployment's authentication and authorization policy. The binding is deployment policy, not something the receipt format can assert on the deployment's behalf. Authorization decisions. The load-bearing row of the table is the fourth. AIMS requires the log to cover authorization decisions, and a decision to deny is the case conventional logging most often loses, because nothing executed and ad hoc logs are written by the executor. AER-1 inverts this: its Section 3 makes issuance independent of execution. A producer MUST issue a receipt for every tool call it receives, including a call it rejects before execution, and "a call that leaves no receipt is a conformance failure: the absence of a record MUST NOT be allowed to hide an attempted call." A deployment whose policy point rejects a request before any tool is invoked applies the same rule at that point: the component that received the request issues the rejection receipt, so the denial is a first-class, checkable record rather than a gap. Tamper evidence. AIMS requires audit records to be tamper-evident. An AER-1 receipt carries the exact canonical bytes of the recorded result and a SHA-256 output commitment over them (Sections 3 and 4 of [AER1]), plus a metadata binding (Section 3.1 of [AER1]). The verification procedure (Section 6 of [AER1]) recomputes the digest and compares; a record altered after issuance fails the comparison. Zambo Expires 30 April 2027 [Page 5] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 Sequenced receipts additionally chain (Section 7 of [AER1]), so removal or reordering of records within a job timeline is detectable against the chain. Durability and retention. AIMS leaves retention periods to deployment policy. AER-1 receipts resolve at stable public URLs (Section 9 of [AER1]) and are self-contained JSON records, so a deployment can retain them in any store that preserves bytes; the commitment makes any later alteration of the retained copy detectable regardless of the store. 4. Execution Chain Reconstruction AIMS Section 11 states that implementations should let operators reconstruct a complete execution chain of an agent task across service boundaries. AER-1 provides two compositions for this. Within one producer, receipts form a hash-chained job timeline (Section 7 of [AER1]): each entry digest binds the entry to its predecessor, so the chain is ordered and gaps are visible. Across steps, a workflow receipt (Section 8 of [AER1]) binds an ordered sequence of step receipts, which may originate from different services, to a single goal, with a Merkle root over the step sequence and bidirectional links between the workflow and each step. An auditor holding the workflow receipt can enumerate the steps, resolve each step receipt at its public URL, and verify each step under Section 6 of [AER1] and the whole under Section 8.2 of [AER1], without an account with, or the cooperation of, any of the producing services. This is the reconstruction AIMS asks for, expressed over records that were checkable when they were issued rather than assembled after the fact. 5. Carriage as SCITT Statements [AER1] Section 10 already permits external anchoring of receipts, including anchoring to a SCITT [SCITT] transparency service. For deployments that operate or use such a service, this section fixes the carriage so independent implementations produce the same statements. The receipt producer issues a SCITT Signed Statement whose payload is the AER-1 receipt as a JSON object, whose subject is the receipt "id", and whose issuer is the producer's SCITT issuer identity. The statement's payload digest therefore commits to the same bytes the receipt's own metadata binding commits to, and the two commitments can be compared by any verifier. On registration, the transparency service returns a Transparent Statement carrying its inclusion proof; a verifier evaluating the receipt reports the anchor's outcome using the per-anchor outcome vocabulary of Section 6 of [AER1] (verified, Zambo Expires 30 April 2027 [Page 6] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 verification failed, rejected: unresolvable record, not checked, or absent), so an unevaluated anchor is never reported with an evaluated outcome. Carriage under this section is OPTIONAL. A receipt that is never registered with a transparency service remains fully verifiable under Section 6 of [AER1]; registration adds an independently operated witness to the receipt's existence and content at a point in time, and, because a transparency service authenticates its issuers, a path to issuer authentication for deployments that require it (see Section 6). Related work in the same space binds agent evidence differently: [THAHA-BINDING] binds AI agent credential evidence using in-toto predicates within the WIMSE credential story, and [THAHA-SCITT] profiles SCITT for agent execution evidence. This document is complementary to both: it starts from the AER-1 record, which exists independently of any credential or transparency infrastructure, maps it to the AIMS audit requirements, and treats SCITT strictly as an optional carriage and anchoring layer. 6. Security Considerations A receipt proves a narrow thing, and this mapping inherits the narrowness. Verification under [AER1] establishes that the saved record was not changed after it was saved. It does not establish that the recorded action was correct, that it was authorized, or that the outcome it reports is true of the outside world. An AIMS deployment MUST NOT treat the presence of a valid receipt as evidence that an action was permitted; the receipt is the record of the decision and the action, and policy evaluation remains the deployment's own function, exactly as AIMS Section 12 frames it. The base AER-1 format does not authenticate the issuer of a receipt; [AER1] discloses this normatively in its own text. Provenance classes (Section 5 of [AER1]) state who ran or reported an action, but a class label is a claim, not a proof. Deployments whose threat model requires issuer authentication use an authenticated anchoring path: the SCITT carriage of Section 5, where the transparency service authenticates issuers, or another anchor medium permitted by Section 10 of [AER1] that binds the receipt digest under an identity the deployment trusts. Section 10.2 of [AER1] applies throughout: binding a receipt to an external record does not transfer the claims of one to the other. Posture and risk state recorded in execution_context are context supplied by the producer. Section 3.2 of [AER1] places execution_context outside the hashed metadata core, so a verifier Zambo Expires 30 April 2027 [Page 7] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 MUST NOT treat posture members as evidence of the state they describe; they record what the producer reported, and a deployment that needs posture it can rely on must obtain it from its own policy components. Clock trust and equivocation limits for chained timelines are as stated in Section 13 of [AER1]. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [AER1] Zambo, B., "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", Internet-Draft draft-zambo-aer1-26, October 2026, . [AIMS] Kasselman, P., et al., "AI Identity Management System", Internet-Draft draft-ietf-wimse-aims-00, September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 8.2. Informative References [SCITT] Birkholz, H., et al., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Internet-Draft draft-ietf-scitt- architecture-22, . [THAHA-BINDING] Thaha, A., "Evidence Binding for AI Agent Credentials", Internet-Draft draft-thaha-wimse-agent-evidence- binding-00, . [THAHA-SCITT] Thaha, A., "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", Internet-Draft draft-thaha- scitt-agent-execution-evidence-00, . Zambo Expires 30 April 2027 [Page 8] Internet-Draft AER-1 for WIMSE AIMS Audit Logs October 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, . 9. Acknowledgments The AIMS framework's decision to state audit requirements, including the minimum audit event fields, without mandating a record format is what makes a mapping document like this one possible. The AER-1 conformance community's independent implementers produced the interoperability evidence cited in the Implementation Status section. Author's Address Brennan Zambo Zambo Email: brennanzambo@zambo.dev URI: https://zambo.dev/aer-1 Zambo Expires 30 April 2027 [Page 9]