The Privacy Pass HTTP Authentication Scheme
Extracted elements (34)
GREASE (Generate Random Extensions And Sustain Extensibility) values are reserved in the token types registry, inspired by RFC 8701. Both Clients and Origins can send greased values to ensure implementations handle unknown token types gracefully and remain interoperable with future extensions.
The challenge_digest field in the Token structure is SHA-256 of the original TokenChallenge. Changing the hash algorithm would require a new token type and structure definition, intentionally making algorithm agility explicit and version-controlled rather than implicit.
The redemption_context field can represent various properties: a per-request nonce (32 random bytes), a time-window-bound value F(time window), a network-bound value F(Client ASN), or a combination. An empty context removes the need for per-context double-spend state but requires global state sharing across all Origin servers.
Token caching is supported so Clients can generate multiple tokens from a single TokenChallenge and store them for future use. This improves privacy by decoupling the time of issuance from the time of redemption, reducing correlation between the two events.
When an Origin sends multiple token challenges, it should sort its preferred challenge first as a hint to Clients, since Clients are free to pick any. Challenges SHOULD only mix token types with functionally equivalent properties, as mixing non-equivalent challenges for the same use case is semantically inconsistent.
Future token types MAY extend or modify both the TokenChallenge and Token structures beyond the defaults defined in this document. The token_type field in each structure acts as the discriminator, and the registry entry defines how the structures differ per type.
All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness (RFC 4086).
All token challenges MUST begin with a 2-octet integer defining the token type in network byte order. Clients MUST ignore challenges with token types they do not support.
All unknown or unsupported parameters to 'PrivateToken' authentication credentials MUST be ignored by the recipient. Clients MUST also ignore parameters in challenges not defined for the issuance protocol corresponding to the token type.
Applications SHOULD constrain tokens to a single Origin unless the use case can accommodate replay attacks. If token redemption produces side effects, Origins SHOULD implement an anti-replay mechanism.
Challenges with redemption_context values of invalid lengths (lengths other than 0 or 32) MUST be ignored by Clients.
Clients MUST NOT fetch or redeem a token based on a challenge that fails validation. Validation requires: recognized token_type, well-formed TokenChallenge structure, and (if origin_info is non-empty) the challenging Origin's name appears in origin_info.
Clients SHOULD discard context-bound tokens (those with non-empty redemption_context) upon flushing state such as HTTP cookies or upon a network change when no Origin-specific state is present, to prevent an Origin from using redemption context as a persistent identifier.
Clients SHOULD have some implementation-specific policy to minimize the number of tokens that can be retrieved by Origins, to defend against token exhaustion attacks where a malicious Origin sends excessive unique challenges.
If the origin_info field in a TokenChallenge is non-empty, the Origin that issued the authentication challenge MUST include its own name as one of the names in the list. Comparison is case-insensitive.
Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice, to ensure Clients cannot replay tokens for previous challenges.
Origins SHOULD include random token types from the reserved 'greased' values with some non-trivial probability to prevent Clients from becoming incompatible with new token challenge types.
Origins SHOULD minimize the number of challenges sent to a particular Client context to avoid overwhelming Clients and Issuers with token requests that might cause rate limiting.
The base64url values for the challenge and token-key parameters in WWW-Authenticate, and for the token parameter in Authorization, MUST include padding as defined in RFC 4648 Section 3.2.
When a Client chooses between multiple token challenges, the choice SHOULD be made in a consistent manner to ensure it does not reveal information about the specific Client.
Server names in token challenges are ASCII strings containing hostname and optional port (implied 443 if absent), following URI authority format (RFC 3986 Section 3.2). Names MUST NOT include a userinfo portion. Multiple Origin names in origin_info are comma-delimited without whitespace.
The AuthenticatorInput structure used for token verification consists of token_type (2 octets), nonce (32 octets), challenge_digest (32 octets), and token_key_id (Nid octets). The authenticator in the Token structure is computed over these fields using the issuance protocol corresponding to the token type.
The Authorization header with 'PrivateToken' scheme carries one parameter, 'token', containing the base64url-encoded Token structure. Clients present this to Origins to redeem (spend) a token. Each token contains a unique Client nonce and a challenge_digest binding it to the specific TokenChallenge.
The 'PrivateToken' HTTP authentication scheme allows Clients to redeem Privacy Pass tokens with Origins. Origins challenge Clients via WWW-Authenticate with a TokenChallenge, and Clients respond via Authorization with a redeemed token. The scheme supports multiple token issuance protocols and optional context/Origin binding.
The WWW-Authenticate header with 'PrivateToken' scheme carries two mandatory parameters: 'challenge' (base64url-encoded TokenChallenge) and 'token-key' (base64url-encoded Issuer public key). An optional 'max-age' parameter specifies the number of seconds the challenge is valid. The token-key MAY be omitted if Clients can retrieve the key out-of-band.
IANA has created a new 'Privacy Pass Token Types' registry in a 'Privacy Pass' page. Entries require: Value (2-byte identifier), Name, Token Structure, Token Key Encoding, TokenChallenge Structure, Publicly Verifiable (Y/N), Public Metadata (Y/N), Private Metadata (Y/N), Nk, Nid, Change Controller, Reference, and Notes. Registration policy is Specification Required.
IANA has registered the 'PrivateToken' authentication scheme in the 'HTTP Authentication Schemes' subregistry of the HTTP Authentication Scheme Registry (RFC 9110 Section 16.4), referencing RFC 9577 Section 2.
The Privacy Pass Token Types registry includes 17 reserved 'GREASE' values (0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F, 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057) with random-byte token/key/challenge structures to maintain extensibility.
Context-bound challenges force token issuance and redemption to occur close in time, enabling a colluding Issuer and Origin to correlate events. Clients MAY introduce delay between challenge receipt and token redemption (using max-age as a guide) to make timing linkability harder.
Context-bound tokens (non-empty redemption_context) should be discarded when flushing cookies or changing networks. Retaining and redeeming them in a new context allows the Origin to use the redemption context as a tracking cookie, linking otherwise-unlinkable sessions.
Cross-Origin tokens with empty contexts are vulnerable to token exhaustion: any Origin in the cross-Origin set can deplete the Client's token supply. Scoping tokens to single Origins via non-empty origin_info or client-side rate limits mitigates this. Token matching on origin_info requires exact string equality.
Cross-Origin tokens with empty redemption contexts can be reflected: an Attacker can relay a TokenChallenge from an Origin to a Client, receive the Client's token, and present it to the Origin as if it were the Client. Per-Origin challenges or non-empty redemption contexts mitigate this attack.
The default Token structure contains: token_type (2-octet uint16), nonce (32-octet Client-generated random), challenge_digest (32-octet SHA-256 hash of the original TokenChallenge), token_key_id (Nid-octet key identifier), and authenticator (Nk-octet value cryptographically bound to preceding fields). Nk and Nid are determined by token_type.
The TokenChallenge structure contains: token_type (2-octet uint16 in network byte order), issuer_name (ASCII string, length-prefixed with 2-octet uint16), redemption_context (0 or 32 bytes, prefixed with 1-octet length), and origin_info (ASCII string, length-prefixed with 2-octet uint16). Future token types MAY extend this structure.