[OAUTH-WG] Re: New I-D: Problem statement on verifiable human mandates for autonomous agent actions

morganLR <morganLR@proton.me> Tue, 25 August 2026 22:30 UTC

Return-Path: <morganLR@proton.me>
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 46E8F12F5CA8C for <oauth@mail2.ietf.org>; Tue, 25 Aug 2026 15:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787697056; bh=VqJ/zPUSc2r9su7GCPS1TywprYQx6PwHyoG1bSuYBx4=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=x/4ep9Ub9dl3rpE3Q4BKUI5amA02ehBDjFO/247B6m7NfEj/U3zvAuzM7ZxJ5ud/P 38IE38K3oewXzE/r2oYKOatm5hE2cAAiWCPO/6KycskLWCoDj/zzNmQBcsun/cpLUX RDoT7neOhbyCR94Ahgup67D0uBG4Pgq/GF6GLLdk=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_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=proton.me
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 t97y2hjwFv4l for <oauth@mail2.ietf.org>; Tue, 25 Aug 2026 15:30:55 -0700 (PDT)
Received: from mail-244116.protonmail.ch (mail-244116.protonmail.ch [109.224.244.116]) (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 158EF12F5CA7B for <oauth@ietf.org>; Tue, 25 Aug 2026 15:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1787697053; x=1787956253; bh=VqJ/zPUSc2r9su7GCPS1TywprYQx6PwHyoG1bSuYBx4=; 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=OgSRuMAL6t//W92SzF5a4W51jomL0dyjcJfDHCHkm8PQMu/FqXcIr8hMK4hnXNQhM iRzqdKubPWsM9iTbBom/H2XRhLURXR6/2+3VLiJEDgiXJ+ZxFVR0RBtnBNKBE+JrkE jhq4sjtyzm5T8rSJEvYGnoxU9r1rGXSY1anuyrh4YICfK82AToqNB7QL90yC6Kb0Bw mFh1bkE50nb7D1JCincx4qt4Z3BDji//OJimu2BHrVY3LyffkoojLEoneIr1ZGvh9A zooLcHDKFX50sRrOAVifU8Iq/KeMmbRUI0QlnGPg3x08wOnjuYcq1JQqOLplcTkwsL IzPz/xBhsHn9A==
Date: Tue, 25 Aug 2026 22:30:47 +0000
To: Mohamad Khalil Yossif <mohamad=40yuthent.com@dmarc.ietf.org>
From: morganLR <morganLR@proton.me>
Message-ID: <hoS6CDDdfxr4IRFu8cvxwZ6hSRfbpO759wsBId-ADdxa10T9QmcQXaDglzgY7T62RZ1FOnTQxzI_RfPyAVh87Qth_Z_o6LVIW12p3_gBCCA=@proton.me>
In-Reply-To: <9ADF6824-D9FB-4F61-B6E3-021387A4B916@yuthent.com>
References: <9ADF6824-D9FB-4F61-B6E3-021387A4B916@yuthent.com>
Feedback-ID: 45800991:user:proton
X-Pm-Message-ID: 8ad5b9e1158c35603412fa1abc7515863f14c5da
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1=_6bC7LgXHsPwiNKW4zJlbyBGDaFssEzTgRU1Xw95c8"
Message-ID-Hash: 5ENSPFXUPWM6PT5CTOMUS7VXT7NJNOBO
X-Message-ID-Hash: 5ENSPFXUPWM6PT5CTOMUS7VXT7NJNOBO
X-MailFrom: morganLR@proton.me
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: oauth@ietf.org
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/agR7ORYGMTG5pnjcKQe3EOozQFU>
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>

Mohamad,

Checking each against running code before answering is the standard this genre should hold itself to; thank you for setting it.

Your hardening of the lifecycle requirement is right and better than my formulation: establishing the as-of state without trusting the party that held it is the requirement, and a timestamp is not a mechanism for it.

On single reliance, your split is the correct one and worth writing down as you stated it: the mandate is standing authority and reliance attaches to the evidence artifact. The reason the reliance itself must be auditable as an event, not just prevented by counter: with independent verifiers, each can honestly rely once unless consumption is provable between them, and an auditor reconciling an incident needs to know not only that evidence existed but which execution spent it.

On delegation: fair, and I will own the reasoning. The one-sentence version: standing authority that can be handed on without provable narrowing becomes wider than what the principal signed, silently, at the second hop: which is the T0-to-T1 gap reappearing between agents instead of between times. Happy to compare your implemented bounds vocabulary against the narrowing dimensions in draft-reece when you get to it; the mapping should be nearly mechanical, which is itself evidence the requirements are converging.

Morgan

On Tuesday, August 25th, 2026 at 12:02 PM, Mohamad Khalil Yossif <mohamad=40yuthent.com@dmarc.ietf.org> wrote:

>> Morgan,
>>
>> Thank you. I went and checked each of the five against what I have
>> running before answering, because I would rather tell you which are
>> already solved than promise to consider all of them.
>>
>> Bounds versus parameters. Your first half is implemented. In my
>> system the signed mandate claims are bounds, documented as such - an
>> amount ceiling, a daily ceiling, permitted action classes,
>> counterparty allowlists carried as hashes, and an agent scope declared
>> by the human at the grant ceremony rather than asserted by the agent.
>> A resolver performs the subset check at execution and refuses on
>> violation. So a verifier-performable subset check is not a
>> hypothetical requirement for me; it is the code path.
>>
>> Your second half is the more interesting one and I do not have it as a
>> first-class concept. A designated class that must obtain fresh
>> principal evidence at T1 regardless of whether the parameters fall
>> inside the bounds is different from escalation triggered by exceeding
>> a bound, and you are right that naming both keeps solutions honest
>> about which they provide. That distinction is worth a requirement.
>>
>> Mandate lifecycle at T1. Also implemented, and I agree it belongs in
>> the statement rather than being left as deployment detail. Revocation
>> is evaluated at the moment of the decision, the mandate carries an
>> expiry, and issuer-key compromise cascades through a revocation path.
>> What I would add to your formulation: re-verification against the
>> state as of the action instant needs the verifier to be able to
>> establish that state without trusting the party that held it, which is
>> a harder requirement than storing a timestamp.
>>
>> Single reliance. Partly. In my system a mandate is standing authority
>> and is meant to be relied on repeatedly, so the requirement cannot
>> attach to the mandate. It attaches to the evidence artifact, and there
>> it is the ordinary replay problem - a unique identifier and a
>> monotonic counter. The part of your requirement I do not have is that
>> the reliance itself be auditable as a distinct event. That is a real
>> gap and I will note it.
>>
>> Survival across delegation. I have nothing here, and I want to be
>> plain about why rather than agree politely. There is no
>> sub-delegation concept in my implementation at all, so I have neither
>> solved this nor discovered it is hard. That makes me a poor judge of
>> the requirement. If it belongs in the statement it belongs on your
>> reasoning, not on my agreement.
>>
>> On amendment as a T0-grade event: I think you are right, and it closes
>> something the exchange with Blake left open. If an amendment mutates
>> the mandate and is not itself principal-signed at the same bar, the
>> auditor is reading a state that the machinery edited. Blake's
>> separation stays clean under your version, which is the test I would
>> apply.
>>
>> I will take all of this into the next revision and see how much of it
>> survives being written down. I am not promising which requirements
>> land - some of these interact and I would rather find that out in the
>> text than commit here.
>>
>> On the two pointers: I will read draft-reece-wimse-cross-org-delegation
>> properly rather than skim it for the requirement numbers, and I will
>> look at the AIMS adoption thread before I write anything.
>>
>> Mohamad