On Sun, May 10, 2026 at 1:23 PM Mohamad Khalil Yossif <[email protected]> wrote:
> 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. > We are in the process of updating this specific bullet to the following: > Developing new mechanisms or/and extensions for authorization of automated > agents working on behalf of users, including addressing scenarios where > automated agents act across multiple administrative domains. > 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 have not read your draft, but have you looked at RFC9470? https://datatracker.ietf.org/doc/rfc9470/ Is this somehow related to the ideas you describe in your draft? Regards, Rifaat 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: > > 1. 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? > 2. 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, > > [image: Mohamad Khalil Yossif] > Mohamad Khalil Yossif > CEO – Yuthent > Founder – FitSnitch, Thesis, SwiftCrew, MK Digital, MK Electronics > [image: Yuthent Logo] > > *T:* +972 50-931-1103 <+972509311103> > *E:* [email protected] > *W:* yuthent.com [image: LinkedIn] > <https://www.linkedin.com/in/mohamad-khalil-yossif-4b9781163/> > > [image: 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 <[email protected]> > wrote: > > > On Thu, May 7, 2026 at 1:21 PM אלעזר פוקס <[email protected]> > 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 < >> [email protected]>: >> >>> 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/ >>> >>> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ OAuth mailing list -- > [email protected] To unsubscribe send an email to [email protected] > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
