>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]
