Change:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.

Discussion:
defined in ARCHITECTURE. Unless otherwise specified, this document encodes protocol messages <del> in TLS notation from TLS13, Section 3.  Moreover, all constants are </del> <ins> in TLS notation from Section 3 of TLS13.  Moreover, all constants are </ins> in network byte order. 3.

(AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. <del> Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key-pair is generated. </del> <ins> This section describes a variant of this issuance protocol for producing privately verifiable tokens using the protocol in OPRF.  In particular, this variant of the issuance protocol uses the OPRF(P-384, SHA-384) ciphersuite. In this variant, Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key-pair is generated. </ins> Clients provide the following as input to the issuance protocol:

6. This section describes a variant of the issuance protocol in private- <del> flow for producing publicly verifiable tokens.  It differs from the previous variant in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </del> <ins> flow for producing publicly verifiable tokens using the protocol in BLINDRSA.  In particular, this variant of the issuance protocol works for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO- Deterministic blind RSA protocol variants described in Section 5 of BLINDRSA. The publicly verifiable issuance protocol differs from the protocol in private-flow in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </ins> Beyond this difference, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance

value "nonce" using the input challenge and Issuer key identifier as follows: <del> The rsabssa_blind function is defined in BLINDRSA, Section 5.1.1.. The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in public-finalize). </del> <ins> The PrepareIdentity and Blind functions are defined in Section 4.1 of BLINDRSA and Section 4.2 of BLINDRSA, respectively.  The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in public-finalize). </ins> The Client then creates a TokenRequest structured as follows:

Client, the Issuer completes the issuance flow by computing a blinded response as follows: <del> This is encoded and transmitted to the client in the following </del> <ins> The BlindSign function is defined in Section 4.3 of BLINDRSA.  The result is encoded and transmitted to the client in the following </ins> TokenResponse structure: <del> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  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". </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> 6.3. Upon receipt, the Client handles the response and, if successful, processes the content as follows: <del> The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in </del> <ins> The Finalize function is defined in Section 4.4 of BLINDRSA.  If this succeeds, the Client then constructs a Token as described in </ins> AUTHSCHEME as follows: The Token.nonce value is that which was sampled in private-request. <del> If the rsabssa_finalize function fails, the Client aborts the protocol. </del> <ins> If the Finalize function fails, the Client aborts the protocol. </ins> 6.4.