[Audit] Re: Charter Comments -- more specific on the scope?
Iman Schrock <team@emiliaprotocol.ai> Tue, 06 October 2026 01:06 UTC
Received: from mail-oo2-x28.google.com (mail-oo2-x28.google.com [IPv6:2607:f8b0:4864:31::28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 968EF4B for <audit@ietf.org>; Tue, 06 Oct 2026 01:06:10 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=emiliaprotocol.ai header.s=google header.b="X/d7+tys"; spf=pass (mx.ietf.org: domain of team@emiliaprotocol.ai designates 2607:f8b0:4864:31::28 as permitted sender) smtp.mailfrom=team@emiliaprotocol.ai; dmarc=pass (policy=quarantine) header.from=emiliaprotocol.ai; arc=pass ("google.com:s=arc-20260327:i=1")
Received: by mail-oo2-x28.google.com with SMTP id 006d021491bc7-6dd0088ec00so749619eaf.2 for <audit@ietf.org>; Mon, 05 Oct 2026 18:06:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1791248770; cv=none; d=google.com; s=arc-20260327; b=M1YHE4P0AO4cBXfXZORYiEgYHfYcQW/JoWtgtT2fnoyzZmE37kID7Cmye8NzkL8fC/ Sw8jdyWiGvna42Rb5tUwaUffKEAokoeIgt07yU4TwIiMTtcSPNjF77OYL5mtOTRVJHyN dLo/kLe7aRkQtDnx6H19MQoqPIR2HXNpJ13gYB4l4bYkVaYgk3qlwADkwG627r1r9nDw 7JyBa2cGp9WITvvf+6S6m3QtGBV4BGhjinDA6clH+wlR9VkDXqMZbOx+qOjiXfu6HW/a OxmU2jJodpUXxBr9z2MdfMr7O9bZhYFK+f8DtX4NHyMcb2Ci6tUXOxfTxrMIItxfR5YN qDlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=laXRlp9lki7tal8G0fc4kaOsMeEAMkqNVJO3rVyVEEQ=; fh=B9P4taNgdviM2BCoIKVRs9dAlCKg4pMg/VLgoPFAgBg=; b=rjjpPzHuB6uIFfsd1wbn3WnBkPLnljt9PboLIex/FL95hUAoyRQIysjHTdF0P0dGVF 0Q/rxgyVj2lW6Z7ZtDi4rrJgMBtIfF71/v1+ekWSuMQAzqrICvh6T5JbcXb+pBv6lbDg 9VKj1QJXyS6xJrY+E9+m2bFqVLhfLgXlYlugDdtPgqdTkvatR8Sg20DcCCiMdrmT8ihc Fcc9XCEo0JmNHHb4qu61Dxdm0Yc74WKk6mNcjJJyskYzUe1qHuQd42tCk0+ayJawcZu7 op1KG9xyBBnQ5PfdyoEtCAGwwtthZx+XLrlq7y1dAvTAlee9+t7s/eDCGG/KKthcXE2f qwZA==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emiliaprotocol.ai; s=google; t=1791248770; x=1791853570; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=laXRlp9lki7tal8G0fc4kaOsMeEAMkqNVJO3rVyVEEQ=; b=X/d7+tys0VIfqefwlH2mNsZUrQ5dl/UI0TB7zG5MbeLNwQBOxLITBQ8lVHnGy07SU8 clFvablVXZaTcxobGk0XMp6w2OUoBCe+gWzYnyxaxy+75b8DaW4m1jxxg6IOgcaFNotW +57NKaKWTkDwu9oUTOMdpuU8dGCMyQb8LspfOxBfQ6oLsgToDB79lEUfETlmKZb+PgWH HfaenE+xdcHwublfyrcqdQw4955i7qSZvIVaIPnMrNOj4aW9rvBusqeznZ45u1UOVxmh ej4ryPYThh5kP+1kNwPe20DSYVmbcd5jxAMMqhxL2A4WbELs/ecLab1/S50ppmLYsUQc g3jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791248770; x=1791853570; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=laXRlp9lki7tal8G0fc4kaOsMeEAMkqNVJO3rVyVEEQ=; b=K31ttPVh08XX4CHRcs+iLxas3KJQurGLvwzuzAmVBG/8iry1YLnxqqiUwPJe15atzX 0Z0TLbwHFOanHg8IMKhXyp/YUmJUT1hW5ZU3HynJZvhPAWCIFdFB9eUSuNqo84syPywE 4NtjCm06gGIGtLy1CPDmJBvSRrEQYaPq4bXqvFM/E9wo0pFAv6wUWo4/IO38GqT2K+3H GPvHQLzS2r+tlDjOQz7r0k5osx7uSX2KFpfEOeyAbnlMfDX9X3EoWC2xTqP5CU1ojqfN DCBozyuUqBKrjfGeaVEq6CciLStTXlnMUjo3xr6dLcyN744I6+uCTFb0EifTKnqs/tP3 mgtw==
X-Forwarded-Encrypted: i=1; AKwUvBzztVPS+ODgTtHvq/VHJw9Dgo8cyQV7+7lcEK1mRAFhaF+SbSavkqQeo22PiUvV83/5crhX6Q==@ietf.org
X-Gm-Message-State: AFuF++kLOdwN5QFbvIbV9LfuCNYxex5rtzZtXN6n4vBwc53jPG0dAlFj 7Q76t8oIH7elcx/1nDH8ZKNiYtPQgVh4LCekxJGjy5lqzNQllu4AZACpbXyFhFUPqF/3fpC0Ude 6fE0Ed6eOBJN2JzKQMWX0YvKVupNVJPZi5QUoLwqE9+Q=
X-Gm-Gg: AYBFou2DGdMnS4UemjwK1zTpC5zmhA8yR5Hj5DeV6QU8KV2Cge6f7wSH2TWcbmDPMqd do9ICAWsxkRFFPsurRdeMzZwbjhR9R0qBbA1VA0S9toH1sZFmXc+LN+de9y1btWNXQgLFlnxnUs SDdhXFzRT8Lvntri+Qvb0n+mLV+qHZ7iWWfABE5qtwW5YkFure33kiuWq7aNRZikuJL5G3EancB VGcQYatwKp1saHYzSZ5tDbc08HDa6kRdSrGo9SJhwfzQxY8AyYs0eO1fy90ZSp76gBXXSgGz4D5 eD/tnT94+/Sl7H+p+FSc+o/JmZ0ngRFFfKbQqTQh+WO2ud8PWWr4gbTWzzFXrxeiMNvHINljwKa IBSg0nXE0U7EFbxIPKfABKgRJRX/4AOeTK7/eYZOVtoKO/cbpRc2HywZM1fYtGLBhs8hc
X-Received: by 2002:a05:6820:4c04:b0:6de:3bb0:aa5a with SMTP id 006d021491bc7-6df3612c902mr10225439eaf.81.1791248769665; Mon, 05 Oct 2026 18:06:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAOfgHgrWahjU7yCKC3EBsPTc_SXUdzeYhzob5Oeqa9_xbb=wBA@mail.gmail.com> <37EBF05A-CD7E-42FA-A8F2-2E65B39610C6@mainlabs.ai>
In-Reply-To: <37EBF05A-CD7E-42FA-A8F2-2E65B39610C6@mainlabs.ai>
From: Iman Schrock <team@emiliaprotocol.ai>
Date: Mon, 05 Oct 2026 18:05:58 -0700
X-Gm-Features: AclHuK_ovd2bu2eeR9fD9AoH7afXfpSJLdgEd6NrqgPXM4zK_HVnqRdAaG5rd6w
Message-ID: <CAOfgHgp9JmNEQm-qD5NHh+Y2Z3t_qEYsbUTMi-b9eWRL-2sxfg@mail.gmail.com>
To: sumit@mainlabs.ai
Content-Type: multipart/alternative; boundary="0000000000009edb4c065d219a14"
X-Spamd-Bar: ---
Message-ID-Hash: S5FLTM7RUOYLJPSG6F2CQDEW6ITZW7TT
X-Message-ID-Hash: S5FLTM7RUOYLJPSG6F2CQDEW6ITZW7TT
X-MailFrom: team@emiliaprotocol.ai
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ietf@kuehlewind.net, liuchunchi@huawei.com, audit@ietf.org, henk.birkholz@ietf.contact
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [Audit] Re: Charter Comments -- more specific on the scope?
List-Id: "Agent Use of Delegation and Interaction Traceability (AUDIT)" <audit.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/audit/u04Utry2tPGRqJ_f-SmRk_EMW88>
List-Archive: <https://mailarchive.ietf.org/arch/browse/audit>
List-Help: <mailto:audit-request@ietf.org?subject=help>
List-Owner: <mailto:audit-owner@ietf.org>
List-Post: <mailto:audit@ietf.org>
List-Subscribe: <mailto:audit-join@ietf.org>
List-Unsubscribe: <mailto:audit-leave@ietf.org>
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 <sumit@mainlabs.ai> 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 <team@emiliaprotocol.ai> 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] Charter Comments -- more specific on the … Liuchunchi(Peter)
- [Audit] Re: Charter Comments -- more specific on … Henri Sirkkavaara
- [Audit] Re: Charter Comments -- more specific on … Liuchunchi(Peter)
- [Audit] Re: Charter Comments -- more specific on … Mirja Kuehlewind (IETF)
- [Audit] Re: Charter Comments -- more specific on … Sumit Ahuja
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Sumit Ahuja
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Sumit Ahuja
- [Audit] Re: Charter Comments -- more specific on … Francesco Marinoni Moretto
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Francesco Marinoni Moretto
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Henri Sirkkavaara
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Sumit Ahuja
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Liuchunchi(Peter)
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Mikhail Sergeev
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Mikhail Sergeev
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Liuchunchi(Peter)
- [Audit] Re: Charter Comments -- more specific on … Nicholas Templeman
- [Audit] Re: Charter Comments -- more specific on … Lars Kersten Kroehl
- [Audit] Re: Charter Comments -- more specific on … Iman Schrock
- [Audit] Re: Charter Comments -- more specific on … Sumit Ahuja
- [Audit] Re: Charter Comments -- more specific on … Lars Kersten Kroehl
- [Audit] Re: Charter Comments -- more specific on … Lars Kersten Kroehl
- [Audit] Re: Charter Comments -- more specific on … Henri Sirkkavaara
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Henri Sirkkavaara
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Lars Kersten Kroehl
- [Audit] Re: Charter Comments -- more specific on … Henri Sirkkavaara
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Lars Kersten Kroehl
- [Audit] Re: Charter Comments -- more specific on … Heime.Jorgen
- [Audit] Re: Charter Comments -- more specific on … Mirja Kuehlewind