Change:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME

Discussion:
"info". Given this configuration and these inputs, the two messages exchanged <del> in this protocol are described below. </del> <ins> in this protocol are described below.  This section uses notation described in OPRF, Section 4, including SerializeElement and DeserializeElement, SerializeScalar and DeserializeScalar, and DeriveKeyPair. </ins> 3.1. <del> The Client first creates a verifiable context as follows: </del> <ins> The Client first creates a context as follows: </ins> Here, 0x0004 is the two-octet identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite in OPRF.

value "nonce" using the input challenge and Issuer key identifier as follows: <del> The Client then creates a TokenRequest structured as follows: </del> <ins> If the Blind step fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows: </ins> The structure fields are defined as follows:

"token_key_id" is the least significant byte of the "key_id". <del> "blinded_msg" is the Nk-octet request defined above. </del> <ins> "blinded_request" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_msg)".  Ne is as defined in OPRF, Section 4. </ins> <del> The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below, where Nk = 48. </del> <ins> The value "tweaked_key" is stored locally and used later as described in finalization.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions: <del> The TokenRequest contains a supported token_type </del> <ins> The TokenRequest contains a supported token_type. </ins> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. <del> The TokenRequest.blinded_msg is of the correct size </del> <ins> The TokenRequest.blinded_msg is of the correct size. </ins> If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client.

The Issuer then creates a TokenResponse structured as follows: <del> The structure fields "evaluated_msg" and "proof" are as computed above, where Ns is as defined in OPRF, Section 4. </del> <ins> The structure fields are defined as follows: "evaluate_response" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluated_msg)". "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as "concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))", where Ns is as defined in OPRF, Section 4. </ins> The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/

3.3. Upon receipt, the Client handles the response and, if successful, <del> processes the body as follows: </del> <ins> deserializes the body values TokenResponse.evaluate_response and TokenResponse.evaluate_proof.  If deserialization of any value fails, the Client aborts the protocol.  Otherwise, when deserialization yields "evaluated_msg" and "proof", the Client processes the response as follows: </ins> If this succeeds, the Client then constructs a Token as follows: