I have made that update to the Complex Delegation bullet. The update can be found here: https://datatracker.ietf.org/doc/charter-ietf-oauth/
Apologies for the delay. Deb Cooley Sec AD On Sun, May 10, 2026 at 10:45 PM Rifaat Shekh-Yusef <[email protected]> wrote: > From your description and from skimming your draft, the problem seems to > be in scope of the OAuth WG even before the rechartering. > Having said that, your document is not a specification; is your plan to > submit a proposed specification to address all these objectives? > > Regardless, let's take this off this thread, which is focused on the > charter. > > Regards, > Rifaat > > > > On Sun, May 10, 2026 at 2:48 PM Mohamad Khalil Yossif <[email protected]> > wrote: > >> >> Rifaat, >> >> Thanks - and I appreciate the proposed wording change. The shift from >> "identity and authorization chaining" to "authorization of automated >> agents working on behalf of users" is meaningful; it broadens the bullet >> from inter-workload chaining to user-authorization for agent actions, >> which is the harder problem. >> >> On RFC 9470: yes, I've read it, and it's the closest neighbor in the >> OAuth family to what draft-yossif-psea-01 addresses - but I think they >> sit on different axes. Let me try to make the distinction precise. >> >> RFC 9470 lets a resource server signal that the authentication event >> behind the current access token is insufficient - too weak (acr_values) >> or too old (max_age) - and triggers re-authentication that produces a >> new token carrying updated acr and auth_time claims. The model assumes >> an active session, the AS performs the authentication, and the resulting >> evidence is encoded as claims inside the token. >> >> PSEA addresses a related but separate property: cryptographic proof, >> generated at the moment of action, that a specific enrolled human >> authorized that specific action with that specific payload - where >> "specific enrolled human" means the biometric template registered for >> this account at enrollment, not "someone who passed UV on this device". >> The proof is bound to the action canonical form (amount, recipient, >> dosage, etc.), produced inside the user's device hardware (Secure >> Enclave / StrongBox), and verifiable independently of session state. >> >> The practical differences I see: >> >> 1. Binding axis. 9470 binds an authentication event to a token. PSEA >> binds a specific-human authorization event to a canonical action >> payload. A 9470-step-up token, once issued, can authorize N >> subsequent actions the user never saw; PSEA evidence is per-action >> and per-specific-human. >> >> 2. Session dependency. 9470 explicitly assumes an active session and >> an available AS at authentication time. PSEA is designed to operate >> post-session and, in some tiers, offline - with verification >> finalized server-side later - for environments where AS reachability >> cannot be assumed at action time (regulated workforce, healthcare >> dispensing, agentic execution under intermittent connectivity). >> >> 3. Audit persistence. PSEA evidence is constructed so that the proof >> of who authorized what survives independently of session and AS >> state - relevant to regulated regimes such as PSD2 SCA dynamic >> linking and eIDAS, which require per-transaction authorization >> evidence linked to amount and payee, retained for audit. >> >> 4. Trust root. In 9470, the AS is the authority that attests >> authentication occurred. In PSEA, the proof originates from the >> user's device hardware and is verified against device-trust state. >> The AS, if present, finalizes - it does not produce the >> human-authorization evidence. >> >> 5. Replay surface. A 9470 token is still a bearer credential within >> its acr context; a captured token can authorize unintended actions >> within scope. PSEA evidence is action-scoped by construction - >> capture of one proof yields no leverage on a different action. >> >> I am not claiming 9470 is deficient - for its problem (session-strength >> signaling) it works well. The question is whether the rechartered >> Complex Delegation bullet, in its new wording, is intended to also >> accommodate per-action human-authorization evidence as a distinct >> mechanism, or whether that should be pursued elsewhere (WIMSE, SPICE, >> a future BoF). >> >> Happy to take the technical comparison off-list if that's more useful >> than continuing on the charter thread. >> >> Best regards, >> >> [image: Mohamad Khalil Yossif, Founder & CEO of Yuthent] >> Mohamad Khalil Yossif >> Founder & CEO · Yuthent >> PSEA Spec Author · IETF draft-yossif-psea >> [image: Yuthent — Execution Authority Infrastructure] >> >> *T:* +972 50-931-1103 <+972509311103> >> *E:* [email protected] >> *W:* yuthent.com [image: LinkedIn] >> <https://www.linkedin.com/in/mohamadkhalilyossif> >> >> [image: Yuthent — Cryptographic proof of human authorization at execution >> time] <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:55:57, Rifaat Shekh-Yusef <[email protected]> >> wrote: >> >> >> 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
