Summary

  • draft-ietf-privacypass-batched-tokens-08 defines an amortized VOPRF batch with one proof over many evaluated elements and a generic batch with optional per-position responses. They have different failure and accounting semantics.
  • A fresh nonce belongs to every requested token, but an HTTP 200, HTTP 206 or valid batch proof does not prove how many tokens finalized, reached durable storage, were later redeemed once or produced an application effect.
  • Operators need a privacy-preserving batch receipt that reconciles requested, admitted, returned, finalized, stored and consumed counts without becoming a stable identifier that links later redemptions.

The issuer returns HTTP 200. The cryptographic proof verifies. The client dashboard increments “available tokens” by 64.

That last step is a business decision disguised as arithmetic.

The protocol may have established that a set of blinded inputs was evaluated under the issuer's key. It has not established that the client parsed 64 outputs, associated each one with the right request, completed finalization, wrote all resulting tokens to durable storage, avoided duplicate records, survived a crash, or later presented each token exactly once. A batch can be valid as a cryptographic exchange and still be miscounted as inventory.

This is the new control surface in draft-ietf-privacypass-batched-tokens-08. The document, dated 4 May 2026, is a Privacy Pass Working Group Internet-Draft intended for the Standards Track. At this evidence cut-off it has been submitted to the IESG, but its state is AD Evaluation::Revised I-D Needed. It is not an RFC. The current IANA Privacy Pass registry lists token types 0x0001 and 0x0002; the draft's VOPRF(ristretto255, SHA-512) value 0x0005 remains a suggested allocation, not a live registry entry.

The draft solves a real scaling problem. RFC 9578's basic issuance exchanges obtain one token at a time. A client needing many tokens can run many requests, perhaps in parallel, but transport multiplexing does not remove repeated cryptographic work. Batch issuance can reduce round trips and amortize a proof. The engineering gain is precise. The temptation to overstate its operational meaning is equally precise.

There are two batches, not one

The document defines two mechanisms because “batch” hides two different structures.

The amortized privately verifiable variant takes several blinded elements of the same supported private-token kind. The issuer evaluates every element and produces one proof over the input and output lists. The client verifies that proof before deriving the authenticators. This is a collective verification gate.

The generic variant is a container for ordinary token requests. Requests can use different registered token types. The issuer returns a corresponding vector of optional responses. One position can be empty because the issuer failed or refused that request, while later positions still carry responses. If some but not all requests are fulfilled, the issuer returns HTTP 206 and continues processing. If none are fulfilled, it returns HTTP 400.

These are not two encodings of the same accounting model. The amortized path concentrates proof success or failure across a set. The generic path exposes per-position partial issuance. An observability system that records only “batch succeeded” erases the distinction the protocol deliberately preserves.

Before adopting the extension, name the event being counted. Was the batch syntactically accepted? Were all elements admitted? Was one proof verified? Were 47 of 64 generic positions non-empty? Were those 47 finalized? Were 46 durably committed? Each answer can be true while the next is false.

A fresh nonce keeps tokens distinct; it does not count them for you

For the amortized path, the client samples a fresh 32-byte nonce for every requested token. The token input also binds the token type, the digest of the challenge and the issuer key identifier. Each blinded element therefore begins from a distinct token input even though the request travels as one batch.

This is a cryptographic invariant, not an inventory system. A correct implementation must still retain the local state needed to match the ith evaluated element and authenticator slice with the ith nonce. Reordering, truncation or an off-by-one association bug can corrupt the relationship without changing the human phrase “proof passed.”

After finalization, a client must decide how tokens become durable bearer inventory. A database transaction can fail after the response was accepted. A process can restart after writing some rows. A retry can reissue the request or duplicate local records. A backup can restore a token already redeemed elsewhere. The protocol's fresh nonce requirement does not settle those local state transitions.

Preserve per-position association during issuance, then discard or minimize correlation data once it is no longer needed. The evidence system should prove counts, integrity and state transitions without creating a stable batch identifier that later follows individual tokens to origins. Privacy can be lost by the audit layer even when the cryptography behaves correctly.

One proof reduces work and enlarges the failure domain

The amortized issuer still performs one evaluation per blinded element. The draft says the computational complexity is linear in Nr. What is amortized is proof generation: as Nr increases, the practical cost approaches roughly half the cost of Nr individual issuance operations.

That is valuable, but it is not “64 tokens for the price of one.” CPU, parsing, admission, network bytes, rate limits, client state and storage do not vanish. The security section tells applications to limit clients and token requests per client and key. Generic batching also retains an inherent linear cost.

The shared proof creates a deliberate atomic boundary. The client deserializes the evaluated messages and proof, then verifies the relation across the lists. If deserialization or proof verification fails, it aborts. A single malformed request element is also enough for the issuer to return HTTP 422 on the amortized request.

Efficiency has therefore moved risk. Separate issuance spends more overhead but limits one exchange's blast radius. A larger batch saves proof work while putting more intended future transactions behind one parser, one key choice, one admission decision and one proof gate. Neither choice is universally right. The correct batch size depends on the cost of correlated loss and retry, not only throughput.

HTTP 206 is a receipt for incompleteness

The generic path is unusually honest about partial success. Each request has a corresponding optional response. An absent value means the issuer failed or refused to issue that token. The client ignores the empty position and continues with later positions.

If the issuer produced some but not all tokens, it must return HTTP 206 Partial Content. The status is not an error that licenses discarding the body. Nor is it success that licenses counting every requested token. It is a control message: inspect the positions.

This matters for mixed token types and key transitions. The draft notes that an issuer might return 206 when requests for the same token type refer to more than one truncated key identifier. A batch can therefore expose a configuration split that individual retry logic would otherwise hide.

The accounting rule should be explicit:

requested ≠ admitted ≠ returned ≠ finalized ≠ stored ≠ redeemable ≠ redeemed ≠ acted upon.

Do not collapse those quantities into one “issued” counter. That word becomes ambiguous at scale. If an issuer returned a response that the client failed to finalize, issuance occurred from one party's perspective and not from another's. The receipt must record whose observation it represents.

The response code does not own the retry policy

Retries create the most expensive ambiguities. An oversized amortized batch can receive 422. A generic batch can return 206 with holes. A network failure can occur after the issuer processed the request but before the client received the response. A local store can fail after finalization.

Should the client retry the whole batch, only empty positions, only non-committed finalizations, or nothing? The protocol cannot answer without local state. Retrying everything may consume admission quota and create additional valid tokens. Retrying holes may require reconstructing the exact request-to-position mapping. Refusing retry protects accounting but can strand an application without inventory.

Define the retry unit before deployment. Bind it to observed state, not an undifferentiated timeout. For each position, record a non-sensitive request digest, token type, issuer key epoch, response presence, finalization result and durable commit result. Keep the issuance receipt separate from the bearer token and from later redemption telemetry.

A retry must never be justified by “HTTP was not 200” alone. In the generic protocol 206 contains usable responses. In an ambiguous network failure, the issuer may have completed work. In a local crash, replaying the wire exchange cannot repair a missing database transaction unless the application understands what was already committed.

Admission limits are economic policy in code

Batch limits look like implementation details. They are also allocation policy.

The amortized issuer rejects a request whose Nr exceeds the number of tokens it can issue in one batch. The generic issuer may ignore requests beyond a per-request limit. Applications are advised to limit the number of clients and token requests per client and key. Those controls decide who can turn one attestation or network round trip into how much future bearer inventory.

Large batches favor clients that can prefetch and hold inventory. Small limits increase online dependence on the issuer. Per-client and per-key limits affect burst tolerance, failover and key rollover. An undocumented limit change can look like cryptographic failure when it is actually policy.

Treat limits as versioned configuration with named ownership. Measure rejection and partial-response rates by client class without logging identifiers that later permit redemption correlation. Publish enough behavior for clients to adapt, but do not let one global registry dictate every issuer's abuse model.

The narrow protocol is an advantage. It defines the interoperable exchange and leaves quota economics local. Governance fails when a wire status is allowed to conceal that local policy exists.

IANA can allocate a code point; it cannot prove deployment

Revision 08 proposes token type 0x0005 and four media types for amortized and generic batch requests and responses. The live registry captured for this Article does not yet contain 0x0005. The responsible Area Director also asked whether the suggested value and references should be clarified before publication.

This is normal standards work, not scandal. It is also a useful evidence boundary. A value printed in an Internet-Draft is not an active allocation. An active allocation would not prove implementation. An implementation report would not prove interoperability. Interoperability would not prove that an operator's inventory accounting is correct.

Keep those receipts in order: document state, IANA state, software support, negotiated use, successful exchange, successful finalization, durable storage and later service behavior. Skipping from the first to the last is how standards labels become false operational assurances.

The document shepherd reports implementations and strong consensus in a small working group. No implementation census, conformance matrix or measured deployment result is supplied. The most accurate sentence is therefore modest: the work has implementation interest and is under IESG evaluation.

Issuance privacy can be undone by inventory telemetry

RFC 9576 separates attestation, issuance and redemption contexts. Privacy depends on what parties can observe and combine. Batched issuance does not erase that architecture.

A batch has its own visible properties: time, size, issuer, key epoch, transport endpoint and client network context. A client-side ledger can add a stable batch identifier, device account, storage location and later redemption record. If that ledger is exported or joined with origin telemetry, it can supply the correlation surface that blinded issuance was designed to avoid.

Auditability and unlinkability are not opposites, but they require deliberate data design. Keep aggregate counts and one-way digests where possible. Use short retention for request-position maps. Separate issuance operations from redemption analytics. Do not put a reusable batch ID into tokens, application requests or cross-domain logs. Restrict who can join attestation, issuance, inventory and redemption records.

The receipt should answer “did the local inventory reconcile?” without answering “which later web action spent token 37 from batch 912?” unless a narrowly authorized incident process truly requires that linkage.

Build the missing batch receipt

A useful receipt has three layers.

The batch layer records protocol variant, issuer endpoint, token types, challenge/configuration digest, issuer key epoch, request count, admitted count if known, response status, returned vector length, proof digest or generic response digest, timing and limits applied.

The position layer records a privacy-preserving request digest, response present or absent, deserialize result, finalization result, local token-record digest and commit status. It must preserve ordering long enough to prove association, then follow a deletion policy.

The inventory layer records opening balance, successfully committed additions, quarantined records, deletions, selected tokens, confirmed redemptions, ambiguous outcomes and closing balance. It must be transactional. The invariant is not “HTTP 200 adds Nr.” It is “only committed, finalized, non-duplicated token records add to available inventory.”

Later redemption needs another receipt: selected inventory item, origin challenge compatibility, presentation, replay-state result, origin authorization and application effect. The batch receipt should link only through protected, purpose-limited evidence—not through a public or broadly queryable tracking key.

This creates an evidence chain without expanding protocol authority:

configure -> attest -> request -> admit -> respond -> verify/finalize -> commit -> select -> redeem -> authorize -> observe.

Every arrow can fail while the previous node remains true. Batching makes the first half cheaper. It does not make the chain shorter.

The operator's test is reconciliation under failure

Happy-path test vectors prove encoding and cryptographic behavior. Production acceptance needs state failure.

Send an amortized batch at the supported limit, then one above it. Corrupt one blinded element. Truncate the evaluated list. Reorder two outputs. Fail proof verification. Kill the client after finalization but before commit. Kill it after a partial commit. Restore a backup containing already-consumed inventory.

For the generic path, mix supported token types. Insert one unknown type. Use different truncated key identifiers. Force one refusal in the middle and verify that later positions continue. Return 206 and ensure the client counts non-empty finalized positions rather than the request length. Fail one per-token finalization. Rotate the issuer key while old inventory remains.

Then test redemption independently. A valid token can be incompatible with the current origin challenge, already spent, outside local policy or rejected by an origin. None of those outcomes retroactively falsifies the issuance proof. They show why the proof never owned the downstream conclusion.

The operational question is simple: after every injected failure, can the system explain each count without exposing a linkable map of future user activity? If not, the batch feature is not ready, however elegant the cryptography.