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
<[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
<[email protected] [mailto:[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 <[email protected]
[mailto:[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/
[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] [mailto:[email protected]] To unsubscribe send an email to
[email protected] [mailto:[email protected]]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
