[agent2agent] Re: Security-principal separation for agent communication protocols

[Leonard Gebauer <[e-mail]>]

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 PM Iman Schrock <[e-mail]> 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 note:
> EP is not a communication protocol — it's the artifact layer several
> 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 an
> implied guarantee.
>
> 2. Executable rows. For every row we map, we'll link a public test vector
> 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 per
> row. Authorization evidence is the clearest case — the artifact is
> application-layer but rides whatever transport the session uses, which is
> why Songbo's binding and freshness columns do more review work than layer
> 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 <[e-mail]> 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 captures
>> 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 <[e-mail]> 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
>> <[e-mail]> wrote:
>> > Hi Songbo, all,
>> >
>> > Songbo, first of all, I’d like to thank you for your organizational
>> 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 thoughts
>> 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 the
>> row with ID 1 applies only to that row, not to all subsequent rows.
>> Theoretically, each row could have a different protocol, or multiple rows
>> 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 “solution" 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 connection |
>> Implemented | Specified | ...
>> > 2 | Identity-Locator Separation | LL-Entity / Peer | EID + dynamic
>> locator binding | EID-to-locator binding state | Locator update freshness |
>> 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 | Composition
>> | Session downgrade | Not Implemented | In work |
>> > 4 | Instance Authentication | LL-Entity | IAT (32-byte token) | Local
>> instance context | Token issuance timestamp | Isolation | Drop + quarantine
>> | 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 | Governance
>> | 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 <= 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 | Governance
>> | 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=RFC_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 AM Songbo Bu <[e-mail]> 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 is
>> >
>> > 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 heuristic
>> >
>> > 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 verifier
>> >
>> > 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> agent2agent mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>