]> Phoenix R&D

ietf@raphaelrobert.com

Cloudflare

caw@heapingbits.net

Cloudflare Inc.

ot-ietf@thibault.uk

Internet-Draft This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time.

Change Log: RFC EDITOR PLEASE DELETE THIS SECTION. draft-08

• Fix indentation
• Add pkS as an argument in BlindEvaluateBatch function definition

draft-07

• Add some precision on linear cost of amortized batched tokens

draft-06

• Address various review comments

draft-05

• Address various review comments

draft-04

• Rename the issuance variants
• Clarify media types
• Make generic issuance more generic byt prefixing requests & responses with token type

draft-03

• Arbitrary token types
• Error code 400 aligned with RFC9578 and replaced by error code 422

draft-02

• Renaming TokenRequest to BatchTokenRequest and TokenResponse to BatchTokenResponse
• IANA: Media types for BatchTokenRequest and BatchTokenResponse
• IANA: Expand Token Type registry entry
• Various editorial fixes

draft-01

• Initial WG document version

Introduction This document specifies two variants of Privacy Pass issuance protocols (as defined in ) that allow for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. The base Privacy Pass issuance protocol defines stateless anonymous tokens, which can either be publicly verifiable or not. While it is possible to run multiple instances of the issuance protocol in parallel, e.g., over a multiplexed transport such as HTTP/3 or by orchestrating multiple HTTP requests, these ad-hoc solutions vary based on transport protocol support. In addition, in some cases, they cannot take advantage of cryptographic optimizations. The first variant () of the issuance protocol builds upon the privately verifiable issuance protocol in that uses VOPRF , and allows for batched issuance of tokens and amortizes the cost of zero knowledge proofs. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. In effect, amortizing private batched issuance reduces the per-token cost, approaching a factor of 2 for large batches. The second variant () of the issuance protocol introduces a new Client-Issuer communication method, which allows for batched issuance of generic token types. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. This variant has no other effect than batching requests and responses and the issuance performance remains linear. This document registers a new token type () that can either be used with the Privately Verifiable Issuance Protocol as defined in , or with the Amortized Privately Verifiable Batch Issuance Protocol defined below.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivation Privacy Pass tokens (as defined in and ) are unlinkable during issuance and redemption. The basic issuance protocols defined in , however, only allow for a single token to be issued at a time for every challenge. In some cases, especially where a large number of clients need to fetch a large number of tokens, this may introduce performance bottlenecks. Amortized Privately Verifiable Token Issuance improves upon the basic Privately Verifiable Token issuance protocol in the following key ways:

1. Issuing multiple tokens at once in response to a single TokenChallenge, thereby reducing the size of the proofs required for multiple tokens.
2. Improving server and client issuance efficiency by amortizing the cost of the VOPRF proof generation and verification, respectively.

Generic Token Batch Issuance allows for a single GenericBatchTokenRequest to be sent that encompasses multiple token requests. This improves upon the basic issuance protocols defined in in the following key ways:

1. Issuing multiple tokens at once of the same type with different keys.
2. Issuing multiple tokens at once of different types.

Presentation Language This document uses the TLS presentation language to describe the structure of protocol messages. In addition to the base syntax, it uses two additional features: the ability for fields to be optional and the ability for vectors to have variable-size length headers.

Optional Value An optional value is encoded with a presence-signaling octet, followed by the value itself if present. When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. ; ]]>

Variable-Size Vector Length Headers In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length. The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In this document, there are several vectors whose sizes vary over significant ranges. So instead of using a fixed-size length field, it uses a variable-size length using a variable-length integer encoding based on the one described in . They differ only in that the one here requires a minimum-size encoding. Instead of presenting min and max values, the vector description simply includes a V. For example: ; opaque variable; } StructWithVectors; ]]>

Amortized Privately Verifiable Token Batch Issuance This section describes a batched issuance protocol for select token types, including 0x0001 (defined in ) and 0x0005 (defined in this document). This variant is more efficient than Generic Token Batch Issuance defined below. It does so by requiring the same key to be used by all token requests.

Client-to-Issuer Request Except where specified otherwise, the client follows the same protocol as described in . The Client first creates a context as follows: ciphersuiteID is the ciphersuite identifier from corresponding to the ciphersuite being used for this token version. SetupVOPRFClient is defined in . Nr denotes the number of tokens the clients wants to request. For every token, the Client then creates an issuance request message for a random value nonce with the input challenge and Issuer key identifier as described below: token_type corresponds to the 2-octet integer in the challenge. The above is repeated for each token to be requested. Importantly, a fresh nonce MUST be sampled each time. The Client then creates a BatchTokenRequest structured as follows: ; } AmortizedBatchTokenRequest; ]]> The structure fields are defined as follows:

• "token_type" is a 2-octet integer, which matches the type in the challenge.
• "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).
• "blinded_msgs" is a list of Nr serialized elements, each of length Ne bytes and computed as SerializeElement(blinded_element_i), where blinded_element_i is the i-th output sequence of Blind invocations above. Ne is as defined in .

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the AmortizedBatchTokenRequest as the content. The media type for this request MUST be "application/private-token-amortized-batch-request". If not, the Issuer responds with status code 415. An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below. ]]>

Issuer-to-Client Response Except where specified otherwise, the client follows the same protocol as described in . Upon receipt of the request, the Issuer validates the following conditions:

• The AmortizedBatchTokenRequest contains a supported token_type of the privately verifiable token kind.
• The AmortizedBatchTokenRequest.truncated_token_key_id corresponds to a key ID of a Public Key owned by the issuer.
• Nr, as determined based on the size of AmortizedBatchTokenRequest.blinded_msgs, is less than or equal to the number of tokens that the issuer can issue in a single batch.

If any of these conditions is not met, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. The Issuer then tries to deseralize the i-th element of AmortizedBatchTokenRequest.blinded_msgs using DeserializeElement from , yielding blinded_element_i of type Element. If this fails for any of the AmortizedBatchTokenRequest.blinded_msgs values, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. Otherwise, if the Issuer is willing to produce a token to the Client, the issuer forms a list of Element values, denoted blinded_elements, and computes a blinded response as follows: ciphersuiteID is the ciphersuite identifier from corresponding to the ciphersuite being used for this token version. SetupVOPRFServer is defined in . The issuer uses a list of blinded elements to compute in the proof generation step. The BlindEvaluateBatch function is a batch-oriented version of the BlindEvaluate function described in . The description of BlindEvaluateBatch is below. The computational complexity of BlindEvaluateBatch is linear in the number of evaluations Nr. However the amortization of proof generation across all Nr evaluations reduces the practical cost by approximately half that of Nr individual token issuance operations as Nr increases. The Issuer then creates a AmortizedBatchTokenResponse structured as follows: ; uint8_t evaluated_proof[Ns + Ns]; } AmortizedBatchTokenResponse; ]]> The structure fields are defined as follows:

• "evaluated_msgs" is a list of Nr serialized elements, each of length Ne bytes and computed as SerializeElement(evaluated_element_i), where evaluated_element_i is the i-th output of BlindEvaluate.
• "evaluated_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 .

The Issuer MUST generate an HTTP response with status code 200 whose content consists of AmortizedBatchTokenResponse, with the content type set as "application/private-token-amortized-batch-response". Clients MUST ignore the response if the status code is not 200 or if the content type is not "application/private-token-amortized-batch-response". ]]>

Finalization Upon receipt, the Client handles the response and, if successful, deserializes the body values AmortizedBatchTokenResponse.evaluated_msgs and AmortizedBatchTokenResponse.evaluated_proof, yielding evaluated_elements and proof. If deserialization of either value fails, the Client aborts the protocol. Otherwise, the Client processes the response as follows: The FinalizeBatch function is a batched variant of the Finalize function as defined in . FinalizeBatch accepts lists of evaluated elements and blinded elements as input parameters, and is implemented as described below: If this succeeds, the Client then constructs Nr Token values, where authenticator is the i-th Nh-byte length slice of authenticator_values that corresponds to nonce, the i-th nonce that was sampled in : The constant Nh is as defined in and denotes the output length of the hash function in bytes used by the token type. If the FinalizeBatch function fails, the Client aborts the protocol. Token verification works exactly as specified in .

Generic Token Batch Issuance This section describes an issuance protocol mechanism for issuing multiple tokens in one round trip between Client and Issuer. A generic batch token request can contain token requests for any token type.

Client-to-Issuer Request The Client first generates all of the individual TokenRequest structures that are intended to be batched together. This request creation follows the protocol describing issuance, such as or . The Client then creates a GenericBatchedTokenRequest structure as follows: ; } GenericBatchTokenRequest ]]> The structure fields are defined as follows:

• GenericTokenRequest's "token_type" is a 2-octet integer. The value represents the token type from the IANA Privacy Pass Token Types Registry (). The rest of the structure follows with the TokenRequest based on that type.
• "token_requests" is an array of GenericTokenRequest satisfying the above constraint.

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the GenericBatchTokenRequest as the content. The media type for this request MUST be "application/private-token-generic-batch-request". If not, the Issuer responds with status code 415. An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below. ]]>

Issuer-to-Client Response Upon receipt of the request, the Issuer validates the following conditions:

• The Content-Type is application/private-token-generic-batch-request as registered with IANA.

If this condition is not met, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. The Issuer then tries to deserialize the first 2 bytes of the i-th element of GenericBatchTokenRequest.token_requests. If this is not a token type registered with IANA, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. The issuer creates a GenericBatchTokenResponse structured as follows: generic_token_response; } OptionalTokenResponse; struct { OptionalTokenResponse optional_token_responses; } GenericBatchTokenResponse ]]> For each request in GenericBatchTokenRequest.token_requests, the issuer generates a TokenResponse according to the token type. GenericBatchTokenResponse.optional_token_responses is a variable-size vector of OptionalTokenResponses. OptionalTokenResponse.token_response is an optional TokenResponse (as specified in ), where an absence of TokenResponse indicates that the Issuer failed or refused to issue the associated TokenRequest. The Issuer MUST generate an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-generic-batch-response". Clients MUST ignore the response if the status code is not 200, 206 or if the content type is not "application/private-token-generic-batch-response". ]]> If the Issuer issues some but not all tokens, it MUST return an HTTP 206 Partial Content response defined in to the client and continue processing subsequent requests. For instance, an Issuer MAY return an HTTP 206 error if requests for tokens of the same token type refer to more than one truncated_token_key_id. If the Issuer decides not to issue any tokens, it MUST return an HTTP 400 Bad Request as defined in to the client.

Finalization The Client tries to deserialize the i-th element of GenericBatchTokenResponse.token_responses using the protocol associated to GenericBatchTokenRequest.token_type. If the element has a size of 0, the Client MUST ignore this token, and continue processing the next token. The Client finalizes each deserialized TokenResponse using the matching TokenRequest according to the corresponding finalization procedure defined by the token type.

Security considerations

Amortized Privately Verifiable Token Batch Issuance Implementors SHOULD be aware of the security considerations described in and implement mitigation mechanisms. Application can mitigate this issue by limiting the number of clients and limiting the number of token requests per client per key.

Generic Token Batch Issuance Implementors SHOULD be aware of the inherent linear cost of this token type. An Issuer MAY ignore GenericTokenRequest if the number of tokens per request is past a limit. Generic Token Batch Issuance does not change the security properties of the batched token types. Each token inherits the security considerations of its token type, for instance for type 0x0002 tokens (Blind RSA, 2048-bit).

IANA considerations This section contains IANA codepoint allocation requests.

Token Type RFC EDITOR: please replace "RFC XXXX" with the RFC number of this document, and 0x0005 with the value assigned by IANA, throughout this document. This document updates the "Token Type" Registry () with the following entry:

• Value: 0x0005 (suggested)
• Name: VOPRF (ristretto255, SHA-512)
• Token Structure: As defined in
• Token Key Encoding: Serialized using SerializeElement from
• TokenChallenge Structure: As defined in
• Publicly Verifiable: N
• Public Metadata: N
• Private Metadata: N
• Nk: 64
• Nid: 32
• Change controller: IETF
• Reference:
• Notes: None

The VOPRF (ristretto255, SHA-512) ciphersuite is defined in and uses the ristretto255 group defined in .

Media Types The following entries should be added to the IANA "media types" registry:

• "application/private-token-amortized-batch-request"
• "application/private-token-amortized-batch-response"
• "application/private-token-generic-batch-request"
• "application/private-token-generic-batch-response"

The templates for these entries are listed below and the reference should be this RFC.

"application/private-token-amortized-batch-request" media type

Type name:

application

Subtype name:

private-token-amortized-batch-request

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Applications that want to issue or facilitate issuance of Privacy Pass Amortized Privately Verifiable tokens as defined in , including Privacy Pass issuer applications themselves.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

"application/private-token-amortized-batch-response" media type

Type name:

application

Subtype name:

private-token-amortized-batch-response

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Applications that want to issue or facilitate issuance of Privacy Pass Amortized Privately Verifiable tokens as defined in , including Privacy Pass issuer applications themselves.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

"application/private-token-generic-batch-request" media type

Type name:

application

Subtype name:

private-token-generic-batch-request

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Applications that want to issue or facilitate issuance of Privacy Pass Generic tokens as defined in , including Privacy Pass issuer applications themselves.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

"application/private-token-generic-batch-response" media type

Type name:

application

Subtype name:

private-token-generic-batch-response

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Applications that want to issue or facilitate issuance of Privacy Pass Generic tokens as defined in , including Privacy Pass issuer applications themselves.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

References Normative References This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Informative References n.d. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Test Vectors This section includes test vectors for the two issuance protocols specified in this document. contains test vectors for Amortized Privately Verifiable Token Batch Issuance (0x0005), and contains test vectors for Generic Token Batch Issuance.

Privately Verifiable Token Issuance - VOPRF (ristretto255, SHA-512) The test vectors below list the following values:

• skS: The Issuer Private Key, serialized using SerializeScalar () and represented as a hexadecimal string.
• pkS: The Issuer Public Key, serialized according to the encoding in .
• token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string. nonce: The 32-byte Client nonce generated according to , represented as a hexadecimal string. blind: The blind used when computing the OPRF blinded message, serialized using SerializeScalar () and represented as a hexadecimal string. token_request: The TokenRequest message constructed according to , represented as a hexadecimal string. token_response: The TokenResponse message constructed according to , represented as a hexadecimal string. token: The output token from the protocol, represented as a hexadecimal string.

Amortized Privately Verifiable Token Issuance - VOPRF (P-384, SHA-384) The test vector below lists the following values:

• skS: The Issuer Private Key, serialized using SerializeScalar from and represented as a hexadecimal string.
• pkS: The Issuer Public Key, serialized according to the encoding in .
• token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string.
• nonces: An array of 32-byte client nonces generated according to , represented as a hexadecimal string.
• blinds: An array of blinds used when computing the OPRF blinded message, serialized using SerializeScalar from and represented as a hexadecimal string.
• token_request: The AmortizedBatchTokenRequest message constructed according to , represented as a hexadecimal string.
• token_response: The BatchedTokenResponse message constructed according to , represented as a hexadecimal string.
• tokens: An array of output Tokens from the protocol, represented as a hexadecimal string.

Amortized Privately Verifiable Token Batch Issuance - VOPRF (ristretto255, SHA-512) The test vector below lists the following values:

• skS: The Issuer Private Key, serialized using SerializeScalar from and represented as a hexadecimal string.
• pkS: The Issuer Public Key, serialized according to the encoding in .
• token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string.
• nonces: An array of 32-byte client nonces generated according to , represented as a hexadecimal string.
• blinds: An array of blinds used when computing the OPRF blinded message, serialized using SerializeScalar from and represented as a hexadecimal string.
• token_request: The AmortizedBatchTokenRequest message constructed according to , represented as a hexadecimal string.
• token_response: The BatchedTokenResponse message constructed according to , represented as a hexadecimal string.
• tokens: An array of output Tokens from the protocol, represented as a hexadecimal string.

Generic Token Batch Issuance The test vector below lists the following values:

• issuance: An array of parameters required to generate TokenRequest batched in the current test vector. This is sharded by a parameter type which is the protocol token type, represented as a hexadecimal string. Depending on the type, issuance contains different information type 0x0001 - skS: The Issuer Private Key, serialized using SerializeScalar from and represented as a hexadecimal string. - pkS: The Issuer Public Key, serialized according to the encoding in . - token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string. - nonce: The 32-byte client nonce generated according to , represented as a hexadecimal string. - blind: The blind used when computing the OPRF blinded message, serialized using SerializeScalar from and represented as a hexadecimal string. - token: The output Token from the protocol, represented as a hexadecimal string. type 0x0002 - skS: The PEM-encoded PKCS#8 RSA Issuer Private Key used for signing tokens, represented as a hexadecimal string. - pkS: The Issuer Public Key, serialized according to the encoding in . - token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string. - nonce: The 32-byte client nonce generated according to , represented as a hexadecimal string. - blind: The blind used when computing the blind RSA blinded message, represented as a hexadecimal string. - salt: The randomly generated 48-byte salt used when encoding the blinded token request message, represented as a hexadecimal string. - token: The output Token from the protocol, represented as a hexadecimal string. type 0x0005 - skS: The Issuer Private Key, serialized using SerializeScalar from and represented as a hexadecimal string. - pkS: The Issuer Public Key, serialized according to the encoding in . - token_challenge: A randomly generated TokenChallenge structure, represented as a hexadecimal string. - nonce: The 32-byte client nonce generated according to , represented as a hexadecimal string. - blind: The blind used when computing the OPRF blinded message, serialized using SerializeScalar from and represented as a hexadecimal string. - token: The output Token from the protocol, represented as a hexadecimal string.
• token_request: The AmortizedBatchTokenRequest message constructed according to , represented as a hexadecimal string.
• token_response: The BatchedTokenResponse message constructed according to , represented as a hexadecimal string.

Note to implementers: Generic batched token is an issuance protocol that does not define a token type. You should decide which test vectors is required for your implementation. The batch for each test vector is the following

• Test vector 1: [0x0001]
• Test vector 2: [0x0002]
• Test vector 3: [0x0001, 0x0001]
• Test vector 4: [0x0002, 0x0002]
• Test vector 5: [0x0001, 0x0002]
• Test vector 6: [0x0001, 0x0002]
• Test vector 7: [0x0002, 0x0001]
• Test vector 8: [0x0001, 0x0002, 0x0005, 0x0002]