[Agentproto] Re: Topic: Existing practice, use cases, and deployment models

Nicholas Templeman <nicholas@csoai.org> Mon, 12 October 2026 16:08 UTC

Received: from out-2uec-a113.jellyfish.systems (out-2uec-a113.jellyfish.systems [63.250.43.113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id A6DAA46 for <agentproto@ietf.org>; Mon, 12 Oct 2026 16:08:13 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=csoai.org header.s=default header.b=OmAveeR1; spf=pass (mx.ietf.org: domain of nicholas@csoai.org designates 63.250.43.113 as permitted sender) smtp.mailfrom=nicholas@csoai.org; dmarc=pass (policy=none) header.from=csoai.org
Received: from mailcore-b4fcc7f95-n8xmd (unknown [172.29.114.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519) (No client certificate requested) by smtp.privateemail.com (Postfix) with ESMTPSA id 4j3MnN24pCz8sWN for <agentproto@ietf.org>; Mon, 12 Oct 2026 16:07:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=csoai.org; s=default; t=1791821272; bh=/lbs9fAvaBPnF+e6VfGKiXYI16CdzO/0l4GzIEEjOrs=; h=From:Date:Subject:To:From; b=OmAveeR1a8P+AVU5JAeDAqYVppKxkMIL3CCxzwpqVm93ea6jEivX/AzoggTi/3Ss+ WyxXESQcHxfchdUrHK3mrbp7MjXdAKq9KxNJIjY7UvD85OpsWt9Cbs35BDck1rEm+w +YgPVU+hJQBkTy7y2ZqLFT7jVilraMYj1Mnq0FSlI6uBA40v58TZg1Stz4pomHCKcO oHaaMrKM6JDMB1kz5/dHoElYh76QtOJPPiceCWfi0XDBhttLgxvvU3dARsJ9EMEQmD ZxmPXNL2dgFfmEteup1bj9d429sIWnC8cDdWKk375L+wcgvoQVnTFR5zrxgYWgdfxC WT91GVuhZd/qg==
From: Nicholas Templeman <nicholas@csoai.org>
Date: Mon, 12 Oct 2026 16:07:51 +0000
Message-Id: <135EDC8SJUU4.GMZJPY40D8KM3@mailcore-b4fcc7f95-n8xmd>
To: agentproto@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-PY5UfCmUMdJ6yhYjH424hQ=="
X-Spamd-Bar: ------------------------
Message-ID-Hash: ZHDBWMBMIBGZZDC4A2YYUJZU4YQRHBOI
X-Message-ID-Hash: ZHDBWMBMIBGZZDC4A2YYUJZU4YQRHBOI
X-MailFrom: nicholas@csoai.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [Agentproto] Re: Topic: Existing practice, use cases, and deployment models
List-Id: Agent Communication Protocols <agentproto.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/agentproto/gcwxa9tLXcRr5VKHJJpTotMUM54>
List-Archive: <https://mailarchive.ietf.org/arch/browse/agentproto>
List-Help: <mailto:agentproto-request@ietf.org?subject=help>
List-Owner: <mailto:agentproto-owner@ietf.org>
List-Post: <mailto:agentproto@ietf.org>
List-Subscribe: <mailto:agentproto-join@ietf.org>
List-Unsubscribe: <mailto:agentproto-leave@ietf.org>

Hi Orie, Leslie and all,





I would use draft-agentic-ai-usecases-requirements-03 as the starting point, with a short traceability mapping to Rosenberg-00. Its dialog/task-context distinction and numbered requirements fit the charter. Rosenberg's section 3.3.3 remains useful for pending downstream operations after reconnection, and section 3.3.5 for delegated authorization, without bringing application context or user-interface requirements into the dialog protocol.





Tiru's proposed -04 text addresses the current-dialog checks, refusal when checks cannot complete, acceptance-time authorization, and the distinction between resuming a dialog and learning an operation's outcome. I support retaining those clarifications.





The remaining precision I support is Bradley's sentence: "The authorization context may be carried in the dialog or by reference." At the lifecycle-transition decision, the participant should also distinguish a reference it could not resolve in time from a resolved value outside the applicable freshness bound, and distinguish both from an evaluated denial. These describe the inputs available for evaluation; they are not additional authorization decisions.





That is a targeted clarification to the proposed starting point. It need not prescribe an audit format, transport task context, or replace authorization mechanisms developed with the relevant working groups.





Best,


Nicholas