Privacy Pass Issuance Protocol for Anonymous Credit Tokens

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[ARCHITECTURE] describes the Privacy Pass architecture, and [ISSUANCE] and [AUTHSCHEME] describe the issuance and redemption protocols for basic Privacy Pass tokens, i.e., those computed using blind RSA signatures as specified in Section 6 of [ISSUANCE] or verifiable oblivious pseudorandom functions as specified in Section 5 of [ISSUANCE]. Further, [ARC] scheme, and its associated integration in [ARCHITECTURE] [ARC_PP], extends these approaches to multi-use tokens.¶

The Anonymous Credit Tokens (ACT) protocol, as specified in [ACT], offers a differentiated approach to rate limiting from [ARC]. In particular, ACT credentials can be presented up-to N times. When they spend a certain number of credits from their token, their old token is invalidated and they redeem a new token with the new balance.¶

This document specifies the issuance and redemption protocols for ACT. Section 2 describes motivation for this new type of token, Section 4 presents an overview of the protocols, and the remainder of the document specifies the protocols themselves.¶

2. Motivation

To demonstrate how ACT is useful, one can use a similar example to the the one presented in Section 2 of [ARC_PP]: a client that wishes to keep its IP address private while accessing a service. [ARC_PP] offers the origin to limit the number of requests a client can make to N. This is enforced by each origin getting its own presentation context, and limiting the number of presentations per context to N. This means that, from a single token, we can produce N presentations and access the system N times, unlinkably. These presentations can be generated in parallel.¶

On the other hand, consider the case of an ACT with N credits in it. A client willing to redeem N different credits has to spend 1, then get a refund, spend 1, then get a refund, and so on. Because the client can't spend 1 until they get a refund for their previous credit, a single live session is enforced per ACT. This provides concurrency control. A client is also able to spend more than 1, allowing for a more efficient redemption of multipe tokens. Finally, as new presentation requires the obtention of a previous refund, the origin gains the ability to invalidate a session by declining said refund. This creates the ability to shed harmful future traffic or redirect it in a favorable way.¶

One such use case for this is a privacy proxy, another is privately accessing web APIs like the artificial intelligence models, and finally zero trust networks which act as forward proxies for their user traffic.¶

Therefore, ACT provides the following properties¶

1. Concurrency control: Preventing multiple simultaneous uses of the same credential, mitigating abuse from token sharing or replay.¶

2. Dynamic Revocation: Enabling immediate invalidation of tokens in response to origin policy, without waiting for token expiry.¶

3. Per-Session Rate Limiting: Enforcing access policies that adapt to user, device, or risk context, rather than static per-token limits. This creates incentives for platform to deploy such methods.¶

3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms Origin, Client, Issuer, and Token as defined in Section 2 of [ARCHITECTURE]. Moreover, the following additional terms are used throughout this document.¶

• Issuer Public Key: The public key (from a private-public key pair) used by the Issuer for issuing and verifying Tokens.¶

• Issuer Private Key: The private key (from a private-public key pair) used by the Issuer for issuing and verifying Tokens.¶

Unless otherwise specified, this document encodes protocol messages in TLS notation from Section 3 of [TLS13]. Moreover, all constants are in network byte order.¶

4. Protocol Overview

The issuance and redemption protocols defined in this document are built on the Anonymous Credit Tokens (ACT) protocol. ACT tokens can be thought of as single use tokens, similar to the RSA Blind Signatures protocol. However, by another viewpoint, they might be thought of as stateful, multi-use tokens.¶

With ACT, Clients receive TokenChallenge inputs from the redemption protocol ([AUTHSCHEME], Section 2.1). If they have a valid ACT for the designated Issuer, Clients can use the TokenChallenge to produce a single token for presentation. Otherwise, Clients invoke the issuance protocol to obtain an ACT. This interaction is shown below.¶

Similar to the core Privacy Pass protocols, the TokenChallenge can be interactive or non-interactive, and per-origin or cross-origin.¶

ACT is only compatible with deployment models where the Issuer and Origin are operated by the same entity (see Section 4 of [ARCHITECTURE]), as tokens produced from a credential are not publicly verifiable. The details of attestation are outside the scope of the issuance protocol; see Section 4 of [ARCHITECTURE] for information about how attestation can be implemented in each of the relevant deployment models.¶

The issuance and redemption protocols in this document are built on [ACT].¶

5. Configuration

ACT Issuers are configured with key material used for issuance and token verification. Concretely, Issuers run the KeyGen function from [ACT] to produce a private and public key, denoted skI and pkI, respectively.¶

skI, pkI = SetupServer()

The Issuer Public Key ID, denoted issuer_key_id, is computed as the SHA-256 hash of the Issuer Public Key, i.e., issuer_key_id = SHA-256(pkI_serialized), where pkI_serialized is the serialized version of pk as described in Section 4.1 of [ACT] (TODO actually write and sync serialization, CBOR and TLS seems weird).¶

6. Token Challenge Requirements

The ACT protocol uses a modified TokenChallenge structure from the one specified in [AUTHSCHEME]. In particular, the updated TokenChallenge structure is as follows:¶

struct {
    uint16_t token_type = 0xE5AC; /* Type ACT(Ristretto255) */
    opaque issuer_name<1..2^16-1>;
    opaque redemption_context<0..32>;
    opaque origin_info<0..2^16-1>;
    opaque credential_context<0..32>;
} TokenChallenge;

With the exception of credential_context, all fields are exactly as specified in Section 2.1.1 of [AUTHSCHEME]. The credential_context field is defined as follows:¶

• "credential_context" is a field that is either 0 or 32 bytes, prefixed with a single octet indicating the length (either 0 or 32). If value is non-empty, it is a 32-byte value generated by the origin that allows the origin to require that clients fetch credentials bound to a specific context. Challenges with credential_context values of invalid lengths MUST be ignored.¶

Similar to the redemption_context field, the credential_context is used to bind information to the credential. This might be useful, for example, to enforce some expiration on the credential. Origins might do this by constructing credential_context as F(current time window), where F is a pseudorandom function. Semantically, this is equivalent to the Origin asking the Client for a token from a credential that is bound to "current time window."¶

OPEN ISSUE: give more guidance about how to construct credential_context and redemption_context depending on the application's needs.¶

!!! UNEDITED BELOW¶

In addition to this updated TokenChallenge, the HTTP authentication challenge also SHOULD contain the following additional attribute:¶

• "rate-limit", which contains a JSON number indicating the presentation limit to use for ARC.¶

Implementation-specific steps: the client should store the Origin-provided input tokenChallenge so that when they receive a new tokenChallenge value, they can check if it has changed and which fields are different. This will inform the client's behavior - for example, if credential_context is being used to enforce an expiration on the credential, then if the credential_context has changed, this can prompt the client to request a new credential.¶

7. Credential Issuance Protocol

Issuers provide an Issuer Private and Public Key, denoted skI and pkI respectively, used to produce tokens as input to the protocol. See Section 5 for how these keys are generated.¶

Clients provide the following as input to the issuance protocol:¶

• Issuer Request URL: A URL identifying the location to which issuance requests are sent. This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL. The value of this parameter depends on the Client configuration and deployment model. For example, in the 'Joint Origin and Issuer' deployment model, the Issuer Request URL might correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer.¶

• Issuer name: An identifier for the Issuer. This is typically a host name that can be used to construct HTTP requests to the Issuer.¶

• Issuer Public Key: pkI, with a key identifier token_key_id computed as described in Section 5.¶

Given this configuration and these inputs, the two messages exchanged in this protocol to produce a credential are described below.¶

request_context = concat(tokenChallenge.issuer_name,
  tokenChallenge.origin_info,
  tokenChallenge.credential_context,
  issuer_key_id)
(clientSecrets, request) = CredentialRequest(request_context)

struct {
  uint16_t token_type = 0xE5AC; /* Type ARC(P-256) */
  uint8_t truncated_issuer_key_id;
  uint8_t encoded_request[Nrequest];
} TokenRequest;

POST /request HTTP/1.1
Host: issuer.example.net
Accept: application/private-credential-response
Content-Type: application/private-credential-request
Content-Length: <Length of TokenRequest>

<Bytes containing the TokenRequest>

response = CredentialResponse(skI, pkI, request)

struct {
   uint8_t encoded_response[Nresponse];
} TokenResponse;

HTTP/1.1 200 OK
Content-Type: application/private-credential-response
Content-Length: <Length of TokenResponse>

<Bytes containing the TokenResponse>

credential = FinalizeCredential(clientSecrets, pkI, request, response)

8. Token Redemption Protocol

The token redemption protocol takes as input TokenChallenge and presentation limit values from [AUTHSCHEME], Section 2.1; the presentation limit is sent as an additional attribute within the HTTP challenge as described in Section 6. Clients use credentials from the issuance protocol in producing tokens bound to the TokenChallenge. The process for producing a token in this way, as well as verifying a resulting token, is described in the following sections.¶

presentation_context = concat(tokenChallenge.issuer_name,
  tokenChallenge.origin_info,
  tokenChallenge.redemption_context,
  issuer_key_id)
state = MakePresentationState(credential, presentation_context, presentationLimit)
newState, nonce, presentation = Present(state)

struct {
    uint16_t token_type = 0xE5AC; /* Type ARC(P-256) */
    uint32_t presentation_nonce;
    uint8_t challenge_digest[32];
    uint8_t issuer_key_id[Nid];
    uint8_t presentation[Npresentation];
} Token;

request_context = concat(tokenChallenge.issuer_name,
  tokenChallenge.origin_info,
  tokenChallenge.credential_context,
  issuer_key_id)
presentation_context = concat(tokenChallenge.issuer_name,
  tokenChallenge.origin_info,
  tokenChallenge.redemption_context,
  issuer_key_id)
valid = VerifyPresentation(skI, pkI, request_context, presentation_context, nonce, presentation, presentation_limit)

9. Security Considerations

Privacy considerations for tokens based on deployment details, such as issuer configuration and issuer selection, are discussed in Section 6.1 of [ARCHITECTURE]. Note that ARC requires a joint Origin and Issuer configuration given that it is privately verifiable.¶

ARC offers Origin-Client unlinkability, Issuer-Client unlinkability, and redemption context unlinkability, as described in Section 3.3 of [ARCHITECTURE], with one exception. While redemption context unlinkability is achieved by re-randomizing credentials every time they are presented as tokens, there is a reduction in the anonymity set in the case of presentation nonce collisions, as detailed in Section 7.2 of [ARC].¶

10. IANA Considerations

This document updates the "Privacy Pass Token Type" Registry with the following entries.¶

• Value: 0xE5AC¶

• Name: ARC (P-256)¶

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

• Token Key Encoding: Serialized as described in Section 5¶

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

• Public Verifiability: N¶

• Public Metadata: N¶

• Private Metadata: N¶

• Nk: 0 (not applicable)¶

• Nid: 32¶

• Reference: This document¶

• Notes: None¶

11. References

Acknowledgments

The authors would like to thank Tommy Pauly and the authors of [RATE-LIMITED] for helpful discussions on rate-limited tokens.¶

Authors' Addresses