[OAUTH-WG] Re: New I-D: Problem statement on verifiable human mandates for autonomous agent actions
Mohamad Khalil Yossif <mohamad@yuthent.com> Thu, 13 August 2026 07:57 UTC
Return-Path: <mohamad@yuthent.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 F0E58129036E6 for <oauth@mail2.ietf.org>; Thu, 13 Aug 2026 00:57:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786607871; bh=MaUP1BxaVf2aOpEJAOjPzaQ6P41h+5wCUl9UWqeQDGs=; h=From:Subject:Date:Cc:To; b=tYAG2EIjdc29F2OxFfy6tbO9/bbj8rVspthTYIx+B1nwfwxy7cgUNWqX1tNlJx2ud jQvGRxVDT5UEU/xzjrUBlh8fFlo2GB5201yFsSDEOP8Uq/VL1nW0nZgH7uvFZuBdc6 j0tloE+wkhRthKuBCRcGi+No3fIxcehccxFAJ2Z0=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 1.237
X-Spam-Level: *
X-Spam-Status: No, score=1.237 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_SBL_CSS=3.335, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=yuthent.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 cW9QfzTTnXJB for <oauth@mail2.ietf.org>; Thu, 13 Aug 2026 00:57:50 -0700 (PDT)
Received: from out-2z4y-a130.jellyfish.systems (out-2z4y-a130.jellyfish.systems [198.54.127.130]) (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 C6770129036E1 for <oauth@ietf.org>; Thu, 13 Aug 2026 00:57:50 -0700 (PDT)
Received: from MTA-08.privateemail.com (unknown [10.50.14.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by BSN-01.privateemail.com (Postfix) with ESMTPS id 4hLHlL6XhSz3hhTB; Thu, 13 Aug 2026 03:57:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yuthent.com; s=default; t=1786607854; bh=MaUP1BxaVf2aOpEJAOjPzaQ6P41h+5wCUl9UWqeQDGs=; h=From:Subject:Date:Cc:To:From; b=dbt54Nu5tkEq7jkBKj83ACxrJiwmmy7pi+5feQJ8PhNg6qGzfvMGDt0z5WPMbapcC SGc0SZYcnTtgvmpt6FVgEpptbTTwUtqw+VD1TUMFCAv94fF48LQ1zt30J5UjdVmecd vO2A7ls697G3OGWam/5U1lqb6YOT7KRqE51VuH7VaSxFxbYOiHLXPUL1ruIUAc7Cew AxxYCZcpNTOJCP4EIEPC1MU1lP+B3ZPsqB1I09vOJHEBLgKFauppqKyyn1HvT0BFSj sTTzxAbxheXK4ayYv0MYNdplcOmKhWa5Aew8Gsd0m1F5uzir+AmGoqVh9Uhh2cVMUJ CPtMOxWR0knWQ==
Received: from mail.privateemail.com (K8S-PROD-WORKER-01 [79.177.153.50]) by mta-08.privateemail.com (Postfix) with ESMTPA id 4hLHlK16JZz3hhTP; Thu, 13 Aug 2026 03:57:32 -0400 (EDT)
From: Mohamad Khalil Yossif <mohamad@yuthent.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE6BF246-E7C8-4045-9DF2-67C3BD4AF91D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
Message-Id: <9241DDB3-78D5-44F1-AF5B-992113226235@yuthent.com>
Date: Thu, 13 Aug 2026 10:57:21 +0300
To: oauth@ietf.org
X-Mailer: Apple Mail (2.3864.700.51.1.1)
Message-ID-Hash: 54MVNFAM2H7DKX6R73NSFODOA5GSK3O7
X-Message-ID-Hash: 54MVNFAM2H7DKX6R73NSFODOA5GSK3O7
X-MailFrom: mohamad@yuthent.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: blake@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/9S8DSvvSruQp1epBaFIsw4rXqmM>
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>
> Blake, > > You're right about the axis. My tiers grade how hard the challenge is > before signing. You're asking what can come back after it. Those are > different questions and mine doesn't touch yours - CONFIRM and STEP_UP > both still end in accept or refuse, so I made the question harder > without making the answer wider. > > The amend case is the one with nowhere to land, and I agree it's the > one worth keeping. "Right question, wrong amount" is the human telling > you the agent got something wrong. Collapsing that into a refusal > keeps the outcome and throws away the reason, and the reason is the > more useful half. > > Before I write it into -01 I want to get the requirement right rather > than the mechanism, and three things are unclear to me. This is a > problem statement, so anything I put in Section 6 has to say what must > be true without saying how to build it. > > First, "wider than two" counts options, and counting is already a > design choice. What I think you're actually pointing at is a property: > the return must be able to carry a response that is neither acceptance > nor refusal. That states the failure without prescribing a shape. Is > that the requirement you mean, or do you mean something stronger that > a count captures and a property doesn't? > > Second, and this is the one I keep going back and forth on - who > declares the response space? > > If the escalating side declares it, the space is closed and the agent > still controls it. An agent that never offers amend leaves the human > exactly where they were, and the requirement is satisfied on paper > while the gap survives. > > If the human can return an amendment whether or not it was offered, > the space is open, but then the requirement lands on the party that > has to accept an unanticipated response, which is a much larger claim > for a problem statement to make. > > I don't think Section 6 can be written without choosing, and I don't > want to choose by accident. > > Third, an amendment carries a value the original didn't. Something has > to decide whether that value is within what was originally authorized > - 500 instead of 5000 is fine, 50000 instead of 5000 is not. Is that > inside the escalation requirement, or a separate one about the > constraint set the amendment is checked against? My instinct is > separate, because otherwise Section 6 quietly becomes a negotiation > protocol. > > Where I've landed provisionally, and tell me if it's wrong: the > requirement is that the escalation return be able to carry a response > that is neither acceptance nor refusal, and that whatever the response > space is, it be declared rather than implied. What that space contains, > and who is bound by it, sits outside a problem statement. > > Mohamad
- [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