Batched Token Issuance Protocol

4.1. Client-to-Issuer Request

Except where specified otherwise, the client follows the same protocol as described in [RFC9578], Section 5.1.¶

The Client first creates a context as follows:¶

client_context = SetupVOPRFClient(ciphersuiteID, pkI)

ciphersuiteID is the ciphersuite identifier from [OPRF] corresponding to the ciphersuite being used for this token version. SetupVOPRFClient is defined in [OPRF], Section 3.2.¶

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:¶

nonce_i = random(32)
challenge_digest = SHA256(challenge)
token_input = concat(token_type, nonce_i, challenge_digest,
                token_key_id)
blind_i, blinded_element_i = client_context.Blind(token_input)

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:¶

struct {
    uint8_t blinded_element[Ne];
} BlindedElement;

struct {
   uint16_t token_type;
   uint8_t truncated_token_key_id;
   BlindedElement blinded_elements<0..2^16-1>;
} BatchTokenRequest;

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_elements" 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 [OPRF], Section 4.¶

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the BatchTokenRequest as the content. The media type for this request is "application/private-token-privately-verifiable-batch-request". An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below.¶

POST /request HTTP/1.1
Host: issuer.example.net
Accept: application/private-token-privately-verifiable-batch-response
Content-Type: application/private-token-privately-verifiable-batch-request
Content-Length: <Length of BatchTokenRequest>

<Bytes containing the BatchTokenRequest>

4.2. Issuer-to-Client Response

Except where specified otherwise, the client follows the same protocol as described in [RFC9578], Section 5.2.¶

Upon receipt of the request, the Issuer validates the following conditions:¶

• The BatchTokenRequest contains a supported token_type equal to one of the batched token types defined in this document.¶

• The BatchTokenRequest.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 BatchTokenRequest.blinded_elements, 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 BatchTokenRequest.blinded_elements using DeserializeElement from Section 2.1 of [OPRF], yielding blinded_element_i of type Element. If this fails for any of the BatchTokenRequest.blinded_elements 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:¶

server_context = SetupVOPRFServer(ciphersuiteID, skI, pkI)
evaluated_elements, proof =
  server_context.BlindEvaluateBatch(skI, blinded_elements)

ciphersuiteID is the ciphersuite identifier from [OPRF] corresponding to the ciphersuite being used for this token version. SetupVOPRFServer is defined in [OPRF], Section 3.2. 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 [OPRF], Section 3.3.2. The description of BlindEvaluateBatch is below.¶

Input:

  Element blindedElements[Nr]

Output:

  Element evaluatedElements[Nr]
  Proof proof

Parameters:

  Group G
  Scalar skS
  Element pkS

def BlindEvaluateBatch(blindedElements):
  evaluatedElements = []
  for blindedElement in blindedElements:
    evaluatedElements.append(skS * blindedElement)

  proof = GenerateProof(skS, G.Generator(), pkS,
                        blindedElements, evaluatedElements)
  return evaluatedElements, proof

The Issuer then creates a BatchTokenResponse structured as follows:¶

struct {
    uint8_t evaluated_element[Ne];
} EvaluatedElement;

struct {
   EvaluatedElement evaluated_elements<0..2^16-1>;
   uint8_t evaluated_proof[Ns + Ns];
} BatchTokenResponse;

The structure fields are defined as follows:¶

• "evaluated_elements" is a list of Nr serialized elements, each of length Ne bytes and computed as SerializeElement(evaluate_element_i), where evaluate_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 [OPRF], Section 4.¶

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-privately-verifiable-batch-response".¶

HTTP/1.1 200 OK
Content-Type: application/private-token-privately-verifiable-batch-response
Content-Length: <Length of BatchTokenResponse>

<Bytes containing the BatchTokenResponse>

4.3. Finalization

Upon receipt, the Client handles the response and, if successful, deserializes the body values TokenResponse.evaluate_response and TokenResponse.evaluate_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:¶

authenticator_values = client_context.FinalizeBatch(token_input, blind,
                         evaluated_elements, blinded_elements, proof)

The FinalizeBatch function is a batched variant of the Finalize function as defined in [OPRF], Section 3.3.2. FinalizeBatch accepts lists of evaluated elements and blinded elements as input parameters, and is implemented as described below:¶

Input:

  PrivateInput input
  Scalar blind
  Element evaluatedElements[Nr]
  Element blindedElements[Nr]
  Proof proof

Output:

  opaque output[Nh * Nr]

Parameters:

  Group G
  Element pkS

Errors: VerifyError

def FinalizeBatch(input, blind,
  evaluatedElements, blindedElements, proof):
  if VerifyProof(G.Generator(), pkS, blindedElements,
                 evaluatedElements, proof) == false:
    raise VerifyError

  output = nil
  for evaluatedElement in evaluatedElements:
    N = G.ScalarInverse(blind) * evaluatedElement
    unblindedElement = G.SerializeElement(N)
    hashInput = I2OSP(len(input), 2) || input ||
                I2OSP(len(unblindedElement), 2) || unblindedElement ||
                "Finalize"
    output = concat(output, Hash(hashInput))

  return output

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 Section 4.1:¶

struct {
    uint16_t token_type;
    uint8_t nonce[32];
    uint8_t challenge_digest[32];
    uint8_t token_key_id[32];
    uint8_t authenticator[Nh];
} Token;

If the FinalizeBatch function fails, the Client aborts the protocol. Token verification works exactly as specified in [RFC9578].¶

5.1. Client-to-Issuer Request

The Client first creates all TokenRequest it wants to batch. To do so, the client follows protocol describing issuance, such as [RFC9578], Section 5.1 or [RFC9578], Section 6.1.¶

The Client then creates a BatchedTokenRequest structured as follows:¶

struct {
   uint16_t token_type;
   select (token_type) {
      case (0x0001): /* Type VOPRF(P-384, SHA-384), RFC 9578 */
         uint8_t truncated_token_key_id;
         uint8_t blinded_msg[Ne];
      case (0x0002): /* Type Blind RSA (2048-bit), RFC 9578 */
         uint8_t truncated_token_key_id;
         uint8_t blinded_msg[Nk];
   }
} TokenRequest;

struct {
  TokenRequest token_requests<0..2^16-1>;
} BatchTokenRequest

The structure fields are defined as follows:¶

• "token_type" is a 2-octet integer. TokenRequest MUST be prefixed with a uint16 "token_type" indicating the token type. The rest of the structure follows based on that type, within the inner opaque token_request attribute. The above definition corresponds to TokenRequest from [RFC9578]. For TokenRequest not defined in [RFC9578], they MAY be used as long as they are prefixed with a 2-octet token_type.¶

• "token_requests" are serialized TokenRequests, in network byte order. The number of token_requests, as a 2-octet integer, is prepended to the serialized TokenRequests. In addition, the 2-octet integer length of each TokenRequest is prepended to the serialized TokenRequests.¶

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the BatchTokenRequest as the content. The media type for this request is "application/private-token-arbitrary-batch-request". An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below.¶

POST /request HTTP/1.1
Host: issuer.example.net
Accept: application/private-token-arbitrary-batch-response
Content-Type: application/private-token-arbitrary-batch-request
Content-Length: <Length of BatchTokenRequest>

<Bytes containing the BatchTokenRequest>

5.2. Issuer-to-Client Response

Upon receipt of the request, the Issuer validates the following conditions:¶

• The Content-Type is application/private-token-arbitrary-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 BatchTokenRequest.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 BatchTokenResponse structured as follows:¶

struct {
  TokenResponse token_response<0..2^16-1>; /* Defined by token_type */
} OptionalTokenResponse;

struct {
  OptionalTokenResponse token_responses<0..2^16-1>;
} BatchTokenResponse

BatchTokenResponse.token_responses is a vector of OptionalTokenResponses, length prefixed with two bytes. OptionalTokenResponse.token_response is a length-prefix-encoded TokenResponse, where a length of 0 indicates that the Issuer failed or refused to issue the associated TokenRequest.¶

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-arbitrary-batch-response".¶

If the Issuer issues some tokens but not all, it MUST return an HTTP 206 to the client and continue processing further requests.¶

HTTP/1.1 200 OK
Content-Type: application/private-token-arbitrary-batch-response
Content-Length: <Length of BatchTokenResponse>

<Bytes containing the BatchTokenResponse>

5.3. Finalization

The Client tries to deserialize the i-th element of BatchTokenResponse.token_responses using the protocol associated to BatchTokenRequest.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.¶

6.1. Batched Privately Verifiable Tokens

Implementors SHOULD be aware of the security considerations described in [OPRF], Section 6.2.3 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.¶

6.2. Arbitrary Batched Verifiable Tokens

Implementors SHOULD be aware of the inherent linear cost of this token type. An Issuer MAY ignore TokenRequest if the number of tokens per request past a limit.¶

7.1. Token Type

This document updates the "Token Type" Registry ([AUTHSCHEME]) with the following entry:¶

• Value: 0xF91A¶

• Name: VOPRF (ristretto255, SHA-512)¶

• Token Structure: As defined in Section 2.2 of [AUTHSCHEME]¶

• Token Key Encoding: Serialized using SerializeElement from Section 2.1 of [OPRF]¶

• TokenChallenge Structure: As defined in Section 2.1 of [AUTHSCHEME]¶

• Publicly Verifiable: N¶

• Public Metadata: N¶

• Private Metadata: N¶

• Nk: 32¶

• Nid: 32¶

• Reference: [RFC9578], Section 5¶

• Notes: None¶

7.2. Media Types

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

• "application/private-token-privately-verifiable-batch-request"¶

• "application/private-token-privately-verifiable-batch-response"¶

• "application/private-token-arbitrary-batch-request"¶

• "application/private-token-arbitrary-batch-response"¶

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

8.1. Normative References

[AUTHSCHEME]

Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", Work in Progress, Internet-Draft, draft-ietf-privacypass-auth-scheme-15, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-15>.

[OPRF]

Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Work in Progress, Internet-Draft, draft-irtf-cfrg-voprf-21, 21 February 2023, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21>.

[RFC9576]

Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-16, 25 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-16>.

[RFC9578]

Celi, S., Davidson, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocol", Work in Progress, Internet-Draft, draft-ietf-privacypass-protocol-16, 3 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-16>.

8.2. Informative References

[HTTP3]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.