Mike's framing on statefulness is the right one. Overloading the token endpoint with per-challenge session state carries the costs he lists: cross-cluster replication, replay exposure for public clients, and low odds of adoption by large IdPs. The ROPW precedent is a fair warning.
Two concerns are getting collapsed here, and the state cost attaches to only one of them. The first is signaling: how the AS tells the client what additional evidence is required. The second is the evidence itself: what the client returns, and how the AS validates it. The statefulness worry is about correlating a challenge to a later response, and about replay. Both can be handled without a persisted challenge session. Signaling can be a stateless signed challenge. The AS returns a short-lived token carrying the nonce, the policy hints, and an expiry, signed by the AS. Nothing is persisted. This follows the instinct in Mike's own examples, UMA permission tickets and AAuth, where the hints ride in a resource-first artifact rather than in endpoint state. The response can be a self-contained evidence artifact whose binding covers the request. If the artifact binds to the payload hash, to the client key, and to the challenge it answers, replay is handled inside the artifact rather than by server-side session. Evidence for action X does not validate action Y. A captured artifact does not replay under a different key. Freshness comes from the echoed challenge and its expiry. That yields challenge and response semantics, plus replay protection, with a stateless token endpoint. The state is externalized into two signed objects instead of held and replicated at the AS. If strict one-time-use is required rather than a bounded window, that reduces to a short-lived jti cache, a smaller and simpler state requirement than a persisted, correlated challenge session. One case is worth naming. The high-risk-action examples in the draft assume the required evidence is about the client. There is a second class where the required evidence is human approval bound to the specific action, the human-in-seat case, which does not reduce to client attestation. I have been working on an EAT-based profile for exactly that in draft-yossif-psea. It slots into the response side above as one evidence type, not a new grant. Glad to work through where a per-action human-approval type would register against Judith's mechanism. Mohamad Khalil Yossif > On 2 Jul 2026, at 23:09, Michael Schwartz <[email protected]> > wrote: > > g > l > u > u _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
