Refine requirements for different type of challenges

[ju-cu]

There are two type of challenges:

• Challenges that provide evidence of the client's provenance (e.g., attestation artifacts)
• Challenges that provide evidence of the client's authorization to request access (e.g., a mandate)

Those two types have different threat models that reflect the challenge session.

Feedback from Mohamad Khalil-Yossif on the oauth mailing list (targeting -00):

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.

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.