MIME-Version: 1.0
References: <1783177466906671820.1783177466@nomotic.ai>
 <CAOfgHgpa9dDpBxptd3gnK41TS=Wt8h1fZiyzbbW9eKTuqbi7Rg@mail.gmail.com>
 <CABTQ9f43k=Heo2JUtmip6=5KYXKbnkKSvVX20nGCVcMVmqeO6Q@mail.gmail.com>
In-Reply-To: 
 <CABTQ9f43k=Heo2JUtmip6=5KYXKbnkKSvVX20nGCVcMVmqeO6Q@mail.gmail.com>
From: Leonard Gebauer <leonard.gebauer.ha@gmail.com>
Date: Sat, 4 Jul 2026 16:50:13 +0100
Message-ID: 
 <CABTQ9f7QR+VzWYRydJpzvA27B9p5ordRsGUZXVpJ6+QAaNmMwA@mail.gmail.com>
To: Iman Schrock <team@emiliaprotocol.ai>, agent2agent@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e331ca0655caffdd"
Message-ID-Hash: DMOUDT5HO2TQSCQMFBQDBGAWR42TSB23
Precedence: list
Subject: =?utf-8?q?=5Bagent2agent=5D_Re=3A_Security-principal_separation_for_agent_co?=
 =?utf-8?q?mmunication_protocols?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/agent2agent/0566PDx1GnWyroxDR4VKW0ZcF0c>

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

Sorry for sending it double, my mail program is currently kinda broken :/

On Sat, Jul 4, 2026 at 4:49=E2=80=AFPM Leonard Gebauer <leonard.gebauer.ha@=
gmail.com>
wrote:

> Hi Iman, Chris, all,
>
> Yeah, I totally agree with you guys about the wording and the points you
> brought up. I'm glad you like my general idea.
>
> Best regards,
> Leonard Gebauer
>
> On Sat, Jul 4, 2026 at 4:19=E2=80=AFPM Iman Schrock <team@emiliaprotocol.=
ai>
> wrote:
>
>> Songbo, Leonard, Chris, all,
>>
>> The two-level model is right, and Songbo's naming matters: a claim
>> registry coordinates review without picking winners, and the per-draft
>> mapping tables keep "specified" honest against "planned" and "inherited.=
"
>>
>> Two commitments from our side:
>>
>> 1. Early mapping. Once the claim IDs stabilize, we'll submit a mapping
>> table for the EMILIA Protocol drafts against the authority,
>> action-evidence, and freshness/revocation rows (authorization receipts,
>> quorum, the action evidence graph, revocation statement). One framing no=
te:
>> EP is not a communication protocol =E2=80=94 it's the artifact layer sev=
eral
>> candidates already reference for those claims. So we'd map it as an
>> inheritance target: where AGTP, IACP, or others mark authority or
>> action-evidence rows "Inherited," the link can point at a concrete
>> mechanism with a named verifier, binding, and failure path, instead of a=
n
>> implied guarantee.
>>
>> 2. Executable rows. For every row we map, we'll link a public test vecto=
r
>> so the mapping is checkable rather than asserted. If the registry format
>> allows an optional vector/evidence column, any protocol that can fill it
>> gets the same auditability.
>>
>> On Chris's layer question: agree the layer field should be open-ended pe=
r
>> row. Authorization evidence is the clearest case =E2=80=94 the artifact =
is
>> application-layer but rides whatever transport the session uses, which i=
s
>> why Songbo's binding and freshness columns do more review work than laye=
r
>> placement ever will.
>>
>> agentproto-claim-matrix as the repo name works; the claim model is the
>> object, the tables are just its serialization.
>>
>> Best,
>>
>> On Sat, Jul 04, 2026 08:04 AM, Chris Hood <chris@nomotic.ai> wrote:
>>
>>> Leonard, all,
>>>
>>> I'm in agreement with Songbo on the two-level model. Claim registry as
>>> the shared review surface, protocol mapping tables as the per-draft
>>> implementation record.
>>>
>>> In addition:
>>>
>>> The layer field however needs to be clarified. The current list will
>>> produce inaccuracies and doesn't cover all proposals. For example, AGTP
>>> sits at the transport layer for all of these options.
>>>
>>> It currently reads as if the matrix has specific layer requirements per
>>> area of evaluation.
>>>
>>> Two paths still apply: OSI-standard layer language (Application,
>>> Transport, Network) which is unambiguous but flat, or an agent-native
>>> taxonomy (substrate, composition, application, governance) which captur=
es
>>> architectural distinctions but requires shared definitions.
>>>
>>> For example, there really is no "governance layer" but that could be
>>> adopted if we can explain it.
>>>
>>> Despite the definition, each auditable row should be open ended to what
>>> layer that feature sits at per evaluation.
>>>
>>> Timeline: I will map AGTP to the initial claim registry once the IDs
>>> stabilize and the layer field vocabulary is decided.
>>>
>>> Chris
>>>
>>>
>>>
>>> On Sat, Jul 4, 2026 at 7:54 AM Songbo Bu <bluedognull@gmail.com> wrote:
>>>
>>> Hi Leonard, all,
>>>
>>> Yes, this direction makes sense. I have folded the idea into the
>>> pre-draft as a two-level model.
>>>
>>> I would use slightly different names, because "protocol taken as
>>> standard" could be read as selecting a winner. The first table should
>>> be a claim registry: stable IDs for the claims or requirements the WG
>>> wants to compare. A row can name one or more candidate protocol
>>> mappings, but only for that row.
>>>
>>> The second table should be the protocol mapping table. Each draft maps
>>> the claim IDs it carries or depends on to concrete verifier-facing
>>> fields: carrier, verifier, binding, freshness, layer, failure
>>> behavior, implementation status, specification status, and external
>>> dependency or inheritance.
>>>
>>> That keeps the separation we need:
>>>
>>> - the claim registry coordinates the review surface;
>>> - the protocol mapping table states what a draft actually specifies or
>>> implements;
>>> - inherited, planned, or externally dependent mechanisms stay visible
>>> instead of becoming implied protocol guarantees.
>>>
>>> For the repository, I agree that a small GitHub repo would be useful.
>>> I would probably name it agentproto-verifier-matrix or
>>> agentproto-claim-matrix rather than agentproto-tables, because the
>>> important object is the verifier-facing claim model, not only the
>>> table format.
>>>
>>> As a first step, I suggest drafting the initial claim registry from
>>> the claims already raised in the thread: authority, live agent
>>> instance, tool or resource identity, delegation, session continuity,
>>> action evidence, freshness or revocation, and failure behavior. Once
>>> the IDs are stable enough, AGTP, IACP, and other candidate drafts can
>>> add their own protocol mapping tables without forcing a common wire
>>> format.
>>>
>>> Best,
>>> Songbo
>>>
>>>
>>> On Sat, 4 Jul 2026 13:54:32 +0100, Leonard Gebauer
>>> <leonard.gebauer.ha@gmail.com> wrote:
>>> > Hi Songbo, all,
>>> >
>>> > Songbo, first of all, I=E2=80=99d like to thank you for your organiza=
tional
>>> efforts. Over the past few days, a large number of I-Ds and ideas have =
come
>>> up, and I think your organizational initiative is exactly what we need =
to
>>> coordinate our work better and utilise the vast amount of ideas that we
>>> have already gathered.
>>> >
>>> > I've read your email and appreciate your initiative to get this on
>>> track through a work I-D, and I'd like to make the following suggestion=
,
>>> based mainly on your feedback and ideas in combination with my own thou=
ghts
>>> and ideas:
>>> >
>>> > MAIN TABLE (MT) - GENERAL COORDINATION/OVERVIEW
>>> >
>>> > ID | CLAIM / REQUIREMENT | PROTOCOL/-S TAKEN AS STANDARD |
>>> >
>>> ---|----------------------------------------|--------------------------=
-----|
>>> > 1 | Agent Identity | (Draft Name) |
>>> > 2 | Identity-Locator Separation | ... |
>>> > 3 | ... | ... |
>>> >
>>> > Note:
>>> > - ID: Every Claim/Requirement gets a own ID.
>>> > - PROTOCOL TAKEN AS STANDARD: The protocol listed, for example, in th=
e
>>> row with ID 1 applies only to that row, not to all subsequent rows.
>>> Theoretically, each row could have a different protocol, or multiple ro=
ws
>>> could have the same one.
>>> > - The purpose of this table is to define the claims and their
>>> corresponding IDs, and then to note which protocol/-s is used as the
>>> architectural =E2=80=9Csolution" for the claim.
>>> >
>>> > INDIVIDUAL TABLE (IT) - ONE TABLE FOR EACH PROTOCOL
>>> >
>>> > (Here presented with IACP as example - The table was generated by an
>>> LLM based on the defined column structure (my Input) i gave it - Edited=
 by
>>> Author)
>>> >
>>> > ID | CLAIM / REQUIREMENT | VERIFIER | MECHANISM | BOUND | FRESHNESS |
>>> LAYER | FAILURE MODE | IMPLEMENTATION STATUS | TECHNICAL STATUS |
>>> CONNECTION TO OTHER WORKS
>>> >
>>> ---|----------------------------------------|-------------------|------=
------------------------------|--------------------------------------|-----=
---------------------------|-------------|-------------------------------|-=
---------------------------|------------------|---------------------------
>>> > 1 | Agent Identity | Peer Node | Ed25519 signature | Handshake
>>> transcript | Nonce / signature timestamp | Substrate | Reject connectio=
n |
>>> Implemented | Specified | ...
>>> > 2 | Identity-Locator Separation | LL-Entity / Peer | EID + dynamic
>>> locator binding | EID-to-locator binding state | Locator update freshne=
ss |
>>> Composition | Locator mismatch -> drop | Implemented | Specified |
>>> > 3 | Post-Rotation Accountability | LL-Entity / Peer | Dual-Key (K_anc=
)
>>> + AA | Previous EID + K_anc chain | Rotation event timestamp | Composit=
ion
>>> | Session downgrade | Not Implemented | In work |
>>> > 4 | Instance Authentication | LL-Entity | IAT (32-byte token) | Local
>>> instance context | Token issuance timestamp | Isolation | Drop + quaran=
tine
>>> | Implemented | Specified |
>>> > 5 | Session Establishment | Peer Node | Dual-Cookie Handshake |
>>> Cookie1/2 transcript | Nonce epoch | Transport | Reject PSS_INIT |
>>> Implemented | Specified |
>>> > 6 | Session Federation / Delegation | Peer Node | Signed SFC contract
>>> | Resource + scope + peer identity | Contract validity timestamp |
>>> Application | Deny ESE access | Implemented | Specified |
>>> > 7 | Action Evidence / Non-Repudiation | Peer / Curator | PoM + signed
>>> tickets | Conflicting signatures (A/B) | PoM challenge window | Governa=
nce
>>> | Slashing trigger | Implemented | Specified |
>>> > 8 | Forwarding / Mobility | Peer Node | Migration Vector + Ticket |
>>> Previous session state + EID | Generation counter | Routing | Session
>>> downgrade | Implemented | Specified |
>>> > 9 | Namespace / DHT Governance | DHT Curator | Signed chain + PoM |
>>> Delegation chain | Ticket TTL / timestamp | Governance | Namespace
>>> revocation | Implemented | Specified |
>>> > 10 | Resource Authorization | Edge Gatekeeper | WRT (signed compute
>>> token) | Resource + compute-equivalence | Token issuance timestamp |
>>> Application | Deny execution | Implemented | Specified |
>>> > 11 | Content Interpretation (Deterministic) | DHI | ANML + EVM <=3D
>>> 0.001 | ANML equivalence proof | EVM computation epoch | Application |
>>> Legacy fallback | Implemented | Specified |
>>> > 12 | Reputation / Access Control | Peer Node | EMA query + PoW
>>> escalation | Reputation ledger entry | Epoch-based EMA update | Governa=
nce
>>> | Throttle / block | Implemented | Specified |
>>> > 13 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ...
>>> > \___________________________________________/
>>> > |
>>> > v
>>> > Is the same in every IT
>>> > Notes:
>>> > - IMPLEMENTATION STATUS: Either "Implemented " or "Not Implemented "
>>> > - TECHNICAL STATUS: Either "Specified", "In work" or "In planning".
>>> > - CONNECTION TO OTHER WORKS: "Inherited", "Partly Inherited" or "Not
>>> Inherited". If "Partly Inherited" or "Not Inherited", then: Hyperlinks =
like
>>> "[RFC9000](ca://s?q=3DRFC_9000)".
>>> >
>>> > For administration and storage of these tables, I think a GitHub-Repo
>>> ("agentproto-matrices" or "agentproto-tables") would be good.
>>> >
>>> > If this general direction makes sense, I would suggest as our first
>>> step to set up our MT and work out all the Claims, and then begin with =
the
>>> ITs.
>>> >
>>> > Best regards,
>>> > Leonard Gebauer
>>> >
>>> > On Sat, Jul 4, 2026 at 2:43=E2=80=AFAM Songbo Bu <bluedognull@gmail.c=
om>
>>> wrote:
>>> >
>>> > Hi Leonard, Chris, all,
>>> >
>>> > Thank you. This is a useful contribution, and it confirms the main
>>> >
>>> > point of the thread: AGENTPROTO needs a shared verifier-facing
>>> >
>>> > security matrix, not only protocol-specific architectural
>>> >
>>> > descriptions.
>>> >
>>> > I reviewed draft-gebauer-iacp-00 and your matrix. Before the matrix i=
s
>>> >
>>> > used as a comparison basis, I would make two concrete changes.
>>> >
>>> > First, add a status column for each row:
>>> >
>>> > - specified in the current I-D;
>>> >
>>> > - planned but not yet specified;
>>> >
>>> > - inherited from another component or external system; or
>>> >
>>> > - architectural assumption rather than a protocol check.
>>> >
>>> > This matters because several IACP rows are already close to direct
>>> >
>>> > protocol-review rows: EID signature validation, dual-cookie nonce
>>> >
>>> > validation, session-key derivation, forwarding-ticket authentication,
>>> >
>>> > migration-vector checks, and namespace-delegation validation. Other
>>> >
>>> > rows, such as reputation thresholds, DHT curator behavior,
>>> >
>>> > PoM/slashing, curator committees, WRT, ANML equivalence, and heuristi=
c
>>> >
>>> > extraction, may be valid design goals, but they should not be
>>> >
>>> > presented as current protocol guarantees unless the current I-D
>>> >
>>> > specifies the verifier, evidence, and failure path.
>>> >
>>> > Second, add binding and freshness fields. For each claim, the verifie=
r
>>> >
>>> > needs to know not only which mechanism is used, but what exact
>>> >
>>> > decision state the mechanism is bound to. Examples:
>>> >
>>> > - EID signature: bound to which handshake message or transcript?
>>> >
>>> > - session key: bound to which peer identities and nonce material?
>>> >
>>> > - SFC access: bound to which resource, operation, and delegated scope=
?
>>> >
>>> > - migration vector: bound to which prior session state and generation
>>> counter?
>>> >
>>> > - action evidence: bound to which observed action input or digest?
>>> >
>>> > Without that binding, a mechanism can be cryptographically valid but
>>> >
>>> > still fail to support the verifier decision being made.
>>> >
>>> > I am turning the checklist from this thread into a short individual
>>> >
>>> > I-D under the working title "Security Principal and Verifier Binding
>>> >
>>> > for Agent Communication Protocols". The document will be
>>> >
>>> > protocol-neutral. Its concrete purpose is to define a matrix that
>>> >
>>> > candidate drafts can map to: claim, carrier, verifier, binding,
>>> >
>>> > freshness, layer, failure behavior, and implementation status.
>>> >
>>> > The request to candidate protocol authors is also concrete: map your
>>> >
>>> > draft to the matrix, or state explicitly where your draft
>>> >
>>> > intentionally differs. That gives the WG a reviewable basis for
>>> >
>>> > comparing AGTP, IACP, and other proposals without forcing a common
>>> >
>>> > wire format too early.
>>> >
>>> > Best,
>>> >
>>> > Songbo
>>>
>>> _______________________________________________
>>> agent2agent mailing list -- agent2agent@ietf.org
>>> To unsubscribe send an email to agent2agent-leave@ietf.org
>>>
>>> _______________________________________________
>>> agent2agent mailing list -- agent2agent@ietf.org
>>> To unsubscribe send an email to agent2agent-leave@ietf.org
>>>
>>

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

<div dir=3D"ltr">Sorry=C2=A0for sending it double, my mail program is curre=
ntly kinda broken :/</div><br><div class=3D"gmail_quote gmail_quote_contain=
er"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 4, 2026 at 4:49=E2=80=
=AFPM Leonard Gebauer &lt;<a href=3D"mailto:leonard.gebauer.ha@gmail.com">l=
eonard.gebauer.ha@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr">Hi Iman, Chris, all,<br><span s=
tyle=3D"background-color:transparent"><br>Yeah, I totally agree with you gu=
ys about the wording and the points you brought up. I&#39;m glad you like m=
y general idea.<br><br>Best regards,<br>Leonard Gebauer</span></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 4=
, 2026 at 4:19=E2=80=AFPM Iman Schrock &lt;<a href=3D"mailto:team@emiliapro=
tocol.ai" target=3D"_blank">team@emiliaprotocol.ai</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"auto">Songbo, Leonard, Chris, all,<br><br>The two-leve=
l model is right, and Songbo&#39;s naming matters: a claim registry coordin=
ates review without picking winners, and the per-draft mapping tables keep =
&quot;specified&quot; honest against &quot;planned&quot; and &quot;inherite=
d.&quot;<br><br>Two commitments from our side:<br><br>1. Early mapping. Onc=
e the claim IDs stabilize, we&#39;ll submit a mapping table for the EMILIA =
Protocol drafts against the authority, action-evidence, and freshness/revoc=
ation rows (authorization receipts, quorum, the action evidence graph, revo=
cation statement). One framing note: EP is not a communication protocol =E2=
=80=94 it&#39;s the artifact layer several candidates already reference for=
 those claims. So we&#39;d map it as an inheritance target: where AGTP, IAC=
P, or others mark authority or action-evidence rows &quot;Inherited,&quot; =
the link can point at a concrete mechanism with a named verifier, binding, =
and failure path, instead of an implied guarantee.<br><br>2. Executable row=
s. For every row we map, we&#39;ll link a public test vector so the mapping=
 is checkable rather than asserted. If the registry format allows an option=
al vector/evidence column, any protocol that can fill it gets the same audi=
tability.<br><br>On Chris&#39;s layer question: agree the layer field shoul=
d be open-ended per row. Authorization evidence is the clearest case =E2=80=
=94 the artifact is application-layer but rides whatever transport the sess=
ion uses, which is why Songbo&#39;s binding and freshness columns do more r=
eview work than layer placement ever will.<br><br>agentproto-claim-matrix a=
s the repo name works; the claim model is the object, the tables are just i=
ts serialization.<br><br>Best,<br></div></div><br><div class=3D"gmail_extra=
"><div>On Sat, Jul 04, 2026 08:04 AM, Chris Hood &lt;<a href=3D"mailto:chri=
s@nomotic.ai" target=3D"_blank">chris@nomotic.ai</a>&gt; wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><p>Leonard, all,</p><p>I&#39;m in=
 agreement with Songbo on the two-level model. Claim registry as the shared=
 review surface, protocol mapping tables as the per-draft implementation re=
cord.</p><p>In addition:</p><p>The layer field however needs to be clarifie=
d. The current list will produce inaccuracies and doesn&#39;t cover all pro=
posals. For example, AGTP sits at the transport layer for all of these opti=
ons.</p><p>It currently reads as if the matrix has specific layer requireme=
nts per area of evaluation.</p><p>Two paths still apply: OSI-standard layer=
 language (Application, Transport, Network) which is unambiguous but flat, =
or an agent-native taxonomy (substrate, composition, application, governanc=
e) which captures architectural distinctions but requires shared definition=
s.</p><p>For example, there really is no &quot;governance layer&quot; but t=
hat could be adopted if we can explain it.</p><p>Despite the definition, ea=
ch auditable row should be open ended to what layer that feature sits at pe=
r evaluation.</p><p>Timeline: I will map AGTP to the initial claim registry=
 once the IDs stabilize and the layer field vocabulary is decided.</p><p>Ch=
ris</p><div><br></div><br><br>
      <div>
        <div>On Sat, Jul 4, 2026 at 7:54 AM Songbo Bu &lt;<a href=3D"mailto=
:bluedognull@gmail.com" target=3D"_blank">bluedognull@gmail.com</a>&gt; wro=
te:</div>
       =20
        <blockquote>Hi Leonard, all,<br><br>Yes, this direction makes sense=
. I have folded the idea into the<br>pre-draft as a two-level model.<br><br=
>I would use slightly different names, because &quot;protocol taken as<br>s=
tandard&quot; could be read as selecting a winner. The first table should<b=
r>be a claim registry: stable IDs for the claims or requirements the WG<br>=
wants to compare. A row can name one or more candidate protocol<br>mappings=
, but only for that row.<br><br>The second table should be the protocol map=
ping table. Each draft maps<br>the claim IDs it carries or depends on to co=
ncrete verifier-facing<br>fields: carrier, verifier, binding, freshness, la=
yer, failure<br>behavior, implementation status, specification status, and =
external<br>dependency or inheritance.<br><br>That keeps the separation we =
need:<br><br>- the claim registry coordinates the review surface;<br>- the =
protocol mapping table states what a draft actually specifies or<br>impleme=
nts;<br>- inherited, planned, or externally dependent mechanisms stay visib=
le<br>instead of becoming implied protocol guarantees.<br><br>For the repos=
itory, I agree that a small GitHub repo would be useful.<br>I would probabl=
y name it agentproto-verifier-matrix or<br>agentproto-claim-matrix rather t=
han agentproto-tables, because the<br>important object is the verifier-faci=
ng claim model, not only the<br>table format.<br><br>As a first step, I sug=
gest drafting the initial claim registry from<br>the claims already raised =
in the thread: authority, live agent<br>instance, tool or resource identity=
, delegation, session continuity,<br>action evidence, freshness or revocati=
on, and failure behavior. Once<br>the IDs are stable enough, AGTP, IACP, an=
d other candidate drafts can<br>add their own protocol mapping tables witho=
ut forcing a common wire<br>format.<br><br>Best,<br>Songbo<br><br><br>On Sa=
t, 4 Jul 2026 13:54:32 +0100, Leonard Gebauer<br>&lt;<a href=3D"mailto:leon=
ard.gebauer.ha@gmail.com" target=3D"_blank">leonard.gebauer.ha@gmail.com</a=
>&gt; wrote:<br>&gt; Hi Songbo, all,<br>&gt;<br>&gt; Songbo, first of all, =
I=E2=80=99d like to thank you for your organizational efforts. Over the pas=
t few days, a large number of I-Ds and ideas have come up, and I think your=
 organizational initiative is exactly what we need to coordinate our work b=
etter and utilise the vast amount of ideas that we have already gathered.<b=
r>&gt;<br>&gt; I&#39;ve read your email and appreciate your initiative to g=
et this on track through a work I-D, and I&#39;d like to make the following=
 suggestion, based mainly on your feedback and ideas in combination with my=
 own thoughts and ideas:<br>&gt;<br>&gt; MAIN TABLE (MT) - GENERAL COORDINA=
TION/OVERVIEW<br>&gt;<br>&gt; ID | CLAIM / REQUIREMENT | PROTOCOL/-S TAKEN =
AS STANDARD |<br>&gt; ---|----------------------------------------|--------=
-----------------------|<br>&gt; 1 | Agent Identity | (Draft Name) |<br>&gt=
; 2 | Identity-Locator Separation | ... |<br>&gt; 3 | ... | ... |<br>&gt;<b=
r>&gt; Note:<br>&gt; - ID: Every Claim/Requirement gets a own ID.<br>&gt; -=
 PROTOCOL TAKEN AS STANDARD: The protocol listed, for example, in the row w=
ith ID 1 applies only to that row, not to all subsequent rows. Theoreticall=
y, each row could have a different protocol, or multiple rows could have th=
e same one.<br>&gt; - The purpose of this table is to define the claims and=
 their corresponding IDs, and then to note which protocol/-s is used as the=
 architectural =E2=80=9Csolution&quot; for the claim.<br>&gt;<br>&gt; INDIV=
IDUAL TABLE (IT) - ONE TABLE FOR EACH PROTOCOL<br>&gt;<br>&gt; (Here presen=
ted with IACP as example - The table was generated by an LLM based on the d=
efined column structure (my Input) i gave it - Edited by Author)<br>&gt;<br=
>&gt; ID | CLAIM / REQUIREMENT | VERIFIER | MECHANISM | BOUND | FRESHNESS |=
 LAYER | FAILURE MODE | IMPLEMENTATION STATUS | TECHNICAL STATUS | CONNECTI=
ON TO OTHER WORKS<br>&gt; ---|----------------------------------------|----=
---------------|------------------------------------|----------------------=
----------------|--------------------------------|-------------|-----------=
--------------------|----------------------------|------------------|------=
---------------------<br>&gt; 1 | Agent Identity | Peer Node | Ed25519 sign=
ature | Handshake transcript | Nonce / signature timestamp | Substrate | Re=
ject connection | Implemented | Specified | ...<br>&gt; 2 | Identity-Locato=
r Separation | LL-Entity / Peer | EID + dynamic locator binding | EID-to-lo=
cator binding state | Locator update freshness | Composition | Locator mism=
atch -&gt; drop | Implemented | Specified |<br>&gt; 3 | Post-Rotation Accou=
ntability | LL-Entity / Peer | Dual-Key (K_anc) + AA | Previous EID + K_anc=
 chain | Rotation event timestamp | Composition | Session downgrade | Not I=
mplemented | In work |<br>&gt; 4 | Instance Authentication | LL-Entity | IA=
T (32-byte token) | Local instance context | Token issuance timestamp | Iso=
lation | Drop + quarantine | Implemented | Specified |<br>&gt; 5 | Session =
Establishment | Peer Node | Dual-Cookie Handshake | Cookie1/2 transcript | =
Nonce epoch | Transport | Reject PSS_INIT | Implemented | Specified |<br>&g=
t; 6 | Session Federation / Delegation | Peer Node | Signed SFC contract | =
Resource + scope + peer identity | Contract validity timestamp | Applicatio=
n | Deny ESE access | Implemented | Specified |<br>&gt; 7 | Action Evidence=
 / Non-Repudiation | Peer / Curator | PoM + signed tickets | Conflicting si=
gnatures (A/B) | PoM challenge window | Governance | Slashing trigger | Imp=
lemented | Specified |<br>&gt; 8 | Forwarding / Mobility | Peer Node | Migr=
ation Vector + Ticket | Previous session state + EID | Generation counter |=
 Routing | Session downgrade | Implemented | Specified |<br>&gt; 9 | Namesp=
ace / DHT Governance | DHT Curator | Signed chain + PoM | Delegation chain =
| Ticket TTL / timestamp | Governance | Namespace revocation | Implemented =
| Specified |<br>&gt; 10 | Resource Authorization | Edge Gatekeeper | WRT (=
signed compute token) | Resource + compute-equivalence | Token issuance tim=
estamp | Application | Deny execution | Implemented | Specified |<br>&gt; 1=
1 | Content Interpretation (Deterministic) | DHI | ANML + EVM &lt;=3D 0.001=
 | ANML equivalence proof | EVM computation epoch | Application | Legacy fa=
llback | Implemented | Specified |<br>&gt; 12 | Reputation / Access Control=
 | Peer Node | EMA query + PoW escalation | Reputation ledger entry | Epoch=
-based EMA update | Governance | Throttle / block | Implemented | Specified=
 |<br>&gt; 13 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ...<b=
r>&gt; \___________________________________________/<br>&gt; |<br>&gt; v<br=
>&gt; Is the same in every IT<br>&gt; Notes:<br>&gt; - IMPLEMENTATION STATU=
S: Either &quot;Implemented &quot; or &quot;Not Implemented &quot;<br>&gt; =
- TECHNICAL STATUS: Either &quot;Specified&quot;, &quot;In work&quot; or &q=
uot;In planning&quot;.<br>&gt; - CONNECTION TO OTHER WORKS: &quot;Inherited=
&quot;, &quot;Partly Inherited&quot; or &quot;Not Inherited&quot;. If &quot=
;Partly Inherited&quot; or &quot;Not Inherited&quot;, then: Hyperlinks like=
 &quot;[RFC9000](ca://s?q=3DRFC_9000)&quot;.<br>&gt;<br>&gt; For administra=
tion and storage of these tables, I think a GitHub-Repo (&quot;agentproto-m=
atrices&quot; or &quot;agentproto-tables&quot;) would be good.<br>&gt;<br>&=
gt; If this general direction makes sense, I would suggest as our first ste=
p to set up our MT and work out all the Claims, and then begin with the ITs=
.<br>&gt;<br>&gt; Best regards,<br>&gt; Leonard Gebauer<br>&gt;<br>&gt; On =
Sat, Jul 4, 2026 at 2:43=E2=80=AFAM Songbo Bu &lt;<a href=3D"mailto:bluedog=
null@gmail.com" target=3D"_blank">bluedognull@gmail.com</a>&gt; wrote:<br>&=
gt;<br>&gt; Hi Leonard, Chris, all,<br>&gt;<br>&gt; Thank you. This is a us=
eful contribution, and it confirms the main<br>&gt;<br>&gt; point of the th=
read: AGENTPROTO needs a shared verifier-facing<br>&gt;<br>&gt; security ma=
trix, not only protocol-specific architectural<br>&gt;<br>&gt; descriptions=
.<br>&gt;<br>&gt; I reviewed draft-gebauer-iacp-00 and your matrix. Before =
the matrix is<br>&gt;<br>&gt; used as a comparison basis, I would make two =
concrete changes.<br>&gt;<br>&gt; First, add a status column for each row:<=
br>&gt;<br>&gt; - specified in the current I-D;<br>&gt;<br>&gt; - planned b=
ut not yet specified;<br>&gt;<br>&gt; - inherited from another component or=
 external system; or<br>&gt;<br>&gt; - architectural assumption rather than=
 a protocol check.<br>&gt;<br>&gt; This matters because several IACP rows a=
re already close to direct<br>&gt;<br>&gt; protocol-review rows: EID signat=
ure validation, dual-cookie nonce<br>&gt;<br>&gt; validation, session-key d=
erivation, forwarding-ticket authentication,<br>&gt;<br>&gt; migration-vect=
or checks, and namespace-delegation validation. Other<br>&gt;<br>&gt; rows,=
 such as reputation thresholds, DHT curator behavior,<br>&gt;<br>&gt; PoM/s=
lashing, curator committees, WRT, ANML equivalence, and heuristic<br>&gt;<b=
r>&gt; extraction, may be valid design goals, but they should not be<br>&gt=
;<br>&gt; presented as current protocol guarantees unless the current I-D<b=
r>&gt;<br>&gt; specifies the verifier, evidence, and failure path.<br>&gt;<=
br>&gt; Second, add binding and freshness fields. For each claim, the verif=
ier<br>&gt;<br>&gt; needs to know not only which mechanism is used, but wha=
t exact<br>&gt;<br>&gt; decision state the mechanism is bound to. Examples:=
<br>&gt;<br>&gt; - EID signature: bound to which handshake message or trans=
cript?<br>&gt;<br>&gt; - session key: bound to which peer identities and no=
nce material?<br>&gt;<br>&gt; - SFC access: bound to which resource, operat=
ion, and delegated scope?<br>&gt;<br>&gt; - migration vector: bound to whic=
h prior session state and generation counter?<br>&gt;<br>&gt; - action evid=
ence: bound to which observed action input or digest?<br>&gt;<br>&gt; Witho=
ut that binding, a mechanism can be cryptographically valid but<br>&gt;<br>=
&gt; still fail to support the verifier decision being made.<br>&gt;<br>&gt=
; I am turning the checklist from this thread into a short individual<br>&g=
t;<br>&gt; I-D under the working title &quot;Security Principal and Verifie=
r Binding<br>&gt;<br>&gt; for Agent Communication Protocols&quot;. The docu=
ment will be<br>&gt;<br>&gt; protocol-neutral. Its concrete purpose is to d=
efine a matrix that<br>&gt;<br>&gt; candidate drafts can map to: claim, car=
rier, verifier, binding,<br>&gt;<br>&gt; freshness, layer, failure behavior=
, and implementation status.<br>&gt;<br>&gt; The request to candidate proto=
col authors is also concrete: map your<br>&gt;<br>&gt; draft to the matrix,=
 or state explicitly where your draft<br>&gt;<br>&gt; intentionally differs=
. That gives the WG a reviewable basis for<br>&gt;<br>&gt; comparing AGTP, =
IACP, and other proposals without forcing a common<br>&gt;<br>&gt; wire for=
mat too early.<br>&gt;<br>&gt; Best,<br>&gt;<br>&gt; Songbo<br><br>________=
_______________________________________<br>agent2agent mailing list -- <a h=
ref=3D"mailto:agent2agent@ietf.org" target=3D"_blank">agent2agent@ietf.org<=
/a><br>To unsubscribe send an email to <a href=3D"mailto:agent2agent-leave@=
ietf.org" target=3D"_blank">agent2agent-leave@ietf.org</a><br></blockquote>
      </div>

_______________________________________________<br>
agent2agent mailing list -- <a href=3D"mailto:agent2agent@ietf.org" target=
=3D"_blank">agent2agent@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:agent2agent-leave@ietf.or=
g" target=3D"_blank">agent2agent-leave@ietf.org</a><br>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div>

--000000000000e331ca0655caffdd--