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

[Blake Morrison <[e-mail]>]

Parisa, Steven, Chris, Iman,

Before the dimension gets drafted, one point from rev 00's own text
rather than from any of the framings on offer.

Section 11 records what was set aside and applies a consistent test: a
dimension has to be protocol-visible within a single exchange and
exercised distinctly. Delegation transitivity failed it because lineage
continuity has "a scope broader than a single exchange". Trust domain
span went the same way. Section 12's last bullet parks that whole class.

Evidence verifiability, as the three framings describe it, has not been
put to that test. Steven's top value is records that survive outside the
session. Iman's pin is a verification root the relying party can fix
independently of every participant. Chris's action row grades on whether
anything external pins the chain head. Each of those is settled after the
exchange, by someone who was not in it. Three routes converging shows the
property matters. It does not show it sits at exchange scope, and
adopting on convergence uses a different test from the one Section 11
applies to everything else.

The cut that keeps it inside the model: grade what the exchange emits,
not what a non-participant can later do. Whether an evidence artifact
crosses the wire, and what root it offers for verifying it, are both
readable per exchange. Whether verification later succeeds turns on log
liveness, key availability and retention, which are exactly the
arrangements Section 11 put outside.

Separately, rev 00 already carries EXT-AUDIT for structured audit records
of actions taken on behalf of requesting parties. That looks close enough
to EXT-ACCTEV that one should absorb the other.

Best,
Blake


On Saturday, 18 July 2026 at 6:03 AM, Mikhail Sergeev <[e-mail]> wrote:

> Parisa —
> 
> Thanks. Here are the four test cases, as requested. These are not proposed matrix rows. Taken together, they vary one factor at a time to test the non-inference rule.
> 
> 1. Participant-verifiable invocation record
> 
> Offered root: a key binding whose trust depends on an exchange participant.
> Evidence verifiability: participant-verifiable.
> Producing boundary: controlled invocation boundary.
> Supportable action claim: the invocation crossed that boundary — not the target's internal execution or external effect.
> 
> 2. Third-party-verifiable invocation record
> 
> Offered root: independently pinnable by a non-participant.
> Evidence verifiability: third-party-verifiable.
> Producing boundary and supportable action claim: the same as case 1. Verification reach increases; the action claim remains invocation.
> 
> 3. Participant-verifiable execution record
> 
> Offered root: a key binding whose trust depends on an exchange participant.
> Evidence verifiability: participant-verifiable.
> Producing boundary: an accepted operator-controlled executor.
> Supportable action claim: execution under that boundary, assuming the record binds the action and result — not independent grounding of the boundary or confirmation of an external effect.
> 
> 4. Third-party-verifiable execution record
> 
> Offered root: independently pinnable by a non-participant.
> Evidence verifiability: third-party-verifiable.
> Producing boundary and supportable action claim: the same as case 3. Verification reach increases; the execution claim does not become broader.
> 
> Read horizontally, the offered root changes verification reach while the supportable action claim stays fixed. Read vertically, the producing boundary changes the supportable action claim while verification reach can stay fixed. Neither property implies the other.
> 
> 
> Best,
> 
> Mikhail
> 
> On Fri, Jul 17, 2026 11:13 AM, "Parisa Foroughi (Nokia)" <[e-mail]> wrote:
> 
> > Dear Steven, Iman, Chris, Blake, Mikhail,
> > Thanks — this has converged into something cleaner than any single framing.
> > Where we've landed:
> > 
> > -   One dimension, three values — evidence verifiability: none / participant-verifiable / third-party-verifiable.
> > -   Graded on the verification root the exchange offers, readable per exchange — not on whether verification later succeeds.
> > 
> > @Blake, thank you for flagging this early. The model was always going to characterize (i.e., relate to the root and the implicit presence/absence ) rather than verify, but your cut named the two things cleanly: the root the exchange offers (what we grade, readable per exchange) versus whether verification later succeeds (log liveness, keys, retention — substrate, and Section 11 puts it outside). I'm glad Section 11 stands up here and does real work rather than sitting as a burden the readers find hard to follow. This also matches Iman's pin, which is about the offered root, not eventual verification.
> > @Mikhail, thank you too. The non-inference rule goes in. Verification reach and action-claim strength are orthogonal: a third-party-verifiable invocation record is still only invocation evidence. I'll add it as an explicit caveat so the axis isn't overread, and please do post your four test cases as plain text, I am curious to know about them and to see if I can use them as part of sanity check process.
> > @Chris, Thanks for your quick draft. Allow me some time to organize all this and get back to you all. Not to mention, with all the new drafts going around, it is somewhat of a challenge to analyze all content critically and methodically. I will certainly have a look once I get a moment.
> > @Steven, I am counting on your input. Thanks for the confirmation note.
> > On populating the table: Iman's instinct is the right direction for keeping it neutral rather than a set of self-descriptions. I will post the revised axis and a first cut of the matrix after Vienna, and we can work out how mappings get proposed and confirmed once we're all looking at the same thing.
> > 
> > Warm regards,
> > Parisa
> > 
> > 
> > 
> > 
> > From: Chris Hood <[e-mail]>
> > Sent: Friday, July 17, 2026 6:50 PM
> > To: team=[e-mail] <team=[e-mail]>
> > Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Parisa Foroughi (Nokia) <[e-mail]>
> > Subject: Re: [agent2agent] Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates
> > 
> > 
> > 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.
> > 
> > Here is Parisa's dimensional analysis for AGTP. Open to feedback or questions.
> > 
> > https://github.com/nomoticai/agtp/blob/main/docs/agtp-dimensions-mapping.md
> > 
> > 
> > Chris
> > 
> > 
> > On Thu, Jul 16, 2026 at 2:06 PM Iman Schrock <team=[e-mail]> wrote:
> > 
> > > Chris,
> > > 
> > > That would be useful.
> > > 
> > > Perhaps the cleanest input format is one row per extension, with each
> > > value accompanied by the exact section and the verification root the
> > > exchange offers. Author-supplied mappings can remain marked as
> > > proposed until the table editor or another reviewer confirms them.
> > > 
> > > I will provide the EP authorization-evidence mapping under the same
> > > rule once Parisa posts the revised axis. That gives the table
> > > source-linked inputs without turning it into competing
> > > self-descriptions.
> > > 
> > > Parisa, no need to hold the revision for either mapping. We can send
> > > deltas against the matrix you publish.
> > > 
> > > Best,
> > > Iman
> > > 
> > > On Thu, 16 Jul 2026 19:27:27 +0000 (UTC), Chris Hood <[e-mail]> wrote:
> > > > @Parisa -- have you updated the matrix beyond vs 00? Happy to map AGTP efforts to it prior to Vienna for everyone's reference.
> > > >
> > > > Chris
> > > >
> > > > On Thu, Jul 16, 2026 at 11:32 AM <[e-mail]> wrote:
> > > >
> > > > Hi Parisa,
> > > >
> > > > On your two questions I'm with Iman on both.
> > > >
> > > > Just one more input: grade the axis per extension, not per protocol. Why? A proposal can be third-party-verifiable on the authz side and have nothing on accountability. A single protocol-level grade would hide what the axis is supposed to surface. Chris grading his own stack three ways shows it works.
> > > >
> > > > Happy to help draft.
> > > >
> > > > Steven
> > > >
> > > > P.S.: Excited to be on the plane towards Vienna, (from San Francisco). Smooth travels to those attending in-person.
> > > 
> > > _______________________________________________
> > > agent2agent mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]