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

[Mikhail Sergeev <[e-mail]>]

Blake, Parisa —

Blake's cut seems right: grade what the exchange emits — the artifact and
the root it offers — not whether verification later succeeds.

One distinction may be worth making explicit in the dimension text.
Verification reach and action-claim strength do not imply one another. A
third-party-verifiable invocation record is still invocation evidence. A
record from an operator-controlled executor may support execution under
that boundary even if verification still depends on the operator.

That second question is what the Witnessability Model classifies, and what
WEXP is intended to make consistent across carriers at verification time. I
wrote down four test cases and the non-inference rule; happy to post them
as plain text if useful.


Mikhail

On Thu, Jul 16, 2026 01:29 AM, Blake <blake=[e-mail]>
wrote:

> Iman,
>
> Your pin is the right axis.
>
> Grading on whether the verification root can be pinned independently of
> every
> participant is correct but Section 11's rule is that a dimension has to be
> protocol-visible within one exchange and exercised distinctly and it
> rejected
> delegation transitivity and trust-domain span for reaching past a single
> exchange. Your pin, Steven's survival outside the session, and Chris's
> external chain-head test all describe the same property from outside the
> exchange, by a party who wasn't in it. Three routes converging shows the
> property matters. It doesn't show it is exercised within one exchange,
> which
> is the test everything else in the model had to pass.
>
> What keeps it inside the model is to grade what the exchange emits (the
> artifact and the root it offers, both readable per exchange) and to leave
> whether verification later succeeds to the substrate since that turns on
> log
> liveness, keys and retention, which Section 11 put outside. If your pin
> already
> means the offered root and not eventual verification then we agree.
>
> Best,
> Blake
>
>
> On Tuesday, 14 July 2026 at 2:59 AM, Iman Schrock <team=
> [e-mail]> wrote:
>
> > Chris, Parisa, Steven,
> >
> > Good convergence. And Chris, grading your own stack three ways on the
> axis is the honesty that makes the model worth having. The action row you
> describe, records signed and stored by the audited party with nothing
> external pinning the chain head, is exactly the case this dimension exists
> to distinguish, and stating it plainly about your own drafts sets the bar
> for everyone's rows, ours included.
> >
> > One definitional pin before Parisa drafts, so the top value keeps its
> teeth:
> >
> >
> > The test for third-party-verifiable is not whether an object is
> self-contained.
> > It is who a non-participant must trust in order to verify it. A
> self-contained object reaches the top value when its verification root can
> be pinned by the relying party independently of every participant,
> including any platform that operates the exchange.
> > Self-contained and self-rooted are different properties, and the grading
> turns on the second.
> >
> > With that one sentence in the drafted text, the value of every proposal
> becomes a mechanical read of its verification root instead of an argument.
> >
> > Iman
> >
> > On Mon, Jul 13, 2026 09:35 AM, Chris Hood <[e-mail]> wrote:
> >
> > > Parisa, Steven, Iman,
> > >
> > > One bit to clarify, and for the record: I still argue that the scale
> of agents requires a different approach. However, from an AGTP point of
> view, third-party-verifiable being a dimensional value holds up against
> AGTP-CERT signed objects as self-contained, verifiable offline, with
> SCITT-style anchoring as one composition path.
> > >
> > > So on the axis: single evidence-verifiability dimension with
> EXT-AUTHEV and EXT-ACCTEV works. Third-party-verifiable as a dimensional
> value with substrate realization options fits what AGTP already does.
> > >
> > > AGTP-TRUST §4.1 defines three Tier 1 verification paths: dns-anchored
> (ACME/DNS TXT), log-anchored (RFC 9162 + SCITT receipt), and hybrid (DNS +
> blockchain signature). The draft states that all three produce attestations
> of equivalent strength for protocol purposes. Same value, three substrates,
> declared interchangeable by the spec itself.
> > >
> > > The action side is stronger still. AGTP-IDENTIFIERS §1.4 states that
> Audit-IDs remain outside the transparency log commitment in AGTP-LOG. The
> per-action evidence (the extended Attribution-Record, JWS-signed,
> hash-chained via previous_audit_id, retrieved by INSPECT target=audit) is a
> self-contained signed object with no log in the verification path. That is
> a shipped, specified instance of third-party-verifiable evidence realized
> without SCITT anchoring.
> > >
> > > AGTP-LOG's abstract makes a sharp architectural claim: statements are
> signed by the governance platform rather than by the agent, so the audited
> party cannot forge its own trail. That is right, and it is the correct
> design for the class of evidence it covers. But AGTP-LOG covers five
> identity-lifecycle events (genesis issued, revoked, suspended, reinstated,
> deprecated). Its scope stops at identity events. The action chain in
> AGTP-IDENTIFIERS is signed by the agent, stored by the agent, and §8.4
> requires the agent to enforce append-only semantics on its own audit store.
> Nothing external pins the chain head.
> > >
> > > So within one protocol family, on the same wire, the axis already
> grades three ways:
> > >
> > > -   identity events: operator-signed, log-anchored, monitored →
> third-party-verifiable, with non-equivocation and completeness
> > > -   action events: agent-signed, agent-stored, unanchored → each
> record individually verifiable; the audited party controls production
> > > -   alg: none fallback (§8.3.1): hash-chained, Audit-ID computed,
> explicitly carrying no anti-forgery claim → none
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > On Mon, Jul 13, 2026 at 8:54 AM Chris Hood <[e-mail]> wrote:
> > >
> > > > 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]. 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
>
> _______________________________________________
> agent2agent mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>