Original text:
type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, token-types. Challenges with unsupported token_type values MUST be ignored.  "issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed The structure fields are defined as follows: "token_type" is a 2-octet integer, in network byte order.  This <del> value must match the value in the challenge (challenge). </del>  "nonce" is a 32-octet message containing a client-generated random nonce. Name: Name of the issuance protocol  Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable Name: Private Use  Publicly Verifiable: N/A Public Metadata: N/A Name: VOPRF (P-384, SHA-384)  Publicly Verifiable: N Public Metadata: N Name: Blind RSA (2048-bit)  Publicly Verifiable: Y Public Metadata: N The Privacy Pass architecture consists of four logical entities - Client, Origin, Issuer, and Attester - that work in concert for token redemption and issuance.  This section describes the purpose of token <del> redemption and issuance and the requirements on the relevant participants. </del>  The typical interaction flow for Privacy Pass uses the following steps: opportunistically present Token values to Origins without a corresponding TokenChallenge.  The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept in the redemption context.  There are a number of ways in which the token redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below.  Clients interact with the Attester and Issuer to produce a token in response to a challenge.  The context in which an Attester vouches for a Client during issuance is referred to as the attestation

Reviewer comments:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.

Revised text:
type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, token-types. Challenges with unsupported token_type values MUST be ignored. <ins> This value determines the structure and semantics of the rest of the structure. </ins> "issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed The structure fields are defined as follows: "token_type" is a 2-octet integer, in network byte order.  This  <ins> value must match the value in the challenge (challenge).  This value determines the structure and semantics of the rest of the structure. </ins> "nonce" is a 32-octet message containing a client-generated random nonce. Name: Name of the issuance protocol <ins> Token Structure: The contents of the Token structure TokenChallenge Structure: The contents of the TokenChallenge structure </ins> Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable Name: Private Use <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: N/A Public Metadata: N/A Name: VOPRF (P-384, SHA-384) <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: N Public Metadata: N Name: Blind RSA (2048-bit) <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: Y Public Metadata: N The Privacy Pass architecture consists of four logical entities - Client, Origin, Issuer, and Attester - that work in concert for token redemption and issuance.  This section describes the purpose of token  <ins> the redemption and issuance protocols and the requirements on the relevant participants. </ins> The typical interaction flow for Privacy Pass uses the following steps: opportunistically present Token values to Origins without a corresponding TokenChallenge. <ins> The structure and semantics of the TokenChallenge and Token messages depend on the issuance protocol and token type being used; see AUTHSCHEME for more information. </ins> The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept in the redemption context.  There are a number of ways in which the token redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. <ins> The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; see ISSUANCE for more information. </ins> Clients interact with the Attester and Issuer to produce a token in response to a challenge.  The context in which an Attester vouches for a Client during issuance is referred to as the attestation