[OAUTH-WG] Re: OAuth WG Rechartering

[Mohamad Khalil Yossif <[e-mail]>]

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,

[Mohamad Khalil Yossif, Founder & CEO of Yuthent]
Mohamad Khalil Yossif
Founder & CEO · Yuthent
PSEA Spec Author · IETF draft-yossif-psea
[Yuthent — Execution Authority Infrastructure]
 
T: [phone] [tel:[phone]]
E: [e-mail] [mailto:[e-mail]]
W: yuthent.com [https://yuthent.com] [LinkedIn] [https://www.linkedin.com/in/mohamadkhalilyossif]
 
[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 <[e-mail]> wrote:


On Sun, May 10, 2026 at 1:23 PM Mohamad Khalil Yossif <[e-mail] [mailto:[e-mail]]> 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/ [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:
* 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: [phone] [tel:[phone]]
E: [e-mail] [mailto:[e-mail]]
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 <[e-mail] [mailto:[e-mail]]> wrote:


‪On Thu, May 7, 2026 at 1:21 PM ‫אלעזר פוקס‬‎ <[e-mail] [mailto:[e-mail]]> 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‬‏ <‪[e-mail] [mailto:[e-mail]]‬‏>:‬

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 -- [e-mail] [mailto:[e-mail]]
To unsubscribe send an email to [e-mail] [mailto:[e-mail]]

_______________________________________________ OAuth mailing list -- [e-mail] [mailto:[e-mail]] To unsubscribe send an email to [e-mail] [mailto:[e-mail]]