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

Meiling Chen <chenmeiling@chinamobile.com> Wed, 12 August 2026 13:59 UTC

Return-Path: <chenmeiling@chinamobile.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 55565128918FF for <oauth@mail2.ietf.org>; Wed, 12 Aug 2026 06:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786543178; bh=VSkcCgVVUGEmw0MlVdcDzgEV9KgqBJTIz+Aa9facJ04=; h=Date:From:To:Cc:Subject:References; b=biap1gIbmAIgPfygJITpQxm8UDGWqBj7We9X/iPjzANBGYU+WTNQYXi8QoVOhtgHK JydMPDPtpRae7/LUh8TBxVtjNGZon28U9V2/AmbCDm0uaqna8rvij7zSpyRxsGpdFH 299sxs75+eqJayxJVR9HbePCNmOkgB/M4L6rz9SI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=chinamobile.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 9KpF-NNK52dN for <oauth@mail2.ietf.org>; Wed, 12 Aug 2026 06:59:35 -0700 (PDT)
Received: from cmccmta8.chinamobile.com (cmccmta8.chinamobile.com [111.22.67.151]) by mail2.ietf.org (Postfix) with ESMTP id 014CA128918F9 for <oauth@ietf.org>; Wed, 12 Aug 2026 06:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chinamobile.com; s=default; l=0; h=from:subject:message-id:to:cc:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=U3l2mVLwvOjcTON6EclHjFMqmoMBao+9CZLRXU3HE59SU6vMesnlNciWKH83tdSNmLQuo5u7nM8e3 chtC00KJsYXApEtePXxMFoX/4/TzUbjRyafs1ySzSUVEehnhQ3cZZjv7CkHHsvkRzJuq9vCDXaOGN5 yCZLdmruQmfvV4s8=
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from mail.dlp.master (unknown[10.188.0.87]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee26a7c7c3bffd-34ca1; Wed, 12 Aug 2026 21:59:28 +0800 (CST)
X-RM-TRANSID: 2ee26a7c7c3bffd-34ca1
Received: from wxh.mailtest (localhost [127.0.0.1]) by mail.dlp.master (Postfix) with ESMTP id 7676315A02EC for <oauth@ietf.org>; Wed, 12 Aug 2026 21:59:28 +0800 (CST)
Received: from spf.mail.chinamobile.com (unknown [10.230.70.214]) by mail.dlp.master (Postfix) with ESMTP id 8FC8A15A02EC for <oauth@ietf.org>; Wed, 12 Aug 2026 21:59:21 +0800 (CST)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from DESKTOP-U9UKLCC (unknown[123.113.228.158]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee16a7c7c35038-87f8f; Wed, 12 Aug 2026 21:59:21 +0800 (CST)
X-RM-TRANSID: 2ee16a7c7c35038-87f8f
Date: Wed, 12 Aug 2026 21:59:19 +0800
From: Meiling Chen <chenmeiling@chinamobile.com>
To: Mohamad Khalil Yossif <mohamad@yuthent.com>
References: <F0148C3C-5896-4438-9ABB-FAAEFDD767B0@yuthent.com>
X-Priority: 3
X-GUID: 9DB21297-10B4-4610-ADFF-D7BCEEB0A98A
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.542[cn]
Mime-Version: 1.0
Message-ID: <202608122159189277143@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart811855075487_=----"
Message-ID-Hash: TKUC3LMTWDSODLHZS7ZVI6Z2ZFWVRGRC
X-Message-ID-Hash: TKUC3LMTWDSODLHZS7ZVI6Z2ZFWVRGRC
X-MailFrom: chenmeiling@chinamobile.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: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-02.txt
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/B71IDEv3-3oPgEB5rmX2He12zME>
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>

Hi Mohamad,
Thank you for your email. First and foremost, please accept my sincere apologies for the conflicting guidance and the confusion this has caused. You were absolutely right to flag the contradictory instructions, and I appreciate you asking for a clear direction before proceeding.
After you pointed this out, I went back and reviewed Yuning's recent, detailed comments on Issue #15 and the corresponding updates to Use Case 1.
I now agree completely with your and Yuning's assessment. The approach to enhance UC1 is the correct one, and we do not need a new standalone use case for this. The updated text, which covers the three points Yuning listed (binding constraints, preserving admission basis, and verifying evidence), appears to address the core requirements you outlined.
The crucial next step is to ensure this solution works for you. Could you please review the latest version of the UC1 text and confirm that it fully resolves the issue from your perspective?
In particular, we want to be sure it meets the excellent point you raised: does the text make it clear that this is a failure where "the agent had authority and the specific action was never approved by anyone"? Your confirmation on this would be invaluable before we close the issue.
Thank you again for your diligence and for pushing for clarity. It's greatly appreciated, and I'm sorry for the detour.
Best,
Meiling


chenmeiling@chinamobile.com
 
From: Mohamad Khalil Yossif
Date: 2026-08-12 21:09
To: chenmeiling
CC: oauth
Subject: Re: [OAUTH-WG] New Version Notification for draft-chen-oauth-agent-authz-use-cases-02.txt

Meiling, Yuning,

Before I open a PR I need one thing settled, because the two answers
I have point in opposite directions and whichever I build will
conflict with the other.

Yuning wrote on #15 yesterday that the scenario is better handled
inside UC1, that UC1 has already been updated to cover it, and that
#15 can be closed as merged.

Meiling wrote this morning that a new standalone use case is the
clearest approach, and asked me to open a PR in that shape.

I am happy to write either. Tell me which and I will send it.

For what it is worth, my own view sits closer to Yuning's, and I want
to say why in case it helps you decide rather than just defer.

The three points Yuning added to UC1 are the right ones - binding
approved constraints to later execution, preserving the admission
basis through to the endpoint, and verifying execution-time evidence
before the action takes effect. Those cover the gap. If they are in
UC1 already, a separate use case would restate the same requirements
under a different narrative, and the catalogue gets longer without
getting clearer.

The one thing I would check before closing #15 is whether the UC1
text keeps the distinction visible. The failure is not that the
agent lacked authority, and not that the wrong principal acted. The
agent had authority and the specific action was never approved by
anyone. If UC1 now carries that as a stated requirement rather than
as narrative context, then #15 is genuinely covered and I have no
objection to closing it.

If instead you want it standalone because the point gets lost inside
UC1, that is a reason I would accept, and I will write it that way.

On Gap C, the enrollment dependency, Yuning is right that it is
cross-cutting rather than UC1-specific. It sits under every use case
in the catalogue where a key is resolved to a person. If it is
useful I can propose short text for it as a cross-cutting concern
rather than attached to any single use case.

Mohamad