Return-Path: X-Original-To: scitt@mail2.ietf.org Delivered-To: scitt@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 213D61328ED96 for ; Mon, 31 Aug 2026 12:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788206167; bh=Y4f9dCS4u01ear+0RRQxANbesDAXLpkTEQuBA1eHf40=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=lkmx5Cz7hnTLVNIj1fx2JzjMXvUfgXoZnBNhOb5Z2RWBxIW8KwImnF3OaGQNYLgXD SsFDmHrOH2dFDNQ9xsKeGSoJ2iFhi+C9Ti2P2X4trIsYvSvSGBPUtj4uSpTk2/ZOuw o5iDghgZ2TVNdurRbSE/JOkTz5udhQ+MN93glEiA= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=phionyx.ai Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hUlGDwVZWvp for ; Mon, 31 Aug 2026 12:56:04 -0700 (PDT) Received: from sender-op-o19.zoho.eu (sender-op-o19.zoho.eu [136.143.169.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2363F1328ECF3 for ; Mon, 31 Aug 2026 12:56:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788206154; cv=none; d=zohomail.eu; s=zohoarc; b=bv6bOvAZvhwO6nlcUtzDtOPrZop75HzZo8hIhrl5YhmKufP+3HhqO+hNFVdRbCsgS0QpbluP8FekF8hqx2xNRq5Gyr0LqBcTiLPQOn50yij3rypDelYmJ2loVmT/gaU4wOSG0OL+cYyaHySqZmTX7q3pnxfxVz//XS1XlYWtoZk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1788206154; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=Y4f9dCS4u01ear+0RRQxANbesDAXLpkTEQuBA1eHf40=; b=Oc4pR84lVJ8C1vG38n//4xJK6DRNzTcVnwa1BK8NTcvEDrfddhemcdxymLOKKhn5/pKzh97gGWIaTf3OjryXV1dPQhaviE6xCwj0CalQNO6nSnF5YA1jJVYUyCl4pOpFpk5+2lE+1ryQXBTPeIN9u3snjfrubzthHzyGOPyIghU= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=phionyx.ai; spf=pass smtp.mailfrom=founder@phionyx.ai; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1788206154; s=zmail; d=phionyx.ai; i=founder@phionyx.ai; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=Y4f9dCS4u01ear+0RRQxANbesDAXLpkTEQuBA1eHf40=; b=lc3DEAFbvc7KP9unxsVB7nFmfF1G/19VpzyaUJ8VvxmEQEOdrvFyVU0NougX6RGx hx+B7JvhHQkL2O9Fx90++WKg7CbMOA4z2ewfnDQiFYfzucR6gqumq0OjHBUX5hFWBbv fjbxVAwxlxrRJ7kEkIqvVvFlbq4FRa6jj1nYns5A= Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1788206154035416.16488980291854; Mon, 31 Aug 2026 21:55:54 +0200 (CEST) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1788206152867607.8177705449705; Mon, 31 Aug 2026 21:55:52 +0200 (CEST) Date: Mon, 31 Aug 2026 22:55:52 +0300 From: Ali Toygar Abak To: "Iman Schrock" Message-Id: <1a059647c95.52b5c00d1669474.5350363334433611579@phionyx.ai> In-Reply-To: References: <1a059195afd.4565299a1665355.5803749020539612109@phionyx.ai> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5146272_792564462.1788206152854" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Message-ID-Hash: IRGUY2LS4V52VTLCJAXDQJ5WJ6DQZHVE X-Message-ID-Hash: IRGUY2LS4V52VTLCJAXDQJ5WJ6DQZHVE X-MailFrom: founder@phionyx.ai X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: scitt X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSCITT=5D_Re=3A_New_I-D=3A_Evidence_Requirements_for_Agent_Contr?= =?utf-8?q?ol_Delivery_and_Outcome_Reconciliation_=28draft-abak-agent-contro?= =?utf-8?q?l-delivery-evidence-00=29?= List-Id: "Supply Chain Integrity, Transparency, and Trust" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_5146272_792564462.1788206152854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Iman, Thank you. I agree that the target-multiplicity case exposes a real gap in = -00. The current text preserves a target or resolution input on the issuer side = and a receiver identity on the receiver side, but it does not make the reco= nciliation unit explicit when one instruction resolves to more than one req= uired enforcement target. As you point out, that allows one matching receiver observation to satisfy = an instruction-level CONFIRMED result while another required path remains o= pen. Section 9.3 acknowledges the operational failure mode, but Sections 5 = and 6 do not currently prevent that stronger delivery claim. I think your description =E2=80=94 existential evidence accidentally satisf= ying a universal delivery claim =E2=80=94 captures the problem precisely. My current preference is the second contract you suggest rather than requir= ing a new instruction identifier for every target: an instruction that resolves to multiple required enforcement targets binds= a closed required-target set, or a verifiable reference that resolves to s= uch a set under the declared profile; reconciliation assigns a disposition to each instruction-target obligation; a receiver observation can satisfy only the target identity and boundary to= which it is verifiably bound; the parent instruction can be reported as fully confirmed only if every req= uired instruction-target obligation is CONFIRMED; and an open, unresolved, or otherwise non-closed required-target population can= not support a complete-delivery or PASS claim. That also suggests conserving target obligations separately from parent ins= tructions when target multiplicity exists, rather than allowing instruction= -level population conservation to hide an uncovered path. I also agree with the freeze race. APPLIED for the freeze must not retroact= ively relabel an operation that was already consumed or in flight before th= e freeze took effect, nor establish that an external effect already produce= d by that operation was reversed. I would like to add a conformance case co= vering that composition boundary while leaving the exact execution and cons= equential-effect semantics to the adjacent action-evidence work. Your references to draft-schrock-ep-revocation-statement and draft-schrock-= ep-outcome-binding are useful here. Tiago Pinto has also just pointed out a= narrower composition seam with draft-pinto-agent-authz-contestability-00: = its effect model deliberately separates acceptance of a declared effect pol= icy, authenticated triggering, ordering, and claimed application. I am goin= g to compare these adjacent models carefully before -01 so the control-deli= very draft composes with existing boundaries rather than restating them. And yes, please send the exact fixture if you are willing. I would prefer t= o test the -01 wording against your case rather than reconstruct a weaker v= ersion of it. Thanks =E2=80=94 this is exactly the kind of adversarial review I was hopin= g for. Best, Ali Toygar Abak Phionyx https://phionyx.ai From: Iman Schrock To: Date: Mon, 31 Aug 2026 22:05:16 +0300 Subject: [SCITT] Re: New I-D: Evidence Requirements for Agent Control Deliv= ery and Outcome Reconciliation (draft-abak-agent-control-delivery-evidence-= 00) Ali, all,=20 =20 The lifecycle separation is useful, and Section 13 draws the boundary=20 with AEB correctly: AEB follows a consequential action toward its=20 effect; this draft follows a stop or revoke instruction toward the=20 runtime constraint.=20 =20 My first failure is target multiplicity at reconciliation. R-CD-4=20 requires a target or resolution input, R-CD-5 requires a receiver=20 identity, and CONFIRMED then requires a matching instruction=20 identifier and content binding. I do not see a normative step that=20 binds the resolved target to that receiver, or an accounting unit that=20 prevents one receiver observation from satisfying a control that=20 resolves to several enforcement paths.=20 =20 For example:=20 =20 - ctrl-1 resolves to EP-A and EP-B.=20 - A reads and applies it.=20 - B produces no receiver observation and remains able to dispatch.=20 - Under Section 6.1, ctrl-1 can be CONFIRMED. The issuer population in=20 Section 6.3 still conserves. Section 9.3 says the control may=20 nevertheless be ineffective.=20 =20 That is existential evidence for a universal delivery claim.=20 =20 I think the model needs one of two contracts: every intended path gets=20 its own instruction identifier and disposition, or the instruction=20 binds a closed target set and reconciliation produces one=20 sub-disposition per target before the parent can be CONFIRMED. An open=20 or unresolved target population should preclude PASS. R-CD-4 and=20 R-CD-5 should also require exact agreement between the resolved target=20 and the receiver identity and boundary, so the right instruction at=20 the wrong enforcement point cannot confirm delivery.=20 =20 Two adjacent drafts may help define the composition seam.=20 draft-schrock-ep-revocation-statement-01 defines the upstream signed=20 control object and says explicitly that it proves the revoker acted,=20 not that anyone received the revocation.=20 draft-schrock-ep-outcome-binding-00 separates accepted dispatch from=20 independently observed effect and keeps missing or unauthenticated=20 required observations indeterminate. With AEB, the chain is revocation=20 statement, control delivery and enforcement evidence,=20 consequential-action boundary evidence, and effect reconciliation. No=20 link implies the next.=20 =20 One race would be useful in the conformance set: O1 crosses provider=20 entry, then a freeze commits, and O2 is blocked. O1 remains consumed=20 or in flight and requires outcome reconciliation. Delivery or APPLIED=20 status for the freeze cannot relabel O1 or prove that an external=20 effect was reversed. The vector should bind the control epoch, closed=20 target population, effect predicate, and observation window.=20 =20 I can contribute an exact fixture if useful.=20 =20 Best,=20 Dr. Iman=20 =20 --=20 SCITT mailing list -- mailto:scitt@ietf.org=20 To unsubscribe send an email to mailto:scitt-leave@ietf.org ------=_Part_5146272_792564462.1788206152854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Hi Iman,

Thank you. I agree that the target-multiplicity= case exposes a real gap in -00.


As you point out, that allows one matc= hing receiver observation to satisfy an instruction-level CONFIRMED result while an= other required path remains open. Section 9.3 acknowledges the operational = failure mode, but Sections 5 and 6 do not currently prevent that stronger d= elivery claim.

I think your description =E2=80=94 existential evidence accidentally sa= tisfying a universal delivery claim =E2=80=94 captures the problem precisel= y.

My curr= ent preference is the second contract you suggest rather than requiring a n= ew instruction identifier for every target:

  • an instruction that resolves to multiple requ= ired enforcement targets binds a closed required-target set, or a verifiabl= e reference that resolves to such a set under the declared profile;<= span class=3D"font" style=3D"font-family: 'courier new',courier,monospace;"= >
  • reconciliation assigns a disposition to each instruction-targ= et obligation;
  • a receiver observation can satisfy only= the target identity and boundary to which it is verifiably bound;=
  • the parent instruction can be reported as fully confirmed only = if every required instruction-target obligation is CONFIRMED; and
  • an open, unresolved, or otherwise non-closed required-target populat= ion cannot support a complete-delivery or PASS claim.

    • That also suggests conserving = target obligations separately from parent instructions when target multipli= city exists, rather than allowing instruction-level population conservation= to hide an uncovered path.

    I also agree with the freeze race. APPLIED for the freeze must= not retroactively relabel an operation that was already consumed or in fli= ght before the freeze took effect, nor establish that an external effect al= ready produced by that operation was reversed. I would like to add a confor= mance case covering that composition boundary while leaving the exact execu= tion and consequential-effect semantics to the adjacent action-evidence wor= k.

    Your r= eferences to draft-sch= rock-ep-revocation-statement and draft-schrock-ep-outcome-binding= are useful here. Tiago Pinto has also just pointed out a narrower composit= ion seam with draft-pi= nto-agent-authz-contestability-00: its effect model delib= erately separates acceptance of a declared effect policy, authenticated tri= ggering, ordering, and claimed application. I am going to compare these adj= acent models carefully before -01 so the control-delivery draft composes wi= th existing boundaries rather than restating them.

    <= p data-start=3D"2861" data-end=3D"3024">And yes, please send the exact fi= xture if you are willing. I would prefer to test the -01 wording against yo= ur case rather than reconstruct a weaker version of it.

    Thanks =E2=80=94 this is= exactly the kind of adversarial review I was hoping for.

    Best,

    Ali Toygar Abak

    Phionyx
    https://= phionyx.ai



From: Iman Schrock <team=3D40emiliaprotocol.ai@dmarc.= ietf.org>
To: <scitt@ietf.org>
Date: Mon, 31 Aug 2026 22:05:= 16 +0300
Subject: [SCITT] Re: New I-D: Evidence Requirements for Agent C= ontrol Delivery and Outcome Reconciliation (draft-abak-agent-control-delive= ry-evidence-00)

Ali, all,

The lifecycle separation is= useful, and Section 13 draws the boundary
with AEB correctly: AEB foll= ows a consequential action toward its
effect; this draft follows a stop= or revoke instruction toward the
runtime constraint.

My first= failure is target multiplicity at reconciliation. R-CD-4
requires a ta= rget or resolution input, R-CD-5 requires a receiver
identity, and CONF= IRMED then requires a matching instruction
identifier and content bindi= ng. I do not see a normative step that
binds the resolved target to tha= t receiver, or an accounting unit that
prevents one receiver observatio= n from satisfying a control that
resolves to several enforcement paths.=

For example:

- ctrl-1 resolves to EP-A and EP-B.
- A= reads and applies it.
- B produces no receiver observation and remains= able to dispatch.
- Under Section 6.1, ctrl-1 can be CONFIRMED. The is= suer population in
Section 6.3 still conserves. Section 9.3 says the co= ntrol may
nevertheless be ineffective.

That is existential evi= dence for a universal delivery claim.

I think the model needs one = of two contracts: every intended path gets
its own instruction identifi= er and disposition, or the instruction
binds a closed target set and re= conciliation produces one
sub-disposition per target before the parent = can be CONFIRMED. An open
or unresolved target population should preclu= de PASS. R-CD-4 and
R-CD-5 should also require exact agreement between = the resolved target
and the receiver identity and boundary, so the righ= t instruction at
the wrong enforcement point cannot confirm delivery. <= br>
Two adjacent drafts may help define the composition seam.
draft= -schrock-ep-revocation-statement-01 defines the upstream signed
control= object and says explicitly that it proves the revoker acted,
not that = anyone received the revocation.
draft-schrock-ep-outcome-binding-00 sep= arates accepted dispatch from
independently observed effect and keeps m= issing or unauthenticated
required observations indeterminate. With AEB= , the chain is revocation
statement, control delivery and enforcement e= vidence,
consequential-action boundary evidence, and effect reconciliat= ion. No
link implies the next.

One race would be useful in the= conformance set: O1 crosses provider
entry, then a freeze commits, and= O2 is blocked. O1 remains consumed
or in flight and requires outcome r= econciliation. Delivery or APPLIED
status for the freeze cannot relabel= O1 or prove that an external
effect was reversed. The vector should bi= nd the control epoch, closed
target population, effect predicate, and o= bservation window.

I can contribute an exact fixture if useful.
Best,
Dr. Iman

--
SCITT mailing list -- scitt@ietf.org
To unsubscri= be send an email to scitt-leave@ietf.org


------=_Part_5146272_792564462.1788206152854--