[Audit] Re: Charter Comments -- more specific on the scope?

["Heime.Jorgen" <[e-mail]>]

Hi Iman, Sumit, Henri, and all,

Thanks Iman, this separation makes complete sense.

Keeping draft-ahuja-schrock-audit-expected-records-00 abstract around slot semantics while delegating concrete mechanisms (TLS Exporters, temporal consensus, atomic state stores) to a companion Enforcement-Point (EP) profile keeps the core architecture clean and extensible.

To support this framing, I have also added a clarification to GitHub PR #36 (https://github.com/mirjak/draft-audit-architecture/pull/36) to formally distinguish Pre-effect Admission Evidence from traditional Post-facto Timestamping:

- Post-facto Evidence (RFC 3161 TSA / SCITT): Provides retrospective proof ("Action X occurred at time T"), but cannot prevent an unauthorized action, replay, or overspend before state-commit. As Henri correctly noted, these existing frameworks remain essential for the post-effect ledger.
- Pre-effect Sealing (EP Layer): Ensures an action is cryptographically bound and validated BEFORE execution takes effect, generating a signed refusal (Case 8) and halting downstream execution if validation fails.

These two approaches are complementary: RFC 3161/SCITT serves as the retrospective ledger, while the EP layer serves as the pre-ingestion gatekeeper.

I agree with all your refinements for the -00 draft:
1. EP Profile Guarantees: The companion EP profile (draft-jorgen-audit-tttps) will explicitly state its ordering, durability, and coverage guarantees to establish that pre-ingestion validation strictly preceded the effect.
2. Case 8 Boundary: A verified refusal bound to the action satisfies the decision slot, and only marks downstream effect slots as not applicable when defined as a terminal condition (without clearing unresolved earlier dispatches).
3. Case 7 Distinction: Treating cryptographic binding failure as making a record ineligible, separate from recipient/holder identity requirement checks.

The example updated with these slot mappings fits well into -00, and I will maintain the concrete implementation guarantees in the companion EP profile draft.

Best regards,
Heime Jorgen


-- Original Message --------
On Friday, 10/09/26 at 23:56 Iman Schrock <team=[e-mail]> wrote:
Hi Heime,

Thanks for writing this up. The gateway and EDR examples help show
where the records come from.

Could we keep the implementation requirements in an enforcement-point
profile, as Sumit suggested? Our draft can describe which slots those
records fill without prescribing TLS exporters, temporal consensus, or
a particular state store.

A seal or channel binding alone does not establish that validation
preceded the effect. The profile would need to state its ordering,
durability, and coverage guarantees.

For Case 8, I'd retain the condition Sumit incorporated: a verified
refusal from an authorized decider, bound to the action, fills the
decision slot. It makes the effect slot not applicable only when the
declaration names refusal as a terminal condition. It must not clear
an unresolved earlier dispatch.

One distinction on Case 7: failed cryptographic binding makes a record
ineligible; wrong recipient concerns who was required to receive or
retain it.

With those changes, I think the example fits well.

Best,
Iman

On Fri, 9 Oct 2026 11:10:52 +0000, Heime Jorgen <[e-mail]> wrote:
> Hi Sumit, Iman, Francesco, and all,
>
> Thanks Sumit. Here is the proposed text grounding the Enforcement Point (EP) layer and how its local execution state links to the expected records framework.
>
> Proposed Text Insertion / Reference:
>
> X. Enforcement Points and Pre-Ingestion Evidence
>
> An Enforcement Point (EP)—such as an API gateway, egress proxy, or EDR module—operates at the immediate boundary of action execution. While an audit task evaluates expected records across an entire chain, an EP provides the immediate, pre-ingestion evidence that an action was cryptographically bound and validated before any state change took effect.
>
> To serve the audit framework, an EP MUST maintain three properties:
>
> 1. Pre-Ingestion Sealing: The record is cryptographically sealed at the exact generation boundary (e.g., using TLS Exporter bindings and temporal consensus) rather than self-attested post-facto.
>
> 2. Executor Atomic State (Replay Defense): The EP checks and commits a unique action token (nonce/context) against an atomic state store (e.g., lock-free local cache or distributed key-value store) prior to downstream dispatch. Replayed or out-of-bound attempts are rejected at line-rate.
>
> 3. Deterministic Failure Reporting: When an EP denies an action (due to replay, stale temporal proof, or key mismatch), it generates a signed refusal or error receipt bound to the action attempt.
>
> Slot Mapping for EP Findings:
>
> Execution Allowed & Sealed: Fills the local execution/temporal slot as ⁠record present⁠.
>
> EP Refusal / Policy Block: Satisfies the decision slot with a signed refusal, rendering the downstream effect slot ⁠not applicable⁠ (Case 8: Declined action).
>
> Binding / Recipient Mismatch: Reports a ⁠wrong-recipient record⁠ or ⁠incomplete audit⁠ without masking missing downstream effect records (Case 7).
>
> Feel free to adapt or trim this to fit the structure of ⁠-00⁠.
>
> Best regards,
>
> Heime Jorgen
On Fri, 09 Oct 2026 11:10:52 +0000, "Heime.Jorgen"
<[e-mail]> wrote:
> Hi Sumit, Iman, Francesco, and all,
>
> Thanks Sumit. Here is the proposed text grounding the Enforcement Point (EP) layer and how its local execution state links to the expected records framework.
>
> Proposed Text Insertion / Reference:
>
> X. Enforcement Points and Pre-Ingestion Evidence
>
> An Enforcement Point (EP)—such as an API gateway, egress proxy, or EDR module—operates at the immediate boundary of action execution. While an audit task evaluates expected records across an entire chain, an EP provides the immediate, pre-ingestion evidence that an action was cryptographically bound and validated before any state change took effect.
>
> To serve the audit framework, an EP MUST maintain three properties:
>
> 1. Pre-Ingestion Sealing: The record is cryptographically sealed at the exact generation boundary (e.g., using TLS Exporter bindings and temporal consensus) rather than self-attested post-facto.
>
> 2. Executor Atomic State (Replay Defense): The EP checks and commits a unique action token (nonce/context) against an atomic state store (e.g., lock-free local cache or distributed key-value store) prior to downstream dispatch. Replayed or out-of-bound attempts are rejected at line-rate.
>
> 3. Deterministic Failure Reporting: When an EP denies an action (due to replay, stale temporal proof, or key mismatch), it generates a signed refusal or error receipt bound to the action attempt.
>
> Slot Mapping for EP Findings:
>
> Execution Allowed & Sealed: Fills the local execution/temporal slot as ⁠record present⁠.
>
> EP Refusal / Policy Block: Satisfies the decision slot with a signed refusal, rendering the downstream effect slot ⁠not applicable⁠ (Case 8: Declined action).
>
> Binding / Recipient Mismatch: Reports a ⁠wrong-recipient record⁠ or ⁠incomplete audit⁠ without masking missing downstream effect records (Case 7).
>
> Feel free to adapt or trim this to fit the structure of ⁠-00⁠.
>
> Best regards,
>
> Heime Jorgen
>
> -------- Original Message --------
> On Thursday, 10/08/26 at 22:56 Sumit Ahuja <sumit=[e-mail]> wrote:
>
> > Francesco, Henri, Iman, Peter, all,
> >
> > Thank you. Both cases go into the -00.
> >
> > Case 7, wrong recipient or holder, as Francesco wrote it, with Iman's correction to the cross-border sentence. It changes the slot itself: a slot names who must receive or retain the record, not only who produces it.
> >
> > Case 8, declined action, with Iman's refinement. A verified refusal from an authorized decider fills the decision slot. It makes the effect slot not applicable only when the declaration names refusal as a terminal condition, so a refusal can never stand in for an effect record that is genuinely missing.
> >
> > Francesco and Henri will be named as contributors for these.
> >
> > Peter, thank you for offering text, and yes please. On splitting by enforcement point: I think the two fit together. A document per enforcement point would say what that point records, which calls it covers, and what it does when its hook fails. This draft sits above them. It lets an auditing task declare which of those records it expects across a chain, and what their absence means. Your gateway and EDR practice would ground the first kind, and this draft would cite it.
> >
> > The draft will be draft-ahuja-schrock-audit-expected-records.
> >
> > Sumit P. Ahuja
> > Main Labs
> >
> > On Wed, Oct 07, 2026 11:40 PM, Iman Schrock <team=[e-mail]> wrote:
> >
> >> Henri,
> >>
> >> Thank you. This catches another important case.
> >>
> >> I would make one distinction: the refusal should satisfy the decision
> >> slot, not fill the downstream effect slot. A verified refusal from an
> >> authorized decider, bound to the exact action, can make that effect
> >> slot not applicable when the declaration names refusal as a terminal
> >> condition.
> >>
> >> That prevents a refusal record from masking a genuinely missing effect
> >> record. With that refinement, I think this should be case 8.
> >>
> >> Best,
> >> Iman
> >>
> >> On Wed, 07 Oct 2026 22:15:29 +0000, Henri Sirkkavaara <[e-mail]> wrote:
> >>> Sumit, Iman,
> >>>
> >>> 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. The result reports a declined action, and the missing effect record is not counted as absence. A refusal bound to a different action cannot fill the slot.
> >>> Example: a policy point refuses an agent's payment because the amount exceeds the mandate, so the payment provider correctly holds no record.
> >>>
> >>> Henri Sirkkavaara
> >>> Vaara - Accountable Autonomy
> >>> Built to see over the noise.
> >>> vaara.ioHelsinki, Finland
> >>
> >>>
> >>> On Wednesday, October 7th, 2026 at 12:48, Heime.Jorgen <heime.jorgen=[e-mail]> wrote:
> >>>
> >>> > Francesco, this wording is spot on.
> >>> >
> >>> > It captures the producer vs. holder distinction cleanly and gives the WG a precise, non-binary finding model for delivery edge cases.
> >>> >
> >>> > Heime
> >>> >
> >>> > -------- Original Message --------
> >>> > On Wednesday, 10/07/26 at 15:12 Francesco Marinoni Moretto <[e-mail]> wrote:
> >>> >
> >>> >> Iman, Heime, thank you.
> >>> >>
> >>> >> Iman, you're right on the cross-border sentence; I put it too broadly.
> >>> >> Whether Art. 8(7) reaches a trader outside the EU depends on the transaction and on whether the trader directs its activity to the consumer's market.
> >>> >>
> >>> >> Here is the case in the same shape as the six:
> >>> >>
> >>> >> 7. *Wrong recipient or holder.* Besides producer and role, a slot may declare the party required to receive or retain the record, the deadline, and the evidence that qualifies as delivery. A record produced by the right party but held only by another cannot fill the slot: the result reports a wrong-recipient record, not "record present" and not "no record". If the declared holder's source cannot be checked, the audit is incomplete, never a delivery finding.
> >>> >>
> >>> >> Example: in an EU distance contract the trader must provide the confirmation to the consumer on a durable medium within a reasonable time, and at the latest on delivery of the goods or before the service begins (Directive 2011/83/EU, Art. 8(7)).
> >>> >> A confirmation held only by the agent platform would be a wrong-recipient record for the consumer-delivery slot.
> >>> >> Whether delivery to the agent counts as delivery to the consumer stays open; the declaration would have to state which holder the audit expects.
> >>> >>
> >>> >> Francesco Marinoni Moretto
> >>> >>
> >>> >> On Wed, Oct 07, 2026 06:06 AM, Iman Schrock <[e-mail]> wrote:
> >>> >>
> >>> >>> Francesco,
> >>> >>>
> >>> >>> Yes, this fits, and it catches a distinction the six cases do not state clearly: the producer of a record, the party required to receive or retain it, and the source searched by the audit may be different.
> >>> >>>
> >>> >>> I would make the required recipient or holder part of the slot’s eligibility criteria, together with the deadline and the evidence that qualifies as delivery. A merchant confirmation held only by the agent platform would then be a wrong-recipient record, not a filled consumer-delivery slot. If the consumer-side source cannot be checked, the result remains incomplete rather than becoming a delivery finding.
> >>> >>>
> >>> >>> Please write this as a seventh case in the same shape as the others. The EU example is useful. I would only qualify the cross-border sentence: Article 8(7) requires the trader to provide the confirmation to the consumer on a durable medium, while whether the rule reaches a trader outside the EU depends on the transaction and whether the trader directs activity to that consumer’s market.
> >>> >>>
> >>> >>> Best,
> >>> >>> Iman
> >>> >>>
> >>> >>> On Wed, 07 Oct 2026 04:58:05 +0200, Francesco Marinoni Moretto <[e-mail]> wrote:
> >>> >>>
> >>> >>>> Sumit, Iman, all, Thank you for carrying the expected-record idea into the draft. I'd like to add a case from agentic commerce, where I think the declaration needs one more field. An agent completes a purchase for a consumer. The declared slots are fairly clear: the user's instruction and approval (agent platform), a user-signed authorization such as an AP2 checkout mandate, the merchant's order confirmation, and the payment provider's authentication record. In the EU the trader must also confirm the contract to the consumer on a durable medium (Directive 2011/83/EU, Art. 8(7)). I use the EU rule because it is binding across all member states and, in general, applies to any trader selling to consumers there, wherever the trader is based, so it reaches merchants outside Europe too. It is also specific about who must hold what and by when, which is what a conformance case needs. The failure worth testing is a confirmation that exists but stops at the agent platform and never reaches the consumer. Whether delivery to the agent counts as delivery to the consumer is an open question. But if the slot only names who produces the record, the audit finds it and reports nothing, even if the consumer never received it. So a slot may need to state the expected holder or recipient as well as the producer, and the finding would then be about delivery, not absence. If that fits the scope, I'm happy to write it up as a case in the same shape as Iman's six. Francesco Marinoni Moretto On Tue, Oct 06, 2026 11:24 PM, Sumit Ahuja <sumit= [e-mail]> wrote: > Iman, all, > > Thank you for the six cases. They set out the mechanism more precisely, > and are now the core of the draft. > > Iman and I are writing the -00 together, with me as lead editor and Iman > as co-author. The scope is the one agreed above. The draft 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. AEB stays > authoritative at the consequence boundary, and EP-AEC is cited for the > decision-time requirement. The draft stays neutral to record format. > > The claim boundary in Iman's post is the one we will hold to: not proof of > absence, only that no qualifying record was found in the declared sources > by the cutoff. > > We are aiming for the -00 before the IETF 127 cutoff. Francesco, Henri, > Lars, Peter: if you have a case that should be on that list it would help > to hear it before then. > > Sumit P. Ahuja > Main Labs > > On Mon, Oct 05, 2026 09:06 PM, Iman Schrock <[e-mail]> > wrote: > >> Sumit, >> >> Your distinction is right. EP-AEC pins one relying party’s decision-time >> evidence requirement for one action. Your declaration is made by an >> auditing task after the fact across the participants in a chain. >> >> I would put six conformance cases into the -00: >> >> 1. *Declaration integrity.* The audit function, not a participant, >> supplies a versioned, digested declaration covering the chain instance, >> participants, slots, accepted profiles, joins, sources and deadlines. Any >> weakening is rejected before evaluation. >> 2. *All slots filled.* Each slot has an eligible, natively verified >> record bound to the exact chain or action, participant and role. Any >> declared format may fill it. No finding is emitted. >> 3. *Bounded observed absence.* After the deadline, every declared >> source is completely searched under the declared query and cutoff, with no >> qualifying record found. The finding binds the declaration digest, slot, >> source set, query and as-of snapshot. >> 4. *Incomplete observation.* An unavailable source, incomplete >> pagination or coverage, unresolved participant set, or open window produces >> an incomplete audit, never an absence finding. >> 5. *Wrong or ineligible record.* A forged, untrusted, stale, or >> wrong-action, wrong-participant or wrong-slot candidate cannot fill the >> slot. The result reports the actual reason, not “no record.” >> 6. *Late record.* A record discovered later produces a new as-of >> result. It does not rewrite the earlier finding. >> >> The important boundary is that this is not “proof of absence” or proof of >> a complete chain. The precise claim is only that no qualifying record was >> found in the declared sources by the cutoff. >> >> I would call the mechanism a *participant-spanning expected-record audit*. >> I would also say “records emitted under an AEB deployment,” not “AEB record >> format,” because AEB deliberately does not define a universal format. >> >> This gives the -00 a testable absence rule while leaving the >> consequence-boundary semantics in AEB and the one-action evidence bar in >> EP-AEC. >> >> Best, >> Iman >> >> >> On Mon, 05 Oct 2026 20:14:18 -0400, Sumit Ahuja <[e-mail]> >> wrote: >> >> Iman, Yes, that division works, and it keeps the -00 small. The draft >> will sit across the chain and leave the boundary semantics where they >> already live. I'll cite AEB as an existing boundary contract and not build >> a parallel consequence model. One addition from reading AEB's references. >> EP-AEC's relying-party-pinned evidence requirement is close to an >> expected-record declaration, so the -00 will cite it too and say how the >> two differ. EP-AEC pins what one relying party needs at decision time, for >> one action. The declaration here is made by an auditing task after the >> fact, across every participant in the chain, and it is what turns an absent >> record into a finding. The draft will stay neutral to record format, so AEB >> records, receipts like Vaara's, AER-1 entries or vCon can each fill a >> declared slot. That matches what Mirja asked for. I'd welcome your >> conformance cases. Having them before the first version would make the >> absence rule testable from the start. Sumit On Mon, Oct 05, 2026 01:25 PM, >> Iman Schrock <[e-mail]> wrote: > Sumit, > > The >> expected-record declaration is useful, and I think there is a > clean way >> to keep the -00 from duplicating work that is already > published. > > >> AEB-07 already defines the executor-side contract at a consequential > >> boundary: the observed material action, native artifact verification, > >> exact-action correspondence, the pinned evaluation record and declared > >> coverage, the authorization decision, durable consumption or > reservation, >> provider entry, closed outcomes, and authenticated > reconciliation. It >> also defines the limits of what that boundary > establishes and >> deliberately does not create a universal record > format. > > >> https://datatracker.ietf.org/doc/draft-schrock-action-evidence-boundary/ >> > > The cross-domain work can sit one layer above that contract: declare > >> which AEB or other native records each participant is expected to > >> produce, what each record establishes, and when absence becomes a > >> finding. That extends the existing work across the chain without > >> reopening the consequence-boundary semantics. I would not create a > >> parallel consequence-boundary model. > > Could we use that as the division >> for the -00 and cite AEB as the > existing boundary contract? I’d be glad >> to work on that text and the > related conformance cases with you before >> the first version. > > Best, > Iman >> >> _______________________________________________ > Audit mailing list -- [e-mail] > To unsubscribe send an email to [e-mail] >
> >> _______________________________________________
> >> Audit mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
_______________________________________________
Audit mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]