[agent2agent] Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates

[Chris Hood <[e-mail]>]

Parisa, Steven, Iman,

Verifiability and accountability are different things. We need to be careful before combining them into a single axis.

Verifiability is a property of a record. Can someone check it against a signature or a chain.

Accountability is about ownership. Who is responsible for what the agent did, and it flows from identity and delegation rather than from evidence artifacts. A record can be third-party-verifiable and still leave accountability ambiguous if the identity and delegation model behind it is thin.

I recognize I started the entire thread about pre-action and post-action audits, which is intended to be a part of AGTP, but I also feel that the pre-action "audit" extends beyond authorization alone.

1. A pre-action event could be authorization, scope validation, contract negotiation, budget approval, and others.
2. A post-action record could be confirmation, execution, hand-off, generation, and more.

And these repeat rather than sit as one-time pre-action and post-action audits. An agent running ten tasks produces ten pre-action events and ten post-action records. The system ends up with an array of authorizations and negotiations next to execution confirmations or hand-offs, all while needing to maintain accountability and verifiability across each action.

This is why the application layer must act as the governance decision and enforcement, while the transport carries and preserves the evidence per action. These are different architectural designs, but should easily compose to allow for richer views of verifiability and accountability.

I'd simplify this into 1) exchange audits live at the transfer layer with accountability and verifiability, and 2) governance decisions live at the application layer leveraging accountability and verifiability from the substrate.

Chris

On Mon, Jul 13, 2026 at 4:25 AM Parisa Foroughi (Nokia) <parisa.foroughi=[e-mail]> wrote:

Dear Steven, Iman and Chris,

Steven, allow me to flag a point of convergence and write this email to the three of you together on purpose. Over the past emails each of you, from a different direction, pointed me at the same property and that convergence is worth surfacing before Viennain the mailing list.

You each identified an axis the draft lacks: whether an exchange produces an independently verifiable record, and who can verify it.

• Iman, from the receipt side: is there a verifiable authorization decision on the wire?
• Chris, from the substrate side: what can the receiving agent verify independently?
• Steven, from the accountability side: can a non-participant verify what the agent did?

Three routes converging into one property is the strongest signal that something belongs in the model, so I'm inclined to adopt it, and I'd rather design it with you than pick one framing.

What I propose: One axis/new dimension call it evidence verifiability, using Steven's grading: none (nothing independently verifiable crosses the wire) / participant-verifiable (the parties can verify each other's records) / third-party-verifiable (a non-participantcan verify without trusting either party).

I lean toward one new axis/dimension rather than two. It will thus require capturing two more extensions (i.e., a pre-action authorization receipt and a post-action accountability record, say respectively EXT-AUTHEV, EXT-ACCTEV) rather than two dimensions. Since they share the identical scale and same orthogonality to the existing seven dimensions. 

Two questions for you:

1. Is verifiability the right single axis, rather than authorization and accountability as separate dimensions?
2. Is third-party-verifiable a clean dimensional value, or a value realized by a substrate,  specifically SCITT/COSE transparency-log anchoring (RFC 9162), which all three of your draftsbuild on?

The evidence artifacts themselves  (i.e., a pre-action authorization receipt, a post-action accountability record) are extension-layer protocol work, so I will name them and leave their design to you rather than settle it in the model. If we converge, I'lldraft the dimension and mapping, cite your drafts as the worked data points, and share it with you for review for the next revision.

Looking forward to further discussion. 

Best regards,

Parisa

---

From: Steven Mih <[e-mail]>
Sent: Monday, July 13, 2026 5:55 AM
To: [e-mail] <[e-mail]>
Cc: Parisa Foroughi (Nokia) <[e-mail]>
Subject: Re: [agent2agent] New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates

You don't often get email from [e-mail]. https://aka.ms/LearnAboutSenderIdentification" id="OWAc08e0966-a1da-aa59-e4f3-dda6048b0c50" class="OWAAutoLink" target="_blank" rel="noreferrer nofollow noopener"> Learn why this is important

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Parisa,

Thanks for this — a neutral dimensional model is exactly what this cluster of proposals needs before Vienna, and characterizing rather than ranking is the right instinct.

One dimension I'd suggest adding: accountability, or evidence. Orthogonal to transport, discovery, and authorization: does the protocol produce a record of what an agent actually did, and who can verify it? It grades naturally:

- None — actions leave only operator logs.
- Participant-verifiable — the parties to an interaction can verify each other's records (signed receipts, mutual attestation).
- Third-party-verifiable — a non-participant (an auditor, a counterparty's counterparty, a regulator) can verify the record without trusting either operator, typically via anchoring to a transparency log.

The reason it earns a dimension of its own: it's the property that changes least across substrates. Two protocols can differ on every axis you've defined and still need the same answer to "prove what the agent did to someone who trusts neither of us." It alsocleanly separates proposals that look similar on other axes — many carry signed messages (participant-verifiable) while very few produce records that survive outside the session.

If useful as data points for populating that column: draft-mih-scitt-agent-action-capsule (third-party-verifiable action records over SCITT), draft-mih-agent-bilateral-attestation (the participant-verifiable→third-party-verifiable step for cross-organizationactions), and draft-mih-sato-agent-accountability-composition (how the accountability dimension decomposes into CAN/WHO/WHAT/AUDIT slots that different protocols can fill).

Happy to propose concrete text for the dimension if that's helpful.

Best,
Steven Mih
Action State Group

BTW I made a quick, free mobile app to share and organize schedules: https://vibes.diy/vibe/stevenmih88/ietf-picker" id="OWA4e1be7dd-c342-462d-5901-8f0411540052" class="OWAAutoLink" rel="noreferrer nofollow noopener" target="_blank"> https://vibes.diy/vibe/stevenmih88/ietf-picker