[OAUTH-WG] Re: New I-D: Problem statement on verifiable human mandates for autonomous agent actions
Blake Morrison <blake@truealter.com> Wed, 26 August 2026 12:12 UTC
Return-Path: <blake@truealter.com>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B0F7112FA30F8 for <oauth@mail2.ietf.org>; Wed, 26 Aug 2026 05:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787746351; bh=ksPYZxdY27K8OrzuPw6F/qZLwpI+DFmUMjcd0lx9tLM=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=gpvjmvKQ3oEf+bSD26E9y5cIumXei4C3VekkaOuqLQQOQvnLODQAmfByeo8QIdJ66 AQzbJ4+0GEn5gdw6cKJXygCFFSU1kAkds+vszQGBuNpKjTWh3z8PeSmpuAVaJwCdUp 11Q0nNZWHf6QFvco8mO4MWDjDA2bUWxTnGp3mQpI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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=truealter.com
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 6ZQLa_DebfEC for <oauth@mail2.ietf.org>; Wed, 26 Aug 2026 05:12:31 -0700 (PDT)
Received: from mail-10625.protonmail.ch (mail-10625.protonmail.ch [79.135.106.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3D38212FA30EE for <oauth@ietf.org>; Wed, 26 Aug 2026 05:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=truealter.com; s=protonmail; t=1787746348; x=1788005548; bh=ksPYZxdY27K8OrzuPw6F/qZLwpI+DFmUMjcd0lx9tLM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Cxc5o/oEECU8A7UqpGk4Cj+mfdBujZEq95OS6LsbN7swvknwvmH6aipVy3KNwvFZn 4yHrIJpk234VJHOXXuM+dB9IaebmuXs/1jNd88tkr6JB2LBskF42mYreyrB9KC1R/N 9JBqhERDjAfW0h03uV8RwprJw2sePz/SRoJllMOaQ90B2P+iyKVvUd50aDSQN/Srh/ gfDYdRlZhfqLd1rIqgRsikyt12HC/AfnFEMdOUmlBFY6612UWVYyJBqe6cMebK7bPS XaNy3Zc/WbkanGsWcMVRPZNsZEOPFaUHWMydywJ7gYyaLdW14Xeksq92m4gizd/x6t zH4uHQQCistmQ==
Date: Wed, 26 Aug 2026 12:12:26 +0000
To: oauth@ietf.org
From: Blake Morrison <blake@truealter.com>
Message-ID: <ITxGtpvZDzAVvODaTmowUGYjuEVMlaMVOX6CEfLxQtLZwtkN_OXCf_vVj9XpgMnlqGRlYyr6PB1J_MQ-WfHG0F_ChIESh1NX4j6Xm5FzkSk=@truealter.com>
In-Reply-To: <sBsWoXHgtt17647k3LIUiYLWAaeNwMtXhN66SQpprmJ35N6EWM6ke-4cZxwnFcFwE_fykYtJDXEKxQhAH-Pn1_dvjJhwO-o0KvjaXgXafsY=@proton.me>
References: <9241DDB3-78D5-44F1-AF5B-992113226235@yuthent.com> <kiD5GqNkywLXWyhXTw76cpJ3fS1zaynfR4-_RaUmdloFLNBrdp6Y6rSX505QoDdJVfv67h-BueZvk-0OIGI7m57OAkpqJxZR2oLsUBbBrnA=@truealter.com> <sBsWoXHgtt17647k3LIUiYLWAaeNwMtXhN66SQpprmJ35N6EWM6ke-4cZxwnFcFwE_fykYtJDXEKxQhAH-Pn1_dvjJhwO-o0KvjaXgXafsY=@proton.me>
Feedback-ID: 187617253:user:proton
X-Pm-Message-ID: 547f5d52e1ae2a5c0bf6ab27b744c13151fdb355
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: CMTNZ3Q7O4WJS3D3F5QVCRHCXJGNIWYZ
X-Message-ID-Hash: CMTNZ3Q7O4WJS3D3F5QVCRHCXJGNIWYZ
X-MailFrom: blake@truealter.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Mohamad Khalil Yossif <mohamad@yuthent.com>, morganLR <morganLR=40proton.me@dmarc.ietf.org>, "drew@truealter.com" <drew@truealter.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: New I-D: Problem statement on verifiable human mandates for autonomous agent actions
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Qzr8WZMfgksJhoDXDJECGOonhmI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
Morgan, Taking the T0-grade amendment. It keeps the separation clean for the reason you give. One consequence. If an amendment is a principal-signed T0 event at the original evidence bar, there is no amended mandate. There is a second mandate and the first is spent. That prices amend out of the asynchronous case, because a principal who can sign at T1 was reachable at T1, and an escalation with a reachable principal has a cheaper answer than amendment. So amend is not a peer of accept and refuse. It is available only where the principal is present, which means the response space an escalation may offer is bounded by reachability as well as by declarer independence. Worth saying in the document. Otherwise an implementer reads three outcomes as uniformly available and builds a flow that cannot produce one of them in the case the document exists for. Best, Blake On Wednesday, 26 August 2026 at 1:50 AM, morganLR <morganLR=40proton.me@dmarc.ietf.org> wrote: > Mohamad, > > The scope defense in your reply upthread is the most important paragraph this thread has produced. The evidence-bar versus governance-bar distinction is exactly right, and both load-bearing properties deserve to survive every revision: the principal as signer rather than as a subject of issuance is what makes the artifact mean something to a party who trusts neither the runtime nor its operator, and dynamic linking under PSD2 SCA is the deployed proof that regulators already require parameter binding at authorization. The general problem inherits that bar; it should not weaken it. > > Four requirements I believe the statement still needs, plus one on the Morrison exchange: > > Bounds versus parameters. Because agent intent is generated at runtime, T0 constraints are bounds, not parameters. That yields two requirements the current text allows to blur: T1 parameters must be provably within the signed T0 bounds (a subset check any verifier can perform), and designated action classes must obtain fresh principal evidence at T1 itself, because for some consequences no bound is specific enough. Your escalating class is the second requirement; naming both keeps solutions honest about which they provide. > Survival across delegation. If the executing agent sub-delegates, the binding must narrow, not merely persist: evaluation at hop N must see constraints no wider than T0's, provably, or the gap reopens at the second hop. > Mandate lifecycle at T1. Your second property settles where the evidence is verified; what remains is the mandate's own state. The verifier needs to establish that the mandate had not been revoked or expired at the moment of execution, within a stated staleness bound, and that the signer's key was valid then, which implies signer-key lifecycle (rotation, compromise, repudiation) is part of the problem, not deployment detail. For the after-the-fact auditor this becomes: re-verification against the state as of the action instant, not as of the audit. > Single reliance. An evidence artifact bound to an exact payload can still be replayed against a second identical execution. The statement should require that evidence be relied upon once, and that the reliance itself be auditable. > > On the escalation exchange: the formulation you and Blake landed on reads right to me, and the declarer-independence principle (the response space not declared by the party whose error the amendment reports) is the load-bearing part. One addition would close the evidentiary side of it: every outcome that mutates the mandate, amendment above all, must itself be a T0-grade event, signed by the principal at the same evidence bar as the original mandate, so the auditor finds an unbroken chain of principal-signed states rather than a mandate whose middle was edited by the machinery around it. That also keeps Blake's separation clean: whether an amended value is inside the constraint set stays a constraint-set question, because the amendment that produced it is just another signed T0 state to check against. > > For comparison while drafting -01: R1, R4, R5, R7, and R10 of draft-reece-wimse-cross-org-delegation state formulations of the narrowing, binding, principal, lifecycle, and execution-time requirements above, and the AIMS adoption thread carries an open gap item on the mid-execution case where a problem statement at this level is the frame being asked for. > > Morgan
- [OAUTH-WG] New I-D: Problem statement on verifiab… Mohamad Khalil Yossif
- [OAUTH-WG] Re: New I-D: Problem statement on veri… george
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Mohamad Khalil Yossif
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Blake Morrison
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Mohamad Khalil Yossif
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Blake Morrison
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Mohamad Khalil Yossif
- [OAUTH-WG] New I-D: Problem statement on verifiab… Blake Morrison
- [OAUTH-WG] Re: New I-D: Problem statement on veri… morganLR
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Blake Morrison
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Brian Vicente
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Blake Morrison
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Mohamad Khalil Yossif
- [OAUTH-WG] Re: New I-D: Problem statement on veri… morganLR
- [OAUTH-WG] Re: New I-D: Problem statement on veri… Kieran Sweeney