Change:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL

Discussion:
cryptographic tokens that prove nothing other than that they have been created by a given server in the past ARCHITECTURE. <del> This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </del> <ins> This document describes the issuance protocol for Privacy Pass built on HTTP.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks.

The values "token_input" and "blinded_element" are stored locally and used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the <del> TokenRequest as the body.  The media type for this request is </del> <ins> TokenRequest as the content.  The media type for this request is </ins> "application/private-token-request".  An example request is shown below.

"concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))", where Ns is as defined in OPRF, Section 4. <del> The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "application/ private-token-response". </del> <ins> The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </ins> 5.3. Upon receipt, the Client handles the response and, if successful, <del> deserializes the body values TokenResponse.evaluate_msg and </del> <ins> deserializes the content values TokenResponse.evaluate_msg and </ins> TokenResponse.evaluate_proof, yielding "evaluated_element" and "proof".  If deserialization of either value fails, the Client aborts the protocol.  Otherwise, the Client processes the response as

"blinded_msg" is the Nk-octet request defined above. The Client then generates an HTTP POST request to send to the Issuer, <del> with the TokenRequest as the body.  The media type for this request is "application/private-token-request".  An example request is shown below, where Nk = 512. </del> <ins> with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below, where Nk = 512. </ins> Upon receipt of the request, the Issuer validates the following conditions:

The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of TokenResponse, with the content type set as "application/private-token-response". </del> <ins> code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </ins> 6.3. Upon receipt, the Client handles the response and, if successful, <del> processes the body as follows: </del> <ins> processes the content as follows: </ins> The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in