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.
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.
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.
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.
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.
Mohamad Khalil Yossif
Author, draft-yossif-psea
On 12/06/2026 11:14:23, 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/
[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]
