A client should be able to request a challenge without using a challenge endpoint

[Denisthemalice]

In section 12.1. (Replay Attacks), two ways are proposed to manage challenges:

• The Authorization Server provides a challenge as an OAuth-Client-
  Attestation-Challenge in the challenge endpoint to the Client
  Instance ...

or

• The Authorization Server generates a challenge that is bound to
  the Client Instance's session, such that a specific challenge in
  the Client Attestation PoP JWT is expected and validated.

These two cases are indeed possible but the management of them is quite different.

In the second case, the text states:

• (...) The Authorization Server may either:

  • send the challenge as part of another previous response to the
    Client Instance of providing the challenge explicitly

  • reuse an existing artefact of the Client Instance's session,
    e.g. the authorization code. This MUST be communicated out-of-
    band between Authorization Server and Client.

It is doubtful that the second case which is too vaguely defined can be implemented in an interoperable way (i.e., by only reading this document). Therefore, I would remove that second case.

Presently, no use case allows a client, within a session, to request a challenge to the AS. This possibility should be added as it allows to split the list into small parts.

As a side effect, the following sentence in section 8 will need to be reconsidered:

If the Authorization Server offers a challenge endpoint, the Client
MUST retrieve a challenge and MUST use this challenge in the OAuth-
Attestation-PoP as defined in Section 5.2.

If it becomes possible to request a challenge to the AS within a session, it should be questioned whether the ability to obtain a challenge using a challenge endpoint should be kept.