MIME-Version: 1.0
References: 
 <CAHCJH6GXJvLQxj-kJK1EdqE5ivz87tsmLygY9KfWN76kO1qvoA@mail.gmail.com>
 <CAOfgHgrnU_wKK3bgp19Yb02K9Omcd64om2+Fna=3MgUMfSpscw@mail.gmail.com>
In-Reply-To: 
 <CAOfgHgrnU_wKK3bgp19Yb02K9Omcd64om2+Fna=3MgUMfSpscw@mail.gmail.com>
From: Sangam Das <info@sangamdas.com>
Date: Wed, 23 Sep 2026 21:03:46 +0530
Message-ID: 
 <CAHCJH6H9od5Cx9jLbyqNPYAR7h82vCdrbP0dWPik2od+x3m_wg@mail.gmail.com>
To: Iman Schrock <team=40emiliaprotocol.ai@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c6800065c2836ef"
Message-ID-Hash: REGVG3YALOEGRCGW3D6AKOSNHQI643X6
CC: dispatch@ietf.org
Precedence: list
Subject: [dispatch] =?utf-8?q?Re=3A_New_Draft=3A_draft-das-accountable-autonomous-eff?=
	=?utf-8?q?ectuation-01_=E2=80=94_AI_Safety_and_Accountability_at_the_Effect?=
	=?utf-8?q?uation_Boundary?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dispatch/78kAtGFMD-uEQArScBTJx59BgP4>

--0000000000000c6800065c2836ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Iman,

Thank you =E2=80=94 this is extremely helpful.

I agree that AEB, CAID, BCR, and the Gate conformance work should be
treated as directly relevant existing work rather than discussed only
indirectly through OAuth, RATS, WIMSE, or other upstream mechanisms.

Your distinction between provider commitment and observed real-world effect
is particularly useful. I agree that these should not be collapsed into a
single binary result. In particular, once dispatch may have crossed the
provider boundary, a local exception is not sufficient evidence of =E2=80=
=9Cno
effect,=E2=80=9D and retrying on that assumption can itself create a duplic=
ate
consequence.

I also agree with the atomicity point. I do not intend the
execution-finality model to imply atomicity between an independently
controlled local state store and an unrelated external provider. The more
precise question is what can be made atomic or serialized inside the
locally controlled effectuation domain, what must transition to an
indeterminate state once dispatch begins, and what evidence is required
before that state can safely be resolved.

A short R1=E2=80=93R14 crosswalk would therefore be very valuable, and I wo=
uld be
glad to run an interoperability exercise against the examples in the draft.

I think the useful comparison should identify three categories:

   1.

   requirements already satisfied directly by AEB / CAID / BCR;
   2.

   requirements that can be satisfied by profiling or composing that work
   with other mechanisms; and
   3.

   any residual execution-finality requirements that remain outside those
   mechanisms.

Some of the areas I would particularly like to test in the third category
are:

   -

   whether the consequential operation is reconstructed from the actual
   native operation presented at the effectuation boundary rather than
   accepted solely from an upstream descriptor;
   -

   whether authority is bound to that exact reconstructed operation,
   destination, boundary, and current protected state;
   -

   whether alternate effect-capable paths are required to pass through the
   same boundary or an equivalent protected enforcement mechanism;
   -

   whether effectuation authority is single-use or otherwise bounded and
   consumed/reserved in conjunction with the local protected transition;
   -

   how revocation, generation/epoch changes, freshness, replay, and stale
   authorization are handled immediately before effectuation;
   -

   whether inability to establish any required predicate leaves the
   Candidate Act non-effective;
   -

   and how local admission/commitment evidence is distinguished from
   evidence that the external consequence actually occurred.

CAID also appears highly relevant to the canonicalization issue raised in
Section 17.1. Its pinned, loss-aware mapping approach looks like exactly
the kind of existing mechanism that should be compared against the draft's
ActionDescriptor requirements rather than reinvented unnecessarily.

I will add AEB, CAID, BCR, and the AEB-1 conformance work to the
related-work analysis.

Please do send the R1=E2=80=93R14 crosswalk. I would be very interested in =
testing
the two architectures against the same hostile cases and identifying
precisely where they are equivalent, composable, or materially different.

That seems much more useful than arguing terminology.

Best regards,

Sangam Das
Independent Researcher
Balasore, Odisha, India

On Wed, 23 Sept 2026 at 20:43, Iman Schrock <team=3D
40emiliaprotocol.ai@dmarc.ietf.org> wrote:

> Hi Sangam,
>
> Thanks for putting this together. I think the effectuation boundary is
> exactly the right place to focus. The requirements also line up closely
> with work we have already made concrete in EMILIA=E2=80=99s AEB, CAID, an=
d BCR
> drafts and the Gate conformance suite.
>
> One distinction may help Q7 and Q8: provider commitment and observed
> real-world effect should not collapse into one binary result. A provider
> may accept a request without the intended effect occurring, and a local
> exception cannot prove that no effect occurred. Our current profile
> therefore keeps two closed axes: provider commitment (COMMITTED,
> PROVEN_NOT_COMMITTED, or INDETERMINATE) and observed effect (
> OBSERVED_AS_REQUESTED, DIVERGED, or INDETERMINATE). Once a request
> crosses the provider boundary, unresolved state remains INDETERMINATE
> until authenticated reconciliation. It cannot safely be treated as NO
> EFFECT and retried.
>
> For Q4 and Q6, CAID lets the executor derive the material action from
> native provider inputs using pinned mappings, report semantic loss, and
> bind the result to a verifier version. AEB then consumes or reserves
> authority inside a named local atomicity domain before dispatch, keeps a
> stable native replay unit, and uses a durable DISPATCH_PENDING state for
> recovery. We deliberately do not claim atomicity across a local store and
> an unrelated provider.
>
> The relevant work is here:
>
>    - Action Evidence Boundary
>    <https://datatracker.ietf.org/doc/draft-schrock-action-evidence-bounda=
ry/>
>    - Canonical Action Identifier
>    <https://datatracker.ietf.org/doc/draft-schrock-canonical-action-ident=
ifier/>
>    - Bounded Capability Receipts
>    <https://datatracker.ietf.org/doc/draft-schrock-ep-bounded-capability-=
receipts/>
>    - AEB-1 runnable conformance profile and hostile cases
>    <https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/conf=
ormance/AEB-1-CONSEQUENCE-ADMISSION.md>
>
> These look like useful existing-work inputs to several questions in
> Section 19. I=E2=80=99d be glad to send a short R1=E2=80=93R14 crosswalk =
and run an
> interoperability exercise against your examples. Would you be open to
> adding them as related work and testing where your requirements still go
> beyond them?
>
> Best,
> Iman
>
>
> On Wed, 23 Sep 2026 17:25:42 +0530, Sangam Das <info@sangamdas.com> wrote=
:
>
> Hi DISPATCH, I have submitted a new Informational Internet-Draft examinin=
g
> an effectuation-boundary problem for AI agents and autonomous systems.
> *Draft:* draft-das-accountable-autonomous-effectuation-01 *Title:* *AI
> Safety and Accountability at the Effectuation Boundary: Protocol
> Requirements for Autonomous Actions* *Datatracker:*
> https://datatracker.ietf.org/doc/draft-das-accountable-autonomous-effectu=
ation/01/
> *The problem in 60 seconds* Autonomous and agentic systems do not
> necessarily follow a fixed execution path from initial authorization to
> final action. An agent may begin with an authorized objective, obtain new
> information, invoke additional services, change tools, re-plan, or alter =
a
> destination or operation several steps later. This creates a distinction
> between: *the action or authority established upstream* and *the actual
> consequential operation presented at the final execution boundary.* The
> draft calls this final non-bypassable point the *effectuation boundary*:
> the last practical point at which an action can still be withheld before
> producing an external consequence. The central question is whether a
> downstream component should be able to determine that the exact operation
> it is about to perform still corresponds to currently valid authority.
> *Questions for the IETF community* Section 20 intentionally leaves the
> standards outcome open and asks, among others: *Q1 =E2=80=94 Is the probl=
em
> distinct?* Is there a useful protocol distinction between general
> caller/workload authorization and verification that a particular locally
> observed consequential operation remains authorized at the point of
> effectuation? *Q11 =E2=80=94 Is a new protocol needed at all?* Could exis=
ting
> mechanisms such as OAuth, WIMSE, RATS, COSE, Transaction Tokens, or
> application-specific profiles be composed to provide the required
> properties without defining a new protocol? The draft is therefore not
> based on the assumption that a new execution-finality protocol is require=
d.
> A useful outcome could equally be an existing-protocol composition,
> profile, implementation guidance, or identification of work already
> covering the problem. *Canonicalization and semantic security* The -01
> revision also adds *Section 17.1, =E2=80=9CCanonicalization, Semantic Equ=
ivalence,
> and Descriptor Interpretation.=E2=80=9D* This addresses a security issue =
that
> becomes important when authority crosses implementations: two systems may
> cryptographically agree on a serialized object while assigning different
> meanings to one or more fields. The section therefore treats semantic
> agreement as part of the security boundary, including handling of: -
> duplicate fields; - type confusion; - unknown, absent, empty, and null
> values; - URI and identifier normalization; - versioning; - critical
> extensions; - deterministic encoding; and - cross-language conformance. T=
he
> intended invariant is not merely canonical bytes, but a *canonical
> understanding of the consequence being authorized*. *Possible IETF
> relationships* The draft discusses possible relationships with: - OAuth a=
nd
> Rich Authorization Requests; - Transaction Tokens and sender-constrained
> authorization; - WIMSE and multi-hop workload context; - RATS and
> attestation of enforcement components; - COSE for protected authorization
> objects; and - emerging AgentProto work for cross-vendor agent-to-agent a=
nd
> agent-to-tool interaction. I would particularly appreciate DISPATCH
> feedback on: 1. whether the effectuation-boundary problem is sufficiently
> distinct to merit further work; 2. whether existing IETF mechanisms alrea=
dy
> provide the required properties when properly composed; 3. whether this
> should instead be expressed as a profile or cross-WG design exercise; and
> 4. which venue, if any, would be most appropriate. Best regards, *Sangam
> Das* Independent Researcher Balasore, Odisha, India info@sangamdas.com
>
> _______________________________________________
> dispatch mailing list -- dispatch@ietf.org
> To unsubscribe send an email to dispatch-leave@ietf.org
>

--0000000000000c6800065c2836ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Iman,</p><p>Thank you =E2=80=94 this is extremely he=
lpful.</p><p>I agree that AEB, CAID, BCR, and the Gate conformance work sho=
uld be treated as directly relevant existing work rather than discussed onl=
y indirectly through OAuth, RATS, WIMSE, or other upstream mechanisms.</p><=
p>Your distinction between provider commitment and observed real-world effe=
ct is particularly useful. I agree that these should not be collapsed into =
a single binary result. In particular, once dispatch may have crossed the p=
rovider boundary, a local exception is not sufficient evidence of =E2=80=9C=
no effect,=E2=80=9D and retrying on that assumption can itself create a dup=
licate consequence.</p><p>I also agree with the atomicity point. I do not i=
ntend the execution-finality model to imply atomicity between an independen=
tly controlled local state store and an unrelated external provider. The mo=
re precise question is what can be made atomic or serialized inside the loc=
ally controlled effectuation domain, what must transition to an indetermina=
te state once dispatch begins, and what evidence is required before that st=
ate can safely be resolved.</p><p>A short R1=E2=80=93R14 crosswalk would th=
erefore be very valuable, and I would be glad to run an interoperability ex=
ercise against the examples in the draft.</p><p>I think the useful comparis=
on should identify three categories:</p><ol start=3D"1"><li><p>requirements=
 already satisfied directly by AEB / CAID / BCR;</p></li><li><p>requirement=
s that can be satisfied by profiling or composing that work with other mech=
anisms; and</p></li><li><p>any residual execution-finality requirements tha=
t remain outside those mechanisms.</p></li></ol><p>Some of the areas I woul=
d particularly like to test in the third category are:</p><ul><li><p>whethe=
r the consequential operation is reconstructed from the actual native opera=
tion presented at the effectuation boundary rather than accepted solely fro=
m an upstream descriptor;</p></li><li><p>whether authority is bound to that=
 exact reconstructed operation, destination, boundary, and current protecte=
d state;</p></li><li><p>whether alternate effect-capable paths are required=
 to pass through the same boundary or an equivalent protected enforcement m=
echanism;</p></li><li><p>whether effectuation authority is single-use or ot=
herwise bounded and consumed/reserved in conjunction with the local protect=
ed transition;</p></li><li><p>how revocation, generation/epoch changes, fre=
shness, replay, and stale authorization are handled immediately before effe=
ctuation;</p></li><li><p>whether inability to establish any required predic=
ate leaves the Candidate Act non-effective;</p></li><li><p>and how local ad=
mission/commitment evidence is distinguished from evidence that the externa=
l consequence actually occurred.</p></li></ul><p>CAID also appears highly r=
elevant to the canonicalization issue raised in Section 17.1. Its pinned, l=
oss-aware mapping approach looks like exactly the kind of existing mechanis=
m that should be compared against the draft&#39;s ActionDescriptor requirem=
ents rather than reinvented unnecessarily.</p><p>I will add AEB, CAID, BCR,=
 and the AEB-1 conformance work to the related-work analysis.</p><p>Please =
do send the R1=E2=80=93R14 crosswalk. I would be very interested in testing=
 the two architectures against the same hostile cases and identifying preci=
sely where they are equivalent, composable, or materially different.</p><p>=
That seems much more useful than arguing terminology.</p><p>Best regards,</=
p><p>Sangam Das<br>Independent Researcher<br>Balasore, Odisha, India</p></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Wed, 23 Sept 2026 at 20:43, Iman Schrock &lt;team=3D<=
a href=3D"mailto:40emiliaprotocol.ai@dmarc.ietf.org">40emiliaprotocol.ai@dm=
arc.ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><p>Hi Sangam,</p>
<p>Thanks for putting this together. I think the effectuation boundary is e=
xactly the right place to focus. The requirements also line up closely with=
 work we have already made concrete in EMILIA=E2=80=99s AEB, CAID, and BCR =
drafts and the Gate conformance suite.</p>
<p>One distinction may help Q7 and Q8: provider commitment and observed rea=
l-world effect should not collapse into one binary result. A provider may a=
ccept a request without the intended effect occurring, and a local exceptio=
n cannot prove that no effect occurred. Our current profile therefore keeps=
 two closed axes: provider commitment (<code>COMMITTED</code>, <code>PROVEN=
_NOT_COMMITTED</code>, or <code>INDETERMINATE</code>) and observed effect (=
<code>OBSERVED_AS_REQUESTED</code>, <code>DIVERGED</code>, or <code>INDETER=
MINATE</code>). Once a request crosses the provider boundary, unresolved st=
ate remains <code>INDETERMINATE</code> until authenticated reconciliation. =
It cannot safely be treated as <code>NO EFFECT</code> and retried.</p>
<p>For Q4 and Q6, CAID lets the executor derive the material action from na=
tive provider inputs using pinned mappings, report semantic loss, and bind =
the result to a verifier version. AEB then consumes or reserves authority i=
nside a named local atomicity domain before dispatch, keeps a stable native=
 replay unit, and uses a durable <code>DISPATCH_PENDING</code> state for re=
covery. We deliberately do not claim atomicity across a local store and an =
unrelated provider.</p>
<p>The relevant work is here:</p>
<ul>
<li><a href=3D"https://datatracker.ietf.org/doc/draft-schrock-action-eviden=
ce-boundary/" target=3D"_blank">Action Evidence Boundary</a></li>
<li><a href=3D"https://datatracker.ietf.org/doc/draft-schrock-canonical-act=
ion-identifier/" target=3D"_blank">Canonical Action Identifier</a></li>
<li><a href=3D"https://datatracker.ietf.org/doc/draft-schrock-ep-bounded-ca=
pability-receipts/" target=3D"_blank">Bounded Capability Receipts</a></li>
<li><a href=3D"https://github.com/emiliaprotocol/emilia-protocol/blob/main/=
docs/conformance/AEB-1-CONSEQUENCE-ADMISSION.md" target=3D"_blank">AEB-1 ru=
nnable conformance profile and hostile cases</a></li>
</ul>
<p>These look like useful existing-work inputs to several questions in Sect=
ion 19. I=E2=80=99d be glad to send a short R1=E2=80=93R14 crosswalk and ru=
n an interoperability exercise against your examples. Would you be open to =
adding them as related work and testing where your requirements still go be=
yond them?</p>
<p>Best,<br>Iman</p><br><br><div class=3D"gmail_quote">On Wed, 23 Sep 2026 =
17:25:42 +0530, Sangam Das &lt;<a href=3D"mailto:info@sangamdas.com" target=
=3D"_blank">info@sangamdas.com</a>&gt; wrote:<br><blockquote><div style=3D"=
white-space:pre-wrap">Hi DISPATCH,

I have submitted a new Informational Internet-Draft examining an
effectuation-boundary problem for AI agents and autonomous systems.

*Draft:* draft-das-accountable-autonomous-effectuation-01


*Title:* *AI Safety and Accountability at the Effectuation Boundary:
Protocol Requirements for Autonomous Actions*
*Datatracker:*
<a href=3D"https://datatracker.ietf.org/doc/draft-das-accountable-autonomou=
s-effectuation/01/" target=3D"_blank">https://datatracker.ietf.org/doc/draf=
t-das-accountable-autonomous-effectuation/01/</a>
*The problem in 60 seconds*

Autonomous and agentic systems do not necessarily follow a fixed execution
path from initial authorization to final action.

An agent may begin with an authorized objective, obtain new information,
invoke additional services, change tools, re-plan, or alter a destination
or operation several steps later.

This creates a distinction between:

*the action or authority established upstream*

and

*the actual consequential operation presented at the final execution
boundary.*

The draft calls this final non-bypassable point the *effectuation boundary*=
:
the last practical point at which an action can still be withheld before
producing an external consequence.

The central question is whether a downstream component should be able to
determine that the exact operation it is about to perform still corresponds
to currently valid authority.
*Questions for the IETF community*

Section 20 intentionally leaves the standards outcome open and asks, among
others:

*Q1 =E2=80=94 Is the problem distinct?*
Is there a useful protocol distinction between general caller/workload
authorization and verification that a particular locally observed
consequential operation remains authorized at the point of effectuation?

*Q11 =E2=80=94 Is a new protocol needed at all?*
Could existing mechanisms such as OAuth, WIMSE, RATS, COSE, Transaction
Tokens, or application-specific profiles be composed to provide the
required properties without defining a new protocol?

The draft is therefore not based on the assumption that a new
execution-finality protocol is required. A useful outcome could equally be
an existing-protocol composition, profile, implementation guidance, or
identification of work already covering the problem.
*Canonicalization and semantic security*

The -01 revision also adds *Section 17.1, =E2=80=9CCanonicalization, Semant=
ic
Equivalence, and Descriptor Interpretation.=E2=80=9D*

This addresses a security issue that becomes important when authority
crosses implementations: two systems may cryptographically agree on a
serialized object while assigning different meanings to one or more fields.

The section therefore treats semantic agreement as part of the security
boundary, including handling of:

   - duplicate fields;
   - type confusion;
   - unknown, absent, empty, and null values;
   - URI and identifier normalization;
   - versioning;
   - critical extensions;
   - deterministic encoding; and
   - cross-language conformance.

The intended invariant is not merely canonical bytes, but a *canonical
understanding of the consequence being authorized*.
*Possible IETF relationships*

The draft discusses possible relationships with:

   - OAuth and Rich Authorization Requests;
   - Transaction Tokens and sender-constrained authorization;
   - WIMSE and multi-hop workload context;
   - RATS and attestation of enforcement components;
   - COSE for protected authorization objects; and
   - emerging AgentProto work for cross-vendor agent-to-agent and
   agent-to-tool interaction.

I would particularly appreciate DISPATCH feedback on:

   1. whether the effectuation-boundary problem is sufficiently distinct to
   merit further work;
   2. whether existing IETF mechanisms already provide the required
   properties when properly composed;
   3. whether this should instead be expressed as a profile or cross-WG
   design exercise; and
   4. which venue, if any, would be most appropriate.

Best regards,
*Sangam Das*
Independent Researcher
Balasore, Odisha, India
<a href=3D"mailto:info@sangamdas.com" target=3D"_blank">info@sangamdas.com<=
/a></div></blockquote></div></div>
_______________________________________________<br>
dispatch mailing list -- <a href=3D"mailto:dispatch@ietf.org" target=3D"_bl=
ank">dispatch@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:dispatch-leave@ietf.org" =
target=3D"_blank">dispatch-leave@ietf.org</a><br>
</blockquote></div>

--0000000000000c6800065c2836ef--