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

[Mikhail Sergeev <[e-mail]>]

Hi, Parisa —

Yes. That distinction is what I intended.

I was not proposing to combine authorization evidence with
post-action/accountability evidence. The consolidation I meant was only
EXT-ACCTEV -> EXT-AUDIT for the post-action side.

EXT-AUTHEV should remain a separate extension point. Authorization evidence
and audit/accountability evidence can arise at different enforcement points
and can be supplied by different protocols.

Evidence Verifiability still applies per record. And the non-inference rule
should remain explicit: an EXT-AUDIT record does not establish the
existence or value of an EXT-AUTHEV record, and vice versa.

So I think we agree on the boundary; my earlier wording was too compressed.

Best,
Mikhail


On Fri, 2 Oct 2026 11:44:07 +0000, "Parisa Foroughi (Nokia)" <
[e-mail]> wrote:
> Dear Iman, Blake, Mikhail, Chris and Sumit,
>
> Apologies for the delayed response. I have also been reconsidering the
scope of this I-D as the discussion increasingly moves toward multi-party
protocols, but coming back to this thread:
>
> I think we need to keep the protocol-visible observation separate from
the property the dimension characterizes.
>
> For evidence-verifiability, I would retain the agreed values: `none /
participant-verifiable / third-party-verifiable`. The presence or absence
of a record is not another value on that axis; it is a protocol/data-model
primitive used to establish the resulting
> verifiability property. A record may exist and still yield `none` if it
does not provide the required verification property.
>
> I agree with Iman's treatment of "not found in this evidence set" as one
possible interpretation of the expected result for the EXT-AUTHEV test.
From the dimensional-model side, though, whether that record exists or not
seems to me
> part of the protocol mechanism supporting the extension, rather than
something that needs to surface in this draft. Unless there is another
reason for the dimensional model to expose record presence or absence
explicitly, I would leave that detail to
> the extension addressing this dimension.
>
> @Mikhail, on the proposal to drop EXT-ACCTEV and let EXT-AUDIT carry both
kinds of records, I think I disagree with collapsing the two extension
points. My reason is not the record-level Evidence Verifiability
classification; I agree that this can be
> applied independently to each record. My main point and concern is that
authorization evidence and post-action/accountability evidence arise at
potentially different enforcement points and may therefore be provided by
different protocols. Treating both as
> one extension would hide that distinction in a model whose purpose is
partly to make such protocol boundaries explicit. If the proposal is
instead simply to rename the post-action extension to EXT-AUDIT, I am fine
with that; it would also align better with
> the scope of the upcoming AUDIT BoF. Do you agree with that distinction,
or am I missing something in what you intended by consolidating them?
>
> @Sumit, good catch on D4 as well. I agree with Iman's proposed
clarification there: D4 describes what is presented at a given crossing; a
`derived-` value at that crossing does not establish uninterrupted
delegation continuity back to the originator.
> I will correct §5.4 accordingly in the next revision.
>
> Cheers,
>
> Parisa
>
> From: Iman Schrock <[e-mail]>
>
> Sent: Friday, October 2, 2026 6:53 AM
>
> To: Sumit Ahuja <[e-mail]>
>
> Cc: Parisa Foroughi (Nokia) <[e-mail]>; Blake Morrison <
[e-mail]>; [e-mail] <[e-mail]>;
[e-mail] <[e-mail]>
>
> Subject: Re: Re: [agent2agent] 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.
>
> Sumit, good catch. Your hop-2/hop-3 example exposes a tension in the
current §5.4: the definition says each step is narrowed back to the
originator, but the paragraph below says a value at one
> crossing does not establish lineage continuity.
>
> Parisa, I’d narrow the definition to what is presented at this crossing,
then add: “A derived-* value at one crossing does not establish that the
originator’s authority survived every earlier crossing.
> That conclusion requires evidence for the intervening chain.”
>
> That keeps D4 a local description without asking it to prove the entire
path. Thanks for flagging it, Sumit.
>
> Iman
>
> On Thu, 01 Oct 2026 18:49:39 -0400, Sumit Ahuja <[e-mail]> wrote:
>
> Parisa, Iman, Blake, One observation on D4; Section 5.4 says a mediator
can either preserve the originator's chain or terminate it and present its
own credentials, and that the two have materially different
> audit and blast-radius implications. The model records the value per
crossing. The consequence I would make explicit is what a downstream
receiver can infer from it. If a mediator terminates the chain at hop 2 and
the next agent derives from the mediator,
> hop 3 is derived-chain. To the receiver at hop 3 it looks the same as a
chain that runs unbroken back to the originator. The value at one crossing
says nothing about whether an earlier crossing was local-policy. It might
be worth one sentence there saying
> that a derived-* value at a given crossing does not establish that the
originator's authority survived every earlier crossing. It’s similar to the
absence sentence Iman proposed: a local value, reported accurately, that a
reader will otherwise take as more
> than it is. Sumit P. Ahuja Main Labs On Thu, Oct 01, 2026 06:23 PM, Iman
Schrock <team=[e-mail]> wrote: > Hi
> Blake, Mikhail, Parisa, > > Thanks for closing the loop, Blake. I’d keep
your third rule as written, then put this sentence immediately after it: >
> “A record not found is reported as not found in the evidence set
examined. That does not establish that the
> event did not occur. An absence conclusion needs a defined boundary and
period, and grounds for believing every qualifying event would have left a
record in that set.” > > For the EXT-AUTHEV test: supply a
third-party-verifiable EXT-AUDIT record and no EXT-AUTHEV
> record. The expected result is the audit record’s own verifiability and
“not found in this evidence set” for authorization. Neither the audit value
nor the missing record establishes whether authorization occurred. > >
Parisa, does that fit the section you’re
> preparing? I can turn it into a direct edit if useful. > > Best, > Iman >
> > > On Thu, 01 Oct 2026 09:32:56 +0000, Blake Morrison <
[e-mail]
> <mailto:[e-mail]>> wrote: > Hi Mikhail, Iman, Parisa, > >
Apologies for the delay. > > Yes to adding it in the same section rather
than as
> a fourth rule, and > to Iman's "not found in this evidence set" as the
expected result for > the EXT-AUTHEV test. > > Nothing to add from me -
Iman, it's yours to write up. > > Blake >
_______________________________________________ > agent2agent mailing list
> -- [e-mail] <mailto:[e-mail]> > To unsubscribe
send an email to
> [e-mail] <mailto:[e-mail]>
>
> Nokia internal use