Original text:
If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step-redemption and <del> redeem its token.  Otherwise, it invokes the issuance protocol to request a token from the designated Issuer. The first step in the issuance protocol is attestation. Specifically, the Attester performs attestation checks on the Client.  These checks could be proof of solving a CAPTCHA, device trust, hardware attestation, etc (see attester). If attestation succeeds, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the details of Attestation, the Client can send the Token Request to the Attester alongside any attestation information.  If attestation fails, the Client receives an error and issuance aborts without a token. </del>  The Issuer generates a Token Response based on the Token Request, which is returned to the Client (generally via the Attester).

Reviewer comments:
The issuance overview step 3 says that the Client and Attester interact to do whatever is necessary to convince the Attester to attest. But there doesn't seem to be any pretext for this process to be initiated. Step 4 says that the client requests issuance (via the Attester), which would provide the necessary cause to start the attesting process. Should these steps be swapped?
Either the attester is an intermediary to the flow (which is what we're doing in practice), or it is a separate flow. So the prerequisite is that the client knows it wants to request a token from an issuer, and then it does attestation.
Perhaps this could be made more clear if we say that the client, upon deciding it wants to invoke the issuance protocol, then begins the deployment-specific attestation process with its trusted attester? I can suggest some text for this.

Revised text:
If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step-redemption and  <ins> redeem its token. If the Client does not have a token available and decides it wants to obtain one (or more) bound to the token challenge, it then invokes the issuance protocol.  As a prerequisite to the issuance protocol, the Client runs the deployment specific attestation process that is required for the designated Issuer.  Client attestation can be done via proof of solving a CAPTCHA, checking device or hardware attestation validity, etc; see attester for more details. If the attestation process completes successfully, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the attestation process, it is possible for attestation to run alongside the issuance protocol, e.g., where Clients send necessary attestation information to the Attester along with their Token Request.  If the attestation process fails, the Client receives an error and issuance aborts without a token. </ins> The Issuer generates a Token Response based on the Token Request, which is returned to the Client (generally via the Attester).