[OAUTH-WG] Re: OAuth WG Rechartering

Mohamad Khalil Yossif <mohamad@yuthent.com> Sun, 10 May 2026 17:23 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 01207EC1E6C7 for <oauth@mail2.ietf.org>; Sun, 10 May 2026 10:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778433834; bh=vCxK/oznyqI7W87JTWYb08ZyjjhhnzFUvvrKXiE5iuY=; h=Date:Subject:From:To:Cc:In-Reply-To:References; b=hNcLxrCOOEd176b7JoQ+LknafO8JkP0o3Whl91N0g+BnV3mwBokHIUCt9iGMJapO/ u7zWHceZhr4yFPDYxwuPQGNrZEnjrxG1fSuBVocU+B2ftSHA369epKBsQuA54ywrqs gT7ZTN/ibwV0ouDdgSJ+bw9ADp/20BU4rF4VesgE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 1.239
X-Spam-Level: *
X-Spam-Status: No, score=1.239 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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 jheqCcjwMjaV for <oauth@mail2.ietf.org>; Sun, 10 May 2026 10:23:50 -0700 (PDT)
Received: from out-07.pe-bsn.jellyfish.systems (out-07.pe-bsn.jellyfish.systems [66.29.159.85]) (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 0C2D6EC1E6BE for <oauth@ietf.org>; Sun, 10 May 2026 10:23: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 4gD8pQ6YfLz3hhTF; Sun, 10 May 2026 13:23:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yuthent.com; s=default; t=1778433822; bh=vCxK/oznyqI7W87JTWYb08ZyjjhhnzFUvvrKXiE5iuY=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=FlWdFCycrKnK3DvUUcY1ux/cTRQQJ0qGNtyFuUSm2CBIZKR4ckYs0ud3KOSuwfIOo ubDfn5DfN3fk/WI3l1TWH4PfBmcgrjWBttk0Rxl9etJl//qEeQiWEomRjg7WMWfz8q 3MtJU28Jk8oIFOP7rHIUhmeZ1Wqg0vZD2PZGMkJCO6AQXPWtw9cZEHWWIJY0EZS1Bh k6/njnpjkfoJbjcBbC0aiCU/3mhA2SnaT8GgbBZS9HLBbpJDZMjSR1Q48kpsjMdkri qfzRQmEjSFd/RH1GONvWW4/NlIwXsP14ZiPB5LBzTMM4/7As1GKQ1k8TrHKTfEPz8S Gsp3jRNoXb0Mg==
Received: from mta-08.privateemail.com (localhost [127.0.0.1]) by mta-08.privateemail.com (Postfix) with ESMTP id 4gD8pQ5GcSz3hhVJ; Sun, 10 May 2026 13:23:42 -0400 (EDT)
Received: from [10.0.0.12] (bzq-79-177-155-81.red.bezeqint.net [79.177.155.81]) by mta-08.privateemail.com (Postfix) with ESMTPA; Sun, 10 May 2026 13:23:39 -0400 (EDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_31112105.491966126978"
MIME-Version: 1.0
Date: Sun, 10 May 2026 20:24:18 +0300
Message-ID: <Mailbird-309b89c0-a445-498c-bfe4-38a447cf3fc0@yuthent.com>
From: Mohamad Khalil Yossif <mohamad@yuthent.com>
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, a0504108486@gmail.com
In-Reply-To: <CADNypP_AQZyeXHUyHyGqn-RgESqO+=VxJLAZNq=fHwvhbcyNgg@mail.gmail.com>
References: <CADNypP8hgBo9_d5qaM9E0LZmMKhCcr3=PNW+XyXV3FbATVGcNQ@mail.gmail.com> <CAF+PL0HBQAH=tTHjwdUT+X3Pgs8+fajbzYdWyn_TR6CuMd3yfA@mail.gmail.com> <CADNypP_AQZyeXHUyHyGqn-RgESqO+=VxJLAZNq=fHwvhbcyNgg@mail.gmail.com>
User-Agent: Mailbird/3.0.57.0
X-Mailbird-ID: Mailbird-309b89c0-a445-498c-bfe4-38a447cf3fc0@yuthent.com
X-Virus-Scanned: ClamAV using ClamSMTP
Message-ID-Hash: CLX4ONUD7IUT6WV7GII4VNXC2J7HA4XU
X-Message-ID-Hash: CLX4ONUD7IUT6WV7GII4VNXC2J7HA4XU
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: oauth@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: OAuth WG Rechartering
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vVfe5mutr8KKPyfVi1wGIZmii9c>
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>

Rifaat, Hannes, Deb,
Thanks for the proposed text. The new framing — "as automated agents increasingly act on behalf of users, organizations, or both" — captures an important shift, and I appreciate that the Work Program acknowledges it explicitly under Complex Delegation.
I'd like to ask a scoping question to understand whether a problem space I've been working on falls inside or outside the rechartered scope, before the telechat.
The Complex Delegation bullet is described as "new mechanisms or/and extensions for identity and authorization chaining to address scenarios where automated agents act across multiple administrative domains." My reading is that this is principally about chaining the identity and authorization of workloads as a request traverses domains — i.e., who is acting and under what delegated grant — and that the Coordination section reinforces this by pointing service-to-service and multi-hop workload identity work toward WIMSE.
What is less clear to me is whether the charter intends to cover execution-time authority assurance as a distinct concern: cryptographic evidence, produced at the moment of a sensitive action, that a specific human (not just a valid session or a properly delegated workload) authorized that specific action, with the action payload bound to the proof. This is adjacent to delegation but operates on a different axis — it is not about who holds the token or how authority is chained, but about whether the executing party can prove human authorization at action time, independent of prior session state.
I ask because I authored draft-yossif-psea-01 (Post-Session Execution Assurance), which addresses exactly this gap, and I want to understand whether the natural home for follow-on work in this area is OAuth (under Complex Delegation or a future extension), WIMSE, SPICE, or somewhere else entirely. I am not asking the charter to call this out explicitly — I am asking the chairs and AD how they see the boundary.
Concretely:
* Does Complex Delegation, as currently scoped, contemplate per-action human authorization proofs bound to the action payload, or is it limited to identity/authorization chaining between automated parties?
* If the former is out of scope here, would the chairs see this as WIMSE territory, SPICE territory, or material for a future BoF?
Apologies if this has been discussed in a venue I missed. Happy to take the answer offline if it is more efficient.
Best regards,

[Mohamad Khalil Yossif]
Mohamad Khalil Yossif
CEO – Yuthent
Founder – FitSnitch, Thesis, SwiftCrew, MK Digital, MK Electronics
[Yuthent Logo]
 
T: +972 50-931-1103 [tel:+972509311103]
E: mohamad@yuthent.com [mailto:mohamad@yuthent.com]
W: yuthent.com [https://yuthent.com] [LinkedIn] [https://www.linkedin.com/in/mohamad-khalil-yossif-4b9781163/]
 
[Yuthent – Verify the Human] [https://yuthent.com]
This email may contain confidential or sensitive information. If you are not the intended recipient, any review, use, disclosure, distribution, or copying is prohibited. If you received this message in error, please delete it immediately.
On 10/05/2026 20:07:37, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:


‪On Thu, May 7, 2026 at 1:21 PM ‫אלעזר פוקס‬‎ <a0504108486@gmail.com [mailto:a0504108486@gmail.com]> wrote:‬

Hi Rifaat, Hannes, and Deb,

Thanks for sharing the updated charter. I have a few concrete points regarding boundaries and future scope that might be worth clarifying before the IESG telechat:

1. Coordination with the SPICE WG: Given that the newly formed SPICE WG is also tackling selective disclosure and digital credentials (SD-CWT), it would be helpful if the OAuth charter explicitly defined the coordination mechanisms. We should ensure there's no overlapping work, especially around Metadata and Capability Discovery.


I do not think that this needs to be spelled out in the charter.
We already have people that are active on both WGs, and the chairs of both working groups contact each other when needed.

2. Future of Identity Chaining: With `draft-ietf-oauth-identity-chaining` nearing completion, does the new charter keep the door open for further Workload Identity standardization and chaining extensions, or is this particular scope considered complete for now?


No, this does not close the door for future work on this area, if it makes sense for that work to be at the OAuth WG.

3. Alignment with W3C VCDM 2.0: Since our work on SD-JWT VC is heavily tied to ecosystems like the EU Digital Identity Wallet, should the charter explicitly mention ongoing alignment and maintenance regarding the W3C VCDM 2.0 specifications?


The chairs have close contacts with the EU Wallets initiative with frequent meetings to keep them up to date on the progress we are making on this front.
Why do you think we need to explicitly mention the W3C VCDM 2.0 specifications?

Regards,
Rifaat

Looking forward to the discussion.

Best regards,
Elazar.

‫בתאריך יום ה׳, 7 במאי 2026 ב-19:27 מאת ‪Rifaat Shekh-Yusef‬‏ <‪rifaat.s.ietf@gmail.com [mailto:rifaat.s.ietf@gmail.com]‬‏>:‬

All,

The OAuth WG chairs and the Security AD (Deb) have been collaborating on a proposal to recharter the OAuth WG.
https://datatracker.ietf.org/doc/charter-ietf-oauth/ [https://datatracker.ietf.org/doc/charter-ietf-oauth/]

Deb put this on the agenda of the IESG telechat for My 21st.

Please, take a look and let us know if you have any comments.

Regards,
Rifaat & Hannes



_______________________________________________
OAuth mailing list -- oauth@ietf.org [mailto:oauth@ietf.org]
To unsubscribe send an email to oauth-leave@ietf.org [mailto:oauth-leave@ietf.org]

_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-leave@ietf.org