Return-Path: 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 ; 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 ; 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 ; 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: From: "Mohamad Khalil Yossif" To: "Rifaat Shekh-Yusef" , "" In-Reply-To: References: 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: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_OAuth_WG_Rechartering?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_NextPart_31112105.491966126978 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rifaat, Hannes, Deb, Thanks for the proposed text. The new framing =E2=80=94 "as automated agent= s increasingly act on behalf of users, organizations, or both" =E2=80=94 ca= ptures an important shift, and I appreciate that the Work Program acknowled= ges 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 th= e telechat. The Complex Delegation bullet is described as "new mechanisms or/and extens= ions for identity and authorization chaining to address scenarios where aut= omated agents act across multiple administrative domains." My reading is th= at this is principally about chaining the identity and authorization of wor= kloads as a request traverses domains =E2=80=94 i.e., who is acting and und= er what delegated grant =E2=80=94 and that the Coordination section reinfor= ces this by pointing service-to-service and multi-hop workload identity wor= k 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, pro= duced 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 del= egation but operates on a different axis =E2=80=94 it is not about who hold= s the token or how authority is chained, but about whether the executing pa= rty can prove human authorization at action time, independent of prior sess= ion state. I ask because I authored draft-yossif-psea-01 (Post-Session Execution Assur= ance), which addresses exactly this gap, and I want to understand whether t= he natural home for follow-on work in this area is OAuth (under Complex Del= egation or a future extension), WIMSE, SPICE, or somewhere else entirely. I= am not asking the charter to call this out explicitly =E2=80=94 I am askin= g the chairs and AD how they see the boundary. Concretely: * Does Complex Delegation, as currently scoped, contemplate per-action huma= n authorization proofs bound to the action payload, or is it limited to ide= ntity/authorization chaining between automated parties? * If the former is out of scope here, would the chairs see this as WIMSE te= rritory, 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 =E2=80=93 Yuthent Founder =E2=80=93 FitSnitch, Thesis, SwiftCrew, MK Digital, MK Electronics [Yuthent Logo] =C2=A0 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/i= n/mohamad-khalil-yossif-4b9781163/] =C2=A0 [Yuthent =E2=80=93 Verify the Human] [https://yuthent.com] This email may contain confidential or sensitive information. If you are no= t the intended recipient, any review, use, disclosure, distribution, or cop= ying is prohibited. If you received this message in error, please delete it= immediately. On 10/05/2026 20:07:37, Rifaat Shekh-Yusef wrote: =E2=80=AAOn Thu, May 7, 2026 at 1:21 PM =E2=80=AB=D7=90=D7=9C=D7=A2=D7=96= =D7=A8 =D7=A4=D7=95=D7=A7=D7=A1=E2=80=AC=E2=80=8E wrote:=E2=80=AC Hi Rifaat, Hannes, and Deb, Thanks for sharing the updated charter. I have a few concrete points regard= ing boundaries and future scope that might be worth clarifying before the I= ESG 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 wou= ld be helpful if the OAuth charter explicitly defined the coordination mech= anisms. We should ensure there's no overlapping work, especially around Met= adata 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` n= earing completion, does the new charter keep the door open for further Work= load Identity standardization and chaining extensions, or is this particula= r 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 expl= icitly 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 fro= nt. Why do you think we need to explicitly mention the W3C VCDM 2.0 specificati= ons? Regards, Rifaat Looking forward to the discussion. Best regards, Elazar. =E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=94=D7= =B3, 7 =D7=91=D7=9E=D7=90=D7=99 2026 =D7=91-19:27 =D7=9E=D7=90=D7=AA =E2=80= =AARifaat Shekh-Yusef=E2=80=AC=E2=80=8F <=E2=80=AArifaat.s.ietf@gmail.com [= mailto:rifaat.s.ietf@gmail.com]=E2=80=AC=E2=80=8F>:=E2=80=AC 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.i= etf.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@ie= tf.org] _______________________________________________ OAuth mailing list -- oauth= @ietf.org To unsubscribe send an email to oauth-leave@ietf.org ------=_NextPart_31112105.491966126978 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Rifaat, Hannes, Deb,

Thanks for the proposed text. The new framing =E2=80=94 "as aut= omated agents increasingly act on behalf of users, organizations, or both"<= /em> =E2=80=94 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, b= efore the telechat.

The Complex Delegation bullet is described as "new mechanisms o= r/and extensions for identity and authorization chaining to address scenari= os 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 =E2= =80=94 i.e., who is acting and under what delegated grant =E2=80=94 and tha= t the Coordination section reinforces this by pointing service-to-service a= nd 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: cr= yptographic 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 =E2=80=94= 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 Execut= ion 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 Co= mplex Delegation or a future extension), WIMSE, SPICE, or somewhere else en= tirely. I am not asking the charter to call this out explicitly =E2=80=94 I= am asking the chairs and AD how they see the boundary.

Concretely:

  1. = Does Complex Delegation, as currently scoped, contemplate per-action human = authorization proofs bound to the action payload, or is it limited to ident= ity/authorization chaining between automated parties?
  2. = If the former is out of scope here, would the chairs see this as WIMSE terr= itory, 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,


3D"Mohamad
Mohamad Khalil Yossif
CEO =E2=80=93 Yuthent
Founder =E2=80=93 FitSnitch, Thesis, SwiftCrew, = MK Digital, MK Electronics
3D"Yuthent
 
T: +972 50-931-1103
E: mohamad@yuthen= t.com
W: yuthent.com 		3D"LinkedIn"
 
3D"Yuthent
This email may contain confidential or sensitive informatio= n. If you are not the intended recipient, any review, use, disclosure, dist= ribution, or copying is prohibited. If you received this message in error, = please delete it immediately.

On 1= 0/05/2026 20:07:37, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrot= e:



=E2=80=AAOn Thu, Ma= y 7, 2026 at 1:21=E2=80=AFPM =E2=80=AB=D7=90=D7=9C=D7=A2=D7=96=D7=A8 =D7=A4= =D7=95=D7=A7=D7=A1=E2=80=AC=E2=80=8E <a0504108486@gmail.com> wrote:=E2=80=AC
Hi Rifaat, Hannes, an= d Deb,

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

1. Coordination with the SPICE WG: Given= that the newly formed SPICE WG is also tackling selective disclosure and d= igital credentials (SD-CWT), it would be helpful if the OAuth charter expli= citly defined the coordination mechanisms. We should ensure there's no = overlapping work, especially around Metadata and Capability Discovery.
<= br>
I do not think that this needs to be spelled out= in the charter.
We already have people that are active on both W= Gs, and the chairs of both working groups contact each other when needed.

=C2=A0
2. Future of Identity Chaining: With `draft-iet= f-oauth-identity-chaining` nearing completion, does the new charter keep th= e door open for further Workload Identity standardization and chaining exte= nsions, or is this particular scope considered complete for now?

No, this does not close the door for future work on th= is area, if it makes sense for that work to be at the OAuth WG.
<= br>
=C2=A0
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, shoul= d the charter explicitly mention ongoing alignment and maintenance regardin= g the W3C VCDM 2.0 specifications?

The chair= s 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=C2=A0mention the=C2=A0W3C VCDM = 2.0 specifications?

Regards,
=C2=A0Rifaa= t

=C2=A0
Looking forward to the discussion.

Be= st regards,
Elazar.

=E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99= =D7=95=D7=9D =D7=94=D7=B3, 7 =D7=91=D7=9E=D7=90=D7=99 2026 =D7=91-19:27 =D7= =9E=D7=90=D7=AA =E2=80=AARifaat Shekh-Yusef=E2=80=AC=E2=80=8F <=E2=80=AA= rifaat.s.ietf@= gmail.com=E2=80=AC=E2=80=8F>:=E2=80=AC
All,
The OAuth WG chairs and the Security AD (Deb) have been collab= orating on a proposal to recharter the OAuth WG.

D= eb put this on the agenda of the IESG telechat for My 21st.

Please, take a look and let us know if you have any commen= ts.

Regards,
=C2=A0Rifaat & Hannes



_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-leave@ietf.org
------=_NextPart_31112105.491966126978--