Change:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!

Discussion:
Issuer name, identifying the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. <del> Issuer Public Key pkI, with a key identifier "key_id" computed as described in issuer-configuration. </del> <ins> Issuer Public Key pkI, with a key identifier "token_key_id" computed as described in issuer-configuration. </ins> Challenge value "challenge", an opaque byte string.  For example, this might be provided by the redemption protocol in HTTP-

"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </del> <ins> "truncated_token_key_id" is the least significant byte of the "token_key_id" in network byte order (in other words, the last 8 bits of "token_key_id"). </ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined

The TokenRequest contains a supported token_type. <del> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. </del> <ins> The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of a Public Key owned by the issuer. </ins> The TokenRequest.blinded_request is of the correct size.

denoted skI and pkI, respectively, used to produce tokens.  Each key pair MUST be generated as follows: <del> The key identifier for this specific key pair, denoted "key_id", is computed as follows: </del> <ins> The key identifier for this specific key pair, denoted "token_key_id", is computed as follows: Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation. </ins> 6.

Issuer name, identifying the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. <del> Issuer Public Key pkI, with a key identifier "key_id" computed as described in public-issuer-configuration. </del> <ins> Issuer Public Key pkI, with a key identifier "token_key_id" computed as described in public-issuer-configuration. </ins> Challenge value "challenge", an opaque byte string.  For example, this might be provided by the redemption protocol in HTTP-

"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </del> <ins> "truncated_token_key_id" is the least significant byte of the "token_key_id" in network byte order (in other words, the last 8 bits of "token_key_id"). </ins> "blinded_msg" is the Nk-octet request defined above.

The TokenRequest contains a supported token_type. <del> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. </del> <ins> The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of a Public Key owned by the issuer. </ins> The TokenRequest.blinded_msg is of the correct size.

denoted skI and pkI, respectively, used to produce tokens.  Each key pair SHALL be generated as as specified in FIPS 186-4 DSS. <del> The key identifier for a keypair (skI, pkI), denoted "key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash </del> <ins> The key identifier for a keypair (skI, pkI), denoted "token_key_id", is computed as SHA256(encoded_key), where encoded_key is a DER- encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash </ins> algorithm and salt size.  The salt size MUST match the output size of the hash function associated with the public key and token type. <ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation. </ins> 7. This document outlines how to instantiate the Issuance protocol based <del> on the VOPRF defined in OPRF and blind RSA protocol defnied in BLINDRSA.  All security considerations described in the VOPRF document also apply in the Privacy Pass use-case.  Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the Architecture document I- D.ietf-privacypass-architecture. </del> <ins> on the VOPRF defined in OPRF and blind RSA protocol defined in BLINDRSA.  All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the Architecture document I-D.ietf-privacypass-architecture. Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This is done to minimize the chance that an Issuer can use distinct keys for targeting specific users.  Since the key ID is truncated to a single byte, an Issuer can partition the set of Clients into at most 256 different anonymity sets.  On top of this key ID space, Clients SHOULD apply some form of key consistency mechanism to help ensure they are not being given unique keys; see CONSISTENCY for more details. </ins> 8.