Return-Path: X-Original-To: agent2agent@mail2.ietf.org Delivered-To: agent2agent@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8087E115D9328 for ; Mon, 13 Jul 2026 07:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783952286; bh=R8xB7bKJBty5DU8ZFnMquzGcSRj9MxVS8P2/Pi3PQQ8=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=QML33Kz4RYIF8mKXCF52czdm46wlR4iLr+SZJv1fNaATp4u7LjpEa/YkbIEDKkluk jX4XQMwTp3/JpK3WCeY3diiap8O7RTDkvmmxHVu+WamOdD5JER9foIuixEurmOLNt4 7an6/mkYfCVui9xtGzix1iE/L4V7m5JT12q1wXfc= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=emiliaprotocol.ai Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaCUEQdq8jWD for ; Mon, 13 Jul 2026 07:18:05 -0700 (PDT) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B005A115D9321 for ; Mon, 13 Jul 2026 07:18:05 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-6a39a267d34so715664eaf.2 for ; Mon, 13 Jul 2026 07:18:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783952285; cv=none; d=google.com; s=arc-20260327; b=ns8S6oUDOCl6lmGlYjy2eqH8XQcqH9MTXvm5FM7oP3zmkztfUHrcGSOCklohaXv/kW /8iGMgOYgL8+8cZc8KKS7lXNp2jxjyFvt+Sjfc3NAsCzeoTVkWI3SVIAPYNitupHNLOm 2cz/Ck1tthbDRy+Wme6RFYBT30CRKGe0CubVCG51IOLXNZbZ3bwQTWtNvkTD0QLjQygR bpXjTro+aC/G5uxvn+rXfEOQdBLPxCtepp36cYDCg8YT27kvB2qYevCeiehVfhVbOYPD VdU0fT9uIDmS69Es8AW6kfuBg55L30whN50LvfevYlYL1QDGH2Oqf6Y4iJPMn3N+COuY j9DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=idO9riQx3rTBJ2uB/VxYoaaJzZl1TKiTPCsgDj898yE=; fh=XVNp6njje8NIXDiOZ5UHeml9PkAbyav0isjyb+DUDiQ=; b=Jb9iMCx3hybid6oF0lxqHCh+Zm/AksX7YqryprEzPodlxYgMpCzsafxHjwyIkkGwLI T+qEHOSH4S6hgk+Qu+A4v2dt4fvptAei3QORhGA9o7g0ixGxqCAcyXVdvDE+bThDi0nS 54caxNuOHhKog1y2ZurV28+odstB59zXn+uJsGsisEtNuTv1wav8pDr0P5rfjzR5WtaX /9pNrrdsYFObaB5lfOU3b90MUpOyXSDYFoS+pPiMssU+XClKd15EOfhF7EHsfGMVxl9V W81Sy2gBIet28km9jLFH8M9KYaluAkOld5lKC3HOuS+5m/4NNB1sQkHAX5uQ5VyTJWBT fXNA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emiliaprotocol.ai; s=google; t=1783952285; x=1784557085; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=idO9riQx3rTBJ2uB/VxYoaaJzZl1TKiTPCsgDj898yE=; b=WdqUJFyM/JcwTivztYFE6ofguav87Lm2SA8vXfk0I3YZFO+w8hFVG5lf23SrF5Oel7 gaUR7eB2bdfgr3Uq3E0o6MbFN0u468MSvx3/xYN58pnD4D1LJf/hr3gK3PHTgFmlP1K9 MQ8StVCZ0bQDEVti/xpD1gAN0DV/qh+SNKyiIVGy7YILkHl9YUG9ycWGcAthM+Lvfb0c LbG1bWZE9DDWhIJ3+JR9kPxGeHZyLFYVxfHEf36fsqlRmiyTQlbrQo15jTJSA48u4UBU IXorJmgJ727mjtbqJjD9TVuGOKgj9JdJ9T8H5X9nhxDHuDCYpOKl+/BCAJttwX3iojUr lN8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783952285; x=1784557085; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=idO9riQx3rTBJ2uB/VxYoaaJzZl1TKiTPCsgDj898yE=; b=R3nSGUmQKJCPWOpMckttZClGEBT4QMNnoTwcz5YH434xo59Y9pPN8T68SAHManInnh /GkTl6JrZEOLv/PlfZ8t1nvBn04pGaDDrd/2LIh55XZXUIgBOK1mfUoIiRhLEXK6S4l5 T4fzEyAxmbXiNk2VZlHCtUmDtzRc4OY7fU3Tw3v7TugyXNaw6c2vn6SDgLazk74qLaSJ bqY5BZIERJKXIhgEN29b5oUNbskhdw8Rp8Ee84om4aQbr+UjKfIhY0V3aT5sAy4cNdCF 5ovDERGdKqKNoVCEYUSTY+CuOdI1p7Ji87beG3IVuZfWRJQCTtSIch0sImdHtcMlqqd6 L/Gw== X-Gm-Message-State: AOJu0YylJ58chGDjEeQt4YRCGEFQaD0LlK6T9Em8ZdohNv+ng2YO33+z 6W9mlMjIQBGX+vsCf6W4bjSEKWX48ZpA64pmrbXHvR2tenJUt3ED4cS666FP+YDVJdzNfoO2n1/ XvMbBkYtkumLcHrZunz8JGAbhSTpDnCJtTwkvBA5CVmc= X-Gm-Gg: AfdE7ckn+Zp/PgId1eLlBV2rqtm3UVkZPKf/1PTmDuECv54CBHgk3kmo5Pdq1zJDFVC xmB3Gr+Zrh0HO97vEcRL27jMc9q4o+XpBVWIkvHRj7POO4gRUTPXxkmvlXPl5OVka4r49Ft4uq6 NgnfNa5JaqK0Gu4siDldmD3e3t0R9bQBdhYraKO9ApqO7NDT9dmIHCCUubQMF8CnIyNk4XcEJoq 3km7vkfM8klKryYqED9plzXGuW4ayRqztMkoBWIS/3f3H1QifBy2BhXjeHK2h2/TtqR2083wWsJ YZRyhLb3duZFNaX1wGYjiUtKWvLJWF+TSca07QSXrlc4GNsHx92zugStGY7y1tvj8sWavP6uWay dsCccjbySTg== X-Received: by 2002:a05:6820:4deb:b0:6a3:7822:9396 with SMTP id 006d021491bc7-6a39a831b5fmr5309239eaf.58.1783952284908; Mon, 13 Jul 2026 07:18:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Iman Schrock Date: Mon, 13 Jul 2026 07:17:53 -0700 X-Gm-Features: AUfX_mw2qv7jVs2SmREDAdZAwpwgjOog_RkBufOaBCVvx0Iu4XjBAk8QZ0OaVO4 Message-ID: To: parisa.foroughi@nokia.com Content-Type: multipart/alternative; boundary="0000000000003d138b06567ec218" Message-ID-Hash: VOU4PGXQSEWTE3F4KID7BEAWDJQEJSOZ X-Message-ID-Hash: VOU4PGXQSEWTE3F4KID7BEAWDJQEJSOZ X-MailFrom: team@emiliaprotocol.ai X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: agent2agent@ietf.org, steven@actionstate.ai, chris@nomotic.ai X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bagent2agent=5D_Re=3A_New_I-D_=3A_A_Dimensional_Model_for_Charac?= =?utf-8?q?terizing_AI_Agent_Protocol_Proposals_and_Their_Substrates?= List-Id: Standardization of AI Agent Communications Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003d138b06567ec218 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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)" < parisa.foroughi@nokia.com> 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 rath= er > 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 th= e > 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 requir= e > capturing two more extensions (i.e., a pre-action authorization receipt a= nd > 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 protoco= l > work, so I will name them and leave their design to you rather than settl= e > it in the model. If we converge, I'll draft the dimension and mapping, ci= te > your drafts as the worked data points, and share it with you for review f= or > the next revision. > Looking forward to further discussion. > Best regards, > Parisa > > > > ------------------------------ > *From:* Steven Mih > *Sent:* Monday, July 13, 2026 5:55 AM > *To:* agent2agent@ietf.org > *Cc:* Parisa Foroughi (Nokia) > *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 steven@actionstate.ai. 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 =E2=80=94 a neutral dimensional model is exactly what thi= s 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 =E2=80=94 actions leave only operator logs. > - Participant-verifiable =E2=80=94 the parties to an interaction can veri= fy each > other's records (signed receipts, mutual attestation). > - Third-party-verifiable =E2=80=94 a non-participant (an auditor, a count= erparty'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 change= s > 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 th= at > look similar on other axes =E2=80=94 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 recor= ds > over SCITT), draft-mih-agent-bilateral-attestation (the > participant-verifiable=E2=86=92third-party-verifiable step for cross-orga= nization > 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 > --0000000000003d138b06567ec218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 b= efore 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 d= igest reference. They share the verifiability scale, so a single evidence-v= erifiability dimension with EXT-AUTHEV and EXT-ACCTEV naming the two artifa= ct classes captures both without fusing artifacts that carry different proo= f obligations.

On the second question: third-party-verifiable is a d= imension value, not a substrate property. A self-contained signed object th= at carries its own key material is verifiable by a non-participant, offline= , with no transparency log in the path. Our published conformance vectors w= ork exactly that way: each vector holds the document, the public key, and t= he expected verdict, and anyone can hand one to an auditor who trusts neith= er party. What a transparency log adds is anchoring: append time, non-equiv= ocation, 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 i= s 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, &q= uot;Parisa Foroughi (Nokia)" <parisa.foroughi@nokia.com> 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 produce= s an independently verifiable record, and who can verify it.
  • Iman, from the receipt side: is there a verifiable authorization decision o= n the wire?
  • Chris, from the substrate side: what can the receiving agent verify indepen= dently?
  • 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 some= thing belongs in the model, so I'm inclined to adopt it, and I'd ra= ther design it with you than pick one framing.
What I propose: One axis/new dimension call it evidence verifiability, usin= g Steven's grading: none (nothing independently verifiable crosses the = wire) / participant-verifiable (the parties can verify each other's rec= ords) / 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-ACCT= EV) rather than two dimensions.=C2=A0 Since they share the identical scale and same orthogonality to the existin= g seven dimensions.=C2=A0
Two questions for you:
  1. Is verifiability the = right single axis, rather than authorization and accountability as separate= dimensions?
  2. Is third-party-verifi= able a clean dimensional value, or a value realized by a substrate,=C2=A0 s= pecifically SCITT/COSE transparency-log anchoring (RFC 9162), which all thr= ee of your drafts build on?
The evidence artifacts themselves=C2=A0 (i.e., a pre-action authorization r= eceipt, a post-action accountability record) are extension-layer protocol w= ork, so I will name them and leave their design to you rather than settle i= t in the model. If we converge, I'll draft the dimension and mapping, cite your drafts as the worked data point= s, and share it with you for review for the next revision.
Looking forward to further discussion.=C2=A0
Best regards,
Parisa



From: Steven Mih <steven@actionstate.ai>
Sent: Monday, July 13, 2026 5:55 AM
To: agent2= agent@ietf.org <agent2agent@ietf.org>
Cc: Parisa Foroughi (Nokia) <parisa.foroughi@nokia.com>
Subject: Re: [agent2agent] New I-D : A Dimensional Model for Charact= erizing AI Agent Protocol Proposals and Their Substrates

You don't often get email from steven@actionstate= .ai. Learn why this is important
=C2=A0
CAUTION: This is an ex= ternal email. Please be very careful when clicking links or opening attachm= ents. See the URL nok.it/ex= t for additional information.

=C2=A0

Parisa,

Thanks for this =E2=80=94 a neutral dimensional model is exactly what this = cluster of proposals needs before Vienna, and characterizing rather than ra= nking is the right instinct.

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

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

The reason it earns a dimension of its own: it's the property that chan= ges least across substrates. Two protocols can differ on every axis you'= ;ve defined and still need the same answer to "prove what the agent di= d to someone who trusts neither of us." It also cleanly separates proposals that look similar on other axes =E2=80=94 many= carry signed messages (participant-verifiable) while very few produce reco= rds 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-mi= h-agent-bilateral-attestation (the participant-verifiable=E2=86=92third-par= ty-verifiable step for cross-organization actions), and draft-mih-sato-agent-accountability-composition (how the acc= ountability dimension decomposes into CAN/WHO/WHAT/AUDIT slots that differe= nt 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
--0000000000003d138b06567ec218--