Hi Mohamad! I have some ideas for the challenge type that I will write down. If you have some input that helps to shape and formalize the example in Appendix A, I am more than happy for your contribution. I also think, it's a good first use case that is not covered by other work in the community yet. Interest is exactly what I was looking for :) Feel free to share your thoughts here on the mailing list (to spark other's interest?), in a personal mail to me or comment on this issue ( https://github.com/curityio/ietf-draft-oauth-client-challenge-protocol/issues/2 ). Let's keep the discussion going!
I'll get back when I have incorporated your feedback and updated the draft. Regards, Judith On Sat, Jun 13, 2026 at 8:16 AM Mohamad Khalil-Yossif <mohamad= [email protected]> wrote: > > Hi Judith, > > Thank you for the careful responses. The plan to keep both evidence > classes in scope and discuss the implications works, provided the type > profiles carry the per-class requirements (binding, freshness, producer) > rather than the framework, which your answer to point 4 already covers. > > On your question about what kind of challenges there should be: I would > argue the first registry entry should be an action-authorization evidence > type. Client attestation already has a home in the WG > (attestation-based-client-auth, and the recent attestation-authz-native-app > individual draft), so a first entry there would duplicate existing work. > What has no home today is the case your own Appendix A example describes: > evidence of a human decision about a specific action, bound to the action > parameters, with a freshness window measured against execution rather than > issuance. Defining that as the first type would also give the registry its > hardest test case, since it forces the binding and freshness machinery to > be real. > > For disclosure, this is the problem class I work on (draft-yossif-psea, > plus a survey on authorization evidence for high-risk actions currently > with the SECDISPATCH chairs), so I have an obvious interest here. With that > on the table: when you revise, I would be glad to contribute a candidate > type definition for that class for you to accept, modify, or reject. > > On 12/06/2026 17:43:54, Judith Kahrer <judith.kahrer= > [email protected]> wrote: > Thank you Mohamad for your feedback!.It is very valuable! > > You find my individual statements inline below. > > Regards, > Judith > > On Fri, Jun 12, 2026 at 10:48 AM Mohamad Khalil-Yossif <mohamad= > [email protected]> wrote: > >> Hi Judith, >> >> I read the draft. The mechanism is useful. The extensible >> challenge-response pattern at the token endpoint fills a real gap. RFC 6749 >> has no way for the AS to say "resolvable, but I need more." Some feedback: >> >> 1. Client authorization vs. action authorization. Section 1.2 states the >> client satisfies the challenge itself, without end-user interaction. But >> the Appendix A example challenges a specific payment initiation with a >> verifiable intent presentation. That is not evidence about client >> provenance or capability. It is evidence about a human decision regarding a >> specific action. The draft currently carries both without distinguishing >> them. I would make the scope explicit: either limit >> authorization_requirement to client-level material (attestation, >> provenance), or acknowledge that the mechanism is also a transport for >> action-level authorization evidence and define what that implies >> (freshness, binding to the action parameters, who produced the evidence). >> The two evidence classes have different threat models. >> >> > Judith: I don't think the framework should distinguish between > "client-level material" (like attestation, provenance) and "action-level > authorization". I will call that out specifically and add a short > discussion on the implications. > > 2. Issuance-time vs. execution-time. A challenge satisfied at the token >> endpoint proves a condition at issuance. The token then lives, and for the >> risk-driven cases in 1.1 (elevated threat signals, high-value operations) >> the condition can change before the action executes. It would help to >> position the draft against RFC 9470, which handles step-up at the resource >> server. They look complementary: 9470 covers the user/acr dimension at the >> RS, this covers the client/evidence dimension at the AS. Saying so would >> preempt confusion. >> > > Judith: Very good point. Thank you! > > >> 3. authorization_requirement.type has no registry. Section 9 registers >> the parameter, the error code, and the client metadata, but not the type >> values. Without a registry, profiles will fragment into vendor-specific >> types and interoperability degrades to bilateral agreements. I would >> establish an IANA registry with a specification-required policy. >> >> Judith: You're right, I didn't include a registry. I probably should for > interoperability. I think, in the next step a first entry would be good to > have as well - the reason for my question regarding what kind of challenges > there should be. :) > > 4. Binding and freshness for high-value types. challenge_session binding >> is SHOULD (8.2) and expires_in is OPTIONAL. For exactly the high-risk cases >> that motivate the draft, an unbound, non-expiring challenge session is a >> replay surface. I would require each type profile to mandate sender-binding >> and a freshness window appropriate to its risk class, rather than leaving >> both optional at the framework level. >> >> > Judith: Makes sense, thanks for pointing it out! > > >> 5. On 403 vs. 401: I agree with your conclusion. 401 plus >> WWW-Authenticate would force challenges into HTTP authentication scheme >> semantics, and 401 already carries RFC 9470 step-up semantics at the RS. >> 403 with a structured body keeps the layers separate. >> >> > Judith: Thanks for confirming! Glad to hear my conclusion resonates. > > >> >> Mohamad Khalil Yossif >> Author, draft-yossif-psea >> >> On 12/06/2026 11:14:23, Judith Kahrer <judith.kahrer= >> [email protected]> wrote: >> Dear working group, >> >> Some weeks ago I shared a link to a draft that I called the OAuth Client >> Challenge Protocol. >> >> https://datatracker.ietf.org/doc/draft-kahrer-oauth-client-challenge-protocol/ >> >> I would very much appreciate some more and honest feedback on the >> proposal. >> >> - What are your thoughts about conditional access control for clients? >> Have you seen (or expect to see) a need for it in your work? >> - Do you find the proposal useful in that context? >> - Have you done, used or seen something similar in the past? >> - What kind (type) of challenge do you think are needed or most useful? >> - What would you change in the proposed protocol? >> >> I have considered returning a 401 HTTP code in the token response for a >> while but came to the conclusion that it would actually limit the kind of >> challenges the authorization server can request from the client because it >> would require an HTTP authentication scheme in the WWW-Authenticate header. >> Therefore, I think, HTTP 403 fits best. >> >> Looking forward to some discussions! >> - Judith >> _______________________________________________ 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]
