Judith, Agree the token endpoint is the right interposition point, for a structural reason worth making explicit: it is the one place every grant type passes through. Authorization code, refresh, client credentials, and the identity assertion grant Yaron referenced all converge there. A challenge mechanism defined at the token endpoint is grant-agnostic by construction, which matters for agentic flows that lean on refresh and assertion grants.
On placement within the exchange: I would put the challenge in a token endpoint error response rather than a success response. A new error code, say additional_evidence_required, with the signed challenge object carried as a response parameter. The client retries the same grant with the evidence artifact attached as a request parameter. This has precedent on both sides. The device authorization grant already runs a challenge-and-retry loop at the token endpoint with authorization_pending, so large IdPs have deployed this interaction shape. And RFC 9470 established challenge-for-additional-evidence semantics at the resource server. This mechanism would be its AS-side complement rather than a new pattern. The challenge object then needs one structural decision: it should declare required evidence by type, with types held in a registry rather than fixed in the mechanism. Client attestation is one type. Per-action human approval is another. That separation keeps your mechanism stable while evidence types evolve independently. Happy to write up a strawman of the challenge object claims and the evidence-type registry structure if that would be useful. Regards, Mohamad Khalil Yossif > On 3 Jul 2026, at 13:08, Judith Kahrer > <[email protected]> wrote: > > Hi Mike and Mohamad! > > You're both right. I haven't thought the implication of the challenge session > through properly. I think, the token endpoint (or token response, more > specifically), is the right point to introduce the challenge behavior, > though, even if it adds just another capability to the already overloaded > token endpoint. I like the idea of a stateless, signed challenge with a nonce > that is bound to the request. Something similar crossed my mind before... > Thanks Mohamad! > > /Judith > > On Fri, Jul 3, 2026 at 11:00 AM Khalil-Yossif, Mohamad > <[email protected]> wrote: > 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] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
