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

[Iman Schrock <[e-mail]>]

Parisa,

Answers to your two questions, from the receipt side.

One axis, with the two extensions, is the right shape. Authorization
evidence and accountability evidence are different claims: one says a named
principal permitted this exact action before it ran, the other says the
action happened as witnessed. The morrison thread just locked the same cut
as grant and receipt objects joined by a digest reference. They share the
verifiability scale, so a single evidence-verifiability dimension with
EXT-AUTHEV and EXT-ACCTEV naming the two artifact classes captures both
without fusing artifacts that carry different proof obligations.

On the second question: third-party-verifiable is a dimension value, not a
substrate property. A self-contained signed object that carries its own key
material is verifiable by a non-participant, offline, with no transparency
log in the path. Our published conformance vectors work exactly that way:
each vector holds the document, the public key, and the expected verdict,
and anyone can hand one to an auditor who trusts neither party. What a
transparency log adds is anchoring: append time, non-equivocation, survival
beyond the parties. So I would define the value as "a non-participant can
verify without trusting either party" and leave the mechanism to the
substrate facet, where SCITT anchoring over RFC 9162 is one strong
realization. That keeps the anchored path and the offline path inside the
same value, and it keeps the dimension mechanism-neutral, which is what has
kept the rest of your model clean.

Happy to review the drafted dimension and mapping whenever it is ready.

Iman

On Mon, Jul 13, 2026 04:25 AM, "Parisa Foroughi (Nokia)" <
[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 Vienna in 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-participant can 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 drafts build 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'll draft 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]. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> *CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext <http://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 also cleanly 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-organization
> actions), 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
>