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

[Leonard Gebauer <[e-mail]>]

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

On Sat, Jul 4, 2026 at 4:49 PM Leonard Gebauer <[e-mail]>
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 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]
>>>
>>