The Privacy Pass HTTP Authentication Scheme

1.1. 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.¶

Unless otherwise specified, this document encodes protocol messages in TLS notation from [TLS13], Section 3.¶

This document uses the following terms to refer to various roles and functions in the Privacy Pass architecture:¶

• Client: A client is a application or device, generally operated by a user, that can be issued tokens via an issuance protocol, and can redeem these tokens with an origin.¶
• Origin: An HTTP server that acts as the relying party and can redeem tokens presented by a client. When used in a web context, this represents the origin the client is accessing.¶
• Token: A signed message that can be issued to a client and redeemed without allowing token redemption to be linked to issuance.¶
• Interactive / non-interactive token: An interactive token signs a nonce generated by an origin as part of a challenge for tokens. This means that the client needs to fetch a new token for this challenge in order to redeem it and cannot use a pre-fetched token. A non-interactive token is one that can be pre-fetched.¶
• Issuance protocol: A protocol by which the client fetches tokens. Every issuance protocol includes two functions: validating or authenticating the client, and issuing a token to the client.¶
• Issuer: An entity that generates tokens for clients using one or more issuance protocols. An Issuer is identified by an Issuer name.¶
• Issuer key: Keying material that can be used with an issuance protocol to create a signed token.¶
• Token challenge: A requirement for tokens sent from an origin to a client, using the "WWW-Authenticate" HTTP header. This may be a challenge for an interactive token or a non-interactive token. A challenge defines the issuance protocol and issuer name to use for a token.¶
• Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header.¶

2.1. Token Challenge

Origins send a token challenge to Clients in an "WWW-Authenticate" header with the "PrivateToken" scheme. This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer.¶

The TokenChallenge message has the following structure:¶

struct {
    uint16_t token_type;
    opaque issuer_name<1..2^16-1>;
    opaque redemption_nonce<0..32>;
    opaque origin_name<0..2^16-1>;
} TokenChallenge;

The structure fields are defined as follows:¶

• "token_type" is a 2-octet integer, in network byte order. This type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, Section 6.2. Challenges with unsupported token_type values MUST be ignored.¶
• "issuer_name" is a string containing the name of the issuer. This is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin.¶
• "redemption_nonce" is an optional field. If present, it indicates that a client needs to present an interactive token, generated specifically in response to this challenge. If empty, the client can use a non-interactive token. When present, this valid is a fresh 32-byte nonce generated by the origin for each challenge. Valid lengths for this field are either 0 or 32 bytes. Challenges with redemption_nonce values of invalid lengths MUST be ignored.¶
• "origin_name" is an optional string containing the name of the origin. This allows a token to be scoped to a specific origin. If empty, any non-origin specific token can be redeemed.¶

When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:¶

• "challenge", which contains a base64url-encoded [RFC4648] TokenChallenge value. Since the length of the challenge is not fixed, the base64url data MUST include padding. This MUST be unique for every 401 HTTP response to prevent replay attacks. This attribute is required for all challenges.¶
• "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url data MUST include padding. This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.¶
• "max-age", an optional attribute that consists of the number of seconds for which the challenge will be accepted by the Origin.¶

Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.¶

Origins MAY also include the standard "realm" attribute, if desired. Issuance protocols MAY require other attributes.¶

As an example, the WWW-Authenticate header could look like this:¶

WWW-Authenticate: PrivateToken challenge=abc..., token-key=123...

Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type. If the TokenChallenge has a token_type the client does not recognize or support, it MUST NOT parse or respond to the challenge.¶

Note that it is possible for the WWW-Authenticate header to include multiple challenges, in order to allow the Client to fetch a batch of multiple tokens for future use.¶

For example, the WWW-Authenticate header could look like this:¶

WWW-Authenticate: PrivateToken challenge=abc..., token-key=123...,
PrivateToken challenge=def..., token-key=234...

2.2. Token Redemption

The output of the issuance protocol is a token that corresponds to the origin's challenge (see Section 2.1). A token is a structure that begins with a two-octet field that indicates a token type, which MUST match the token_type in the TokenChallenge structure.¶

struct {
    uint16_t token_type;
    uint8_t nonce[32];
    uint8_t context[32];
    uint8_t token_key_id[Nid];
    uint8_t authenticator[Nk];
} Token;

The structure fields are defined as follows:¶

• "token_type" is a 2-octet integer, in network byte order. This value must match the value in the challenge (Section 2.1).¶
• "nonce" is a 32-octet message containing a client-generated random nonce.¶
• "context" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge).¶
• "token_key_id" is an Nid-octet identifier for the the token authentication key. The value of this field is defined by the token_type and corresponding issuance protocol.¶
• "authenticator" is a Nk-octet authenticator that covers the preceding fields in the token. The value of this field is defined by the token_type and corresponding issuance protocol.¶

The authenticator value in the Token structure is computed over the token_type, nonce, context, and token_key_id fields.¶

When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Token struct. Since the length of the Token struct is not fixed, the base64url data MUST include padding. All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored.¶

Clients present this Token structure to Origins in a new HTTP request using the Authorization header as follows:¶

Authorization: PrivateToken token=abc...

For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce and the hash of a valid TokenChallenge. For interactive tokens, origins store the nonces of previous TokenChallenge structures in order to validate uniqueness. A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions. For non-interactive tokens, origins SHOULD implement some form of double spend prevention that prevents a token with the same nonce from being redeemed twice. This prevents clients from "replaying" tokens for previous challenges.¶

If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response.¶

6.1. Authentication Scheme

This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established by [RFC7235].¶

Authentication Scheme Name: PrivateToken¶

Pointer to specification text: Section 2 of this document¶

6.2. Token Type Registry

The "Token Type" registry lists identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535.¶

Template:¶

• Value: The two-byte identifier for the algorithm¶
• Name: Name of the issuance protocol¶
• Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable¶
• Public Metadata: A Y/N value indicating if the output tokens can contain public metadata.¶
• Private Metadata: A Y/N value indicating if the output tokens can contain private metadata.¶
• Nk: The length in bytes of an output authenticator¶
• Nid: The length of the token key identifier¶
• Reference: Where this algorithm is defined¶

The initial contents for this registry are defined in the table below.¶