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

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

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] >