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

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

Hi Mikhail,

Thank you for this exceptionally sharp question. You have hit on the exact durability boundary required for a production-grade Enforcement Point (EP) profile.

To address your core question regarding crash recovery:

1. Surviving Artifact During EP Crash
If an application effect succeeds but the EP crashes before the asynchronous audit batch is signed, the surviving durable artifact is the "Evidence enabling independent verification" (the 180B wire record + TLS Exporter binding context hash + atomic state claim receipt).

2. Durable Handoff Contract
Under the EP profile contract, downstream dispatch to the application MUST NOT occur until this 180B pre-effect evidence bundle is atomically staged in the durable primary state store (e.g., WAL / primary memory cluster via single-command SET NX).

Therefore, if the EP worker crashes post-commit:
- The effect is NOT repeated.
- The recovery process reads the durably staged raw verification evidence from the primary store to reconstruct and sign the missing batch receipt asynchronously.
- Independent third-party auditors can re-verify the signature and channel exporter binding directly from the recovered raw evidence, rather than relying solely on a retained verifier attestation.

3. Draft-13 Disclaimers vs. Draft-14 Specifications
As you noted, draft-helmprotocol-tttps-13 deliberately bounded single-record wire processing and left persistence/recovery unspecified to keep the baseline abstract.

In the upcoming draft-helmprotocol-tttps-14 update (preparing for submission before the I-D deadline), Section 10.2 and Section 9.2 are expanded to explicitly define:
- The mandatory WAL/staging handoff contract before downstream execution release.
- The async Merkle-tree batch receipt structure.
- Baseline benchmark bounds specifically scoped to tested multi-primary RAM deployment profiles (distinguishing O(1) wire/state validation from end-to-end ledger persistence).

This provides the exact end-to-end durability and recovery properties you referenced while preserving the O(1) fast-path validation boundary.

Heime

-------- Original Message --------
On Sunday, 10/11/26 at 10:32 Mikhail Sergeev <[e-mail]> wrote:

> Hi Heime,
>
> One specific question about the batching description: I could not find an explicit asynchronous receipt-signing contract in draft-helmprotocol-tttps-13. Section 10.2 leaves the receipt format unspecified.
>
> Section 9.2 already requires crash-safe claim/commit handling and completion recovery; Section 2.5 keeps completed action and receipt persistence separately observable. Consider an application commit that succeeds, followed by an EP crash before the corresponding audit batch is durably stored. Which durable artifact survives that crash and supports the recovered receipt: evidence enabling independent verification, or a retained attestation of the live verifier's observation, as distinguished in Section 10.2? Recovering the operation result without repeating the effect does not by itself recover missing verification evidence.
>
> Could you identify the batching/recovery contract and a benchmark for the exact implementation revision that includes that durable handoff? Section 1.3 bounds single-record processing and explicitly excludes persistence and crash recovery; Section 9.3 disclaims implied line-rate performance, and Section 13.2 leaves deployment performance unmeasured. An atomic nonce claim alone does not establish those end-to-end properties.
>
> This question concerns the batching and recovery path described for the EP profile. PR #36's proposed text already separates admission decisions from action outcomes.
>
> Best,
> Mikhail
>
> On Sat, 10 Oct 2026 03:25:52 +0000, "Heime.Jorgen" <heime.jorgen=[e-mail]> wrote:
>
>> Hi Peter, Thanks for bringing up these essential efficiency considerations. Addressing high-throughput perimeter environments (tens to hundreds of Gbps) is critical for keeping the Enforcement Point (EP) profile practical for carrier-scale hardware. To prevent cryptographic validation from stalling the data path at scale, the TTTPS profile (draft-helmprotocol-tttps) explicitly decouples the real-time admission gate from background reporting across three technical layers: 1. Fast-Path Wire Validation (Zero-Copy, Fixed 180B) At line-rate, perimeter security devices cannot afford payload JSON parsing, deep packet inspection (DPI), or intent evaluation at the admission boundary. TTTPS relies on a fixed 180-octet binary wire layout. This allows O(1) zero-copy offset checks and session exporter validation before touching application payloads. 2. Lock-Free Atomic State Execution (RAM-Speed Primary Clusters) To execute replay checks across multi-gateway nodes without state-store contention, the atomic nonce claim interfaces directly with distributed in-memory primary clusters (such as AWS MemoryDB or RAM-speed primary nodes). Using single-command O(1) atomic claims (e.g., SET NX) at the primary node guarantees state isolation without locks or database transaction overhead. 3. Asynchronous Batch Reporting While the admission decision MUST be instant and synchronous per-request to prevent unauthorized state-commit, downstream audit reporting (to SCITT or SIEM) does NOT need to block incoming traffic. The EP profile explicitly permits asynchronous, batched cryptographic signing (such as Merkle tree aggregation) for audit receipts, eliminating logging latency from the active packet path. Decoupling instant pre-effect admission from batched receipt generation gives perimeter hardware the necessary flexibility to operate at Gbps throughput while maintaining cryptographically verifiable execution boundaries. Best regards, Heime Jorgen -------- Original Message -------- On Saturday, 10/10/26 at 12:17 Liuchunchi(Peter) <[e-mail]> wrote: Thanks Heime, Iman. Explicitly mentioning the Enforcement Points narrows the focus and is clearer now. Just one thing I would suggest take into consideration is efficiency, especially on the Pre-effect Sealing part that require timely blocking and reporting. For perimeter security products, analyzing additional contextual information like tool calling intents requires deeper packet parsing, even on-the-spot inference using embedded computing power. These are time-consuming. So I suggest 1. keeping implementation requirements flexible as profiles (as Iman mentioned below). 2. Allow a batch-style cryptographic signing, rather than per-request-level, and maybe relax a little bit of timely reporting requirements (maybe I didn’t totally get the necessity of these requirements). For perimeter security products that have tens or hundreds Gbps throughput, this may matters more than a little bit. Other than that I don’t have further considerations at the time. Best, Peter > -----Original Message----- > From: Heime.Jorgen <[e-mail]> > Sent: Saturday, October 10, 2026 10:31 AM > To: Iman Schrock <team=[e-mail]> > Cc: [e-mail]; [e-mail]; > [e-mail]; [e-mail]; Liuchunchi(Peter) > <[e-mail]>; [e-mail]; [e-mail] > Subject: Re: [Audit] Re: Charter Comments -- more specific on the scope? > > 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-evidenc > > >>> >>>> e-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] > _______________________________________________ Audit mailing list -- [e-mail] To unsubscribe send an email to [e-mail]