[OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt

morganLR <morganLR@proton.me> Thu, 23 July 2026 14:01 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 E54A911D77349 for <oauth@mail2.ietf.org>; Thu, 23 Jul 2026 07:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784815316; bh=EWa9MovgMf5/wz73kx1b4KnVvX6VdtC0TmBzpIIjWF0=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=xdkMfa1zqV0Uj1FL2Fer/oy10Q49RT0TOkZoR5+2bMJCnCVGlucKNchy01oM1sIlg iH3ysv/DzJlHP+x2yaMEXkt07OKtzBNdE4euqeSzyWZMnNuNWb8cH3QW6OeaUTXwrd gcc1ZF7nl2vMxP+98ZXWIbXMV4sD+HmAZfNrxA3Q=
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_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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 qAXyjqTjYru5 for <oauth@mail2.ietf.org>; Thu, 23 Jul 2026 07:01:56 -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 0107B11D7733F for <oauth@ietf.org>; Thu, 23 Jul 2026 07:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1784815308; x=1785074508; bh=HwxM3adBJkJyZ5nV8rVAzm8bVE1uhcyrXK4T3ZVdKo0=; 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=O7hp/x+7KT61bafnjju2wYT7OLEDk2VSmLFD+qeFjS50DK25zajQ/IL2GSqpWTLof ThGJlTrzXPZgDThQiEqbRc5/ODjw3mtvxxb7ymW4iMhmy6PyeAFURIgcTG3AN+IU8+ kmmOCDVtNZj+wjm11qe83OH6Yh6i+zMjFQhvVxjsjvNsxUP0iQnC00jFNSMWbK19A5 GGjEi+jwKbrAc1x3tbji/0Zfewihi6s5UY9sLMluUBYPbHb77AmukIS1fA5uYZYUCp 69tfa1MeHG7OF+CAAENzeLkVi2s1de2k2ZdO+lhVBVl80cD/MuXuzRR9YqzZBnI9yq mgoZDIu9TLDsw==
Date: Thu, 23 Jul 2026 14:01:42 +0000
To: Mohamad Khalil Yossif <mohamad=40yuthent.com@dmarc.ietf.org>
From: morganLR <morganLR@proton.me>
Message-ID: <zB0m8AyNdPnby_0TATSqlweeYCH6XbR4R-Vi23M6YW-EHOlHJGMa-85_nN4Dy9TUQ1dARmqEzJS1mrHUTzTHvCejFcHMv6hEHYGFU0jvX7g=@proton.me>
In-Reply-To: <79C8FBE6-832B-4CDF-A04B-57369EC3971B@yuthent.com>
References: <178326844691.267540.6806897697824010077@dt-datatracker-57b5d8f849-zrqfx> <202607132157242002541@chinamobile.com> <49E4C072-13E0-4A56-B6BA-2D1DF70F0C0C@yuthent.com> <202607151957484157299@chinamobile.com> <56ADA8DA-10DA-4899-A4B4-3907B5682808@yuthent.com> <202607152116331707952@chinamobile.com> <qKxC6Uj-5GJVJdb76e3zWpzPzN7pq4fE3Bm7SVyar8oU20vLNdf9UQ2eK9MtPCjZnc3_VP2C9Cjs3qZzienzFJCC1dRZzSHBdnDHtUC-kKc=@truealter.com> <6173A0FE-5A07-4D85-B768-028241A019FD@yuthent.com> <79C8FBE6-832B-4CDF-A04B-57369EC3971B@yuthent.com>
Feedback-ID: 45800991:user:proton
X-Pm-Message-ID: 048fb76133a230b51ef9c3ff888ad56c5d783c55
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: GXAI77HJG5H3NM56IDUUP7SDVSMED6TC
X-Message-ID-Hash: GXAI77HJG5H3NM56IDUUP7SDVSMED6TC
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: Blake <blake@truealter.com>, oauth <oauth@ietf.org>, "chenmeiling@chinamobile.com" <chenmeiling@chinamobile.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dqz-wOKWQeS1_V92IdGA34TwgSI>
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>

Meiling,

Thank you for the session presentation and for the -01 revision. The gap analysis is exactly the kind of foundation the group needs before mechanism selection, and I want to engage with two parts of it.

First, on Use Case 5. During the session you referenced a prior list discussion of the cold-start scenario; in case it helps the record, that framing aligns with requirement R2 of draft-reece-wimse-cross-org-delegation-00 (cross-organizational verification without an interaction-specific prior arrangement), which I also applied in my July 20 note on the cross-domain transaction token thread. Your UC5 gap statement, no universal secure protocol for scoped, revocable access in a zero-trust, no-pre-channel initialization, is a very good articulation of it, and I would be glad to see it survive into whatever this document becomes.

Second, an offer. UC5 as drafted covers the case where the service side lacks authorization infrastructure entirely. There is a companion case that I believe belongs alongside it: both sides have full trust infrastructure, the agent's organization and the service's organization each operate their own, and there is still no pre-authorization channel between them because they have never interacted. This is the ordinary condition of cross-organizational agent delegation, and its requirements are stricter in some dimensions (the service must be able to verify delegated, attenuated authority from another organization, potentially without a runtime callback to it) and looser in others. I would be happy to contribute that use case in your document's format, along with a mapping of the -01 gaps to the R1-R9 requirement set from the draft above, as review input rather than as competing structure. I also have a couple of small terminology notes, including one on the classical confused-deputy framing in UC3, that I will send separately so they do not clutter this thread.

Thank you again for anchoring the discussion at the use-case level.

Regards,
Morgan



Sent with Proton Mail secure email.

On Wednesday, July 22nd, 2026 at 7:36 AM, Mohamad Khalil Yossif <mohamad=40yuthent.com@dmarc.ietf.org> wrote:

> Following the axis you both settled on: the execution-time class in
> that split is exactly where a delegation-constraint layer sits, and
> the ex-ante piece is where the human-signed mandate lives before the
> agent acts.
> 
> I have posted a short problem statement on that upstream piece:
> 
>   draft-yossif-agent-mandate-problem-00
>   https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
> 
> No protocol, no mechanism. It states the gap between an authorized
> agent and an authorized action, and the requirements any solution
> would need to meet. draft-yossif-psea covers the execution-time
> evidence; this new draft covers the ex-ante mandate the evidence is
> verified against.
> 
> For the catalogue: this may be worth citing as a problem reference
> under the delegation class, alongside the existing entries.
> 
> Feedback welcome on the framing.
> 
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>