MapGraphSeamsCalendarIntroductionDisclosureMethodFor agents and tools

Updated weekly, new versions on Mondays · Corrections: open an issue

IETF AUDIT (BoF preparation)

IETFchartercore entry

Verified 2026-10-13. Status as of 2026-10-13. All entries.

Status

Charter text under discussion on the audit list and in mirjak/audit-bof-preparation; the BoF request lists "User e-commerce use case" in its proposed agenda (file updated 2026-09-18). On 2026-10-05 and 2026-10-06 participants agreed in words on the sentence "VCON is considered a suitable record format and the audit group will work with the vcon group to ensure the specified format addresses the auditing"; pull request #61 (one commit, 009b915) was still open on 2026-10-08 and does not contain that sentence. On 2026-10-13 the datatracker group page of audit shows the state Birds of a Feather (BOF) and no charter; a name search for expected-records finds no draft (not found on the datatracker, 2026-10-13), although a list message of 2026-10-10 refers to draft-ahuja-schrock-audit-expected-records-00. On 2026-10-10 a BoF proponent wrote on the list to a participant who had asked for a presentation slot "I am not the chair of the BoF meeting. The chairs will be selected by the ADs." and that the BoF agenda "will not be based on an open call for presentation". Pull request #61 was still open on 2026-10-13 (3 comments, last update 2026-10-06) and the repository mirjak/audit-bof-preparation has no commit after 2026-09-18.

Relevance

AUDIT concerns audit information about agents and delegated systems, so it touches commerce wherever an agent acts for a buyer and a seller or payer later needs a record of what happened. The charter scope reads "The scope of such auditing is the observable behavior of agents, including user intent, agent or tool interactions, invoked or declined actions, exchanged data, and" Commerce, seller, merchant: not found in the charter text, 2026-10-02; repository example: "booking a hotel room" (issue #16).

The BoF request lists under "Architecture overview und use cases (20 mins)" a "User e-commerce use case" and names no presenter; the architecture draft has no "e-commerce" text, and its use cases include a flight booked through a chain of agents and "Financial Transactions by Agents": "Agents may execute financial operations such as payments or procurement actions on behalf of users". The sentence on VCON was proposed on the list on 2026-10-05 by a BoF proponent, Mirja Kuehlewind ("VCON is considered a suitable record format and the audit group will work with the vcon group to ensure the specified format addresses the auditing") and accepted on 2026-10-06 by a participant ("I'm OK with this wording"); another participant proposed a variant in charter style.

On 2026-10-06 Sumit Ahuja wrote that he and Iman Schrock are writing an expected-record draft, "We are aiming for the -00 before the IETF 127 cutoff", which "declares which records each participant in a cross-domain chain is expected to produce, what each establishes, and when an absent one becomes a finding"; Schrock listed six conformance cases for it (declaration integrity, all slots filled, bounded observed absence, incomplete observation, wrong or ineligible record, late record) and the claim boundary "no qualifying record was found in the declared sources by the cutoff". No text of that draft was read; it was announced on the list.

Case 4 reads "An unavailable source, incomplete pagination or coverage, unresolved participant set, or open window produces an incomplete audit, never an absence finding." On 2026-10-07 the author of this map wrote a seventh case on the list at Schrock's request, "Wrong recipient or holder": a record produced by the right party but held only by another does not fill the slot, and if the declared holder's source cannot be checked the audit is incomplete; the example is the confirmation that an EU trader owes the consumer on a durable medium (Directive 2011/83/EU, Art. 8(7)), held only by the agent platform. a co-author of the draft replied the same day that the case "catches a distinction the six cases do not state clearly" and asked for it to be written in the same shape; the draft text has not been read.

The text of PR #61 adds to deliverable 2: "For interaction records - the expectation is that the group will leverage the VCON format. Extensions to VCON to add data needed to model AI" On 2026-10-07 a participant proposed case 8, "Declined action": "A slot for an action that was refused before it ran is filled by the decider's signed refusal bound to that action."; on 2026-10-08 Iman Schrock replied "the refusal should satisfy the decision slot, not fill the downstream effect slot", and that a verified refusal "can make that effect slot not applicable when the declaration names refusal as a terminal condition." On 2026-10-07 Pavel Izmaylov posted the individual draft draft-izmaylov-agent-permission-receipts: the principal signs a permission with a passkey that carries "limits a machine can check" and conditions, and a verifier states for each recorded action whether it stayed within that permission.

Schrock replied on 2026-10-08 comparing it with draft-schrock-ep-authorization-receipts-13 and draft-schrock-ep-bounded-capability-receipts-06 and suggested a comparison in Section 11 of the draft. On 2026-09-30 a participant wrote on the list "Let me know if you want me to share some of our practices on EDR and Gateways during any interim or future meetings." (EDR: endpoint detection and response); on 2026-10-08 the lead editor of the expected-record draft answered "thank you for offering text, and yes please." and the participant wrote that the architecture draft and the charter should "identify the necessary PEPs that should be covered first, rather than jumping into defining the record entries directly" (the message does not expand PEPs; policy enforcement points is the usual expansion).

On 2026-10-08 the lead editor of the expected-record draft wrote "Both cases go into the -00." (cases 7 and 8), added that the contributors of the two cases "will be named as contributors for these" (see Disclosure for the credit to the author of this map), and wrote "The draft will be draft-ahuja-schrock-audit-expected-records."; the datatracker page of that name returned 404 and the document search found no draft with "expected-record" in its name on 2026-10-09, so the text is pending and its content was not read.

On 2026-10-11 a participant wrote a ninth case, "Refusal with an undetermined cause": "The slot is filled by a record that states whether a refusal came from a check that ran and failed, or from a check that", adding "AAE as published collapses both causes into a single DENY, so this case describes a gap in my own specification as much as anywhere else." Iman Schrock answered the same day (his text read as quoted in the lead editor's reply) that where the declaration requires grounds, "a single DENY cannot tell us whether revocation was established or the status check could not finish", and the lead editor of the expected-record draft wrote the same day "This goes into the -00 as Case 9, just like Iman put it.

Lars will be named as a contributor for this case." On 2026-10-12 the same participant wrote that the decision receipt format that he publishes "carries Case 9 as fields". The draft itself is still not found on the datatracker (document search for expected-record and audit-expected, and the page and text URLs of draft-ahuja-schrock-audit-expected-records-00, HTTP 404, 2026-10-13), so cases 7, 8 and 9 are announced for the -00 and not read in it.

Committed next

Boundary

Scope excludes "the auditing of the underlying AI model, training data, or inference mechanisms" and new identity primitives (issue #7).

Author participation

The author of this map took part in issue #35 of mirjak/draft-audit-architecture and the AUDIT list (2026-09-28), and wrote two messages on the AUDIT list on 2026-10-07 proposing and writing the seventh case; see Disclosure.

Sources

Neighbours in the map

Neighbours of IETF AUDIT (BoF preparation) in the map Each circle is an entry of the map and links to its page; the colour is the kind of body behind it, a filled circle is a core entry and a dashed circle a context entry. The entry in the middle, with the entries it overlaps and the entries named by the same seams. Overlaps (3)Share a seam (0)IETF agentproto (Agent Communication Protocols WG) (IETF, core)IETF agentproto IETF vcon (Virtualized Conversations WG) (IETF, core)IETF vcon EMILIA Protocol (individual drafts and open-source gate) (Independent, context)EMILIA Protocol IETF AUDIT

Solid lines: overlaps declared by one of the two entries. Dashed lines, coloured by seam: entries named by the same seam (S1 to S4) in the seams note. Every node is a link.

Evidence and coverage

Read
On 2026-10-13 also: the session request data of IETF 127 for audit (API); the three audit list messages of 2026-10-11 and 2026-10-12 on case 9, found among the 40 latest messages of the list page.
Not read
The expected-record draft (announced, no text read); diffs of PR #52, #53, #58, #60; issues of mirjak/draft-audit-architecture; the audit list before 2026-09-17 for the e-commerce search.
Not found
Not found in the items read, 2026-10-02: minors, buyer age, terms of use, Know Your Agent (KYA), product identity. Not found in the 80 audit list messages (2026-09-17 to 2026-10-06): e-commerce, UCP, ACP, AP2, x402, Verifiable Intent, Visa. Not found in the draft-kuehlewind-audit-architecture files and history, 2026-10-06: e-commerce. Not found on the datatracker BoF page (2026-10-02) and in the IETF 127 agenda updated 2026-10-02 (read 2026-10-06): an AUDIT session.

Open proposals

ProposalAuthorDateStateLink
Charter text: data models for interaction records, identities, delegation context; reuse VCON.Jonathan Rosenberg2026-10-02openhttps://github.com/mirjak/audit-bof-preparation/pull/61