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]
