]> Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America tpauly@apple.com

Google LLC

svaldez@chromium.org

Cloudflare

caw@heapingbits.net

anonymous authorization crypto This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme in this document can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present Privacy Pass tokens.

Introduction Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client (see ). Tokens are generated by token issuers, on the basis of authentication, attestation, or some previous action such as solving a CAPTCHA. A client possessing such a token is able to prove that it was able to get a token issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow. Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. This document defines a common HTTP authentication scheme (), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. Clients and relying parties (origins) interact using this scheme to perform the token challenge and token redemption flow. In particular, origins challenge clients for a token with an HTTP Authentication challenge (using the WWW-Authenticate response header field). Clients can then react to that challenge by issuing a new request with a corresponding token (using the Authorization request header field). Clients generate tokens that match the origin's token challenge by running the token issuance protocol . The act of presenting a token in an Authorization request header field is referred to as token redemption. This interaction between client and origin is shown below.

Challenge and redemption protocol flow | | | | (Run issuance protocol) | | |<------ Authorization: Token ----------+ | | ]]>

In addition to working with different token issuance protocols, this scheme optionally supports use of tokens that are associated with origin-chosen contexts and specific origin names. Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case. These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens.

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 when, and only when, they appear in all capitals, as shown here. Unless otherwise specified, this document encodes protocol messages in TLS notation from , Section 3. This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in . It additionally uses the following terms in more specific ways:

• Issuer key: Keying material that can be used with an issuance protocol to create a signed token.
• Token challenge: A request for tokens sent from an origin to a client, using the "WWW-Authenticate" HTTP header field. This challenge identifies a specific token issuer and issuance protocol. Token challenges optionally include one or both of: a redemption context (see ), and a list of associated origins. These optional values are then be bound to the token that is issued.
• Token redemption: An action by which a client presents a token to an origin in an HTTP request, using the "Authorization" HTTP header field.

HTTP Authentication Scheme Token redemption is performed using HTTP Authentication (), with the scheme "PrivateToken". Origins challenge clients to present a token from a specific issuer (). Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (). The process of presenting a token as authentication to an origin is also referred to as "spending" a token. In order to prevent linkability across different transactions, clients will often present a particular "PrivateToken" only once. Origins can link multiple transactions to the same client if that client spends the same token value more than once. As such, origins ought to expect at most one unique token value, carried in one request, for each challenge. The rest of this section describes the token challenge and redemption interactions in more detail.

Token Challenge Origins send a token challenge to clients in an "WWW-Authenticate" header field with the "PrivateToken" scheme. This authentication scheme has two mandatory parameters: one containing a token challenge and another containing the token-key used for producing (and verifying) a corresponding token. Origins that support the "PrivateToken" authentication scheme need to handle the following tasks in constructing the WWW-Authenticate header field:

1. Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate token challenges. The issuer name is included in the token challenge, and the issuer token-key is used to populate the WWW-Authenticate header parameter.
2. Determine a redemption context construction to include in the token challenge, as discussed in .
3. Select the origin information to include in the token challenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself for per-origin tokens, or a list of origin names containing the origin itself. See for more information about the difference between cross-origin and per-origin tokens.

Once these decisions are made, origins construct the WWW-Authenticate header by first constructing the token challenge as described in . Origins send challenges as described in , and clients process them as described in and .

Token Challenge Structure This document defines the default challenge structure that can be used across token types, although future token types MAY extend or modify the structure of the challenge; see for the registry information which establishes and defines the relationship between "token_type" and the contents of the TokenChallenge message. All token challenges MUST begin with a 2-octet integer that defines the token type, in network byte order. This type indicates the issuance protocol used to generate the token and determines the structure and semantics of the rest of the structure. Values are registered in an IANA registry, . Client MUST ignore challenges with token types they do not support. Even when a given token type uses the default challenge structure, the requirements on the presence or interpretation of the fields can differ across token types. For example, some token types might require that "origin_info" is non-empty, while others allow it to be empty. The default TokenChallenge message has the following structure: ; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; } TokenChallenge; ]]> The structure fields are defined as follows:

• "token_type" is a 2-octet integer, in network byte order, as described above.
• "issuer_name" is an ASCII string that identifies the issuer using the format of a server name defined in . This name identifies the issuer that is allowed to issue tokens that can be redeemed by this origin. The field that stores this string in the challenge is prefixed with a 2-octet integer indicating the length, in network byte order.
• "redemption_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 tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts. See for example contexts that might be useful in practice. Challenges with redemption_context values of invalid lengths MUST be ignored.
• "origin_info" is an ASCII string that is either empty, or contains one or more origin names that allow a token to be scoped to a specific set of origins. Each origin name uses the format of a server name defined in . The string is prefixed with a 2-octet integer indicating the length, in network byte order. If empty, any non-origin-specific token can be redeemed. If the string contains multiple origin names, they are delimited with commas "," without any whitespace. If this field is not empty, the Origin MUST include its own name as one of the names in the list.

If "origin_info" contains multiple origin names, this means the challenge is valid for any of the origins in the list, including the origin which issued the challenge (which must always be present in the list if it is non-empty; see ). This can be useful in settings where clients pre-fetch and cache tokens for a particular challenge -- including the "origin_info" field -- and then later redeem these tokens with one of the origins in the list. See for more discussion about token caching.

Server Name Encoding Server names contained in a token challenge are ASCII strings that contain a hostname and optional port, where the port is implied to be "443" if missing. The names use the format of the authority portion of a URI as defined in . The names MUST NOT include a "userinfo" portion of an authority. For example, a valid server name might be "issuer.example.com" or "issuer.example.com:8443", but not "issuer@example.com".

Redemption Context Construction The TokenChallenge redemption context allows the origin to determine the context in which a given token can be redeemed. This value can be a unique per-request nonce, constructed from 32 freshly generated random bytes. It can also represent state or properties of the client session. Some example properties and methods for constructing the corresponding context are below. This list is not exhaustive.

• Context bound to a given time window: Construct redemption context as F(current time window), where F is a pseudorandom function.
• Context bound to a client network: Construct redemption context as F(client ASN), where F is a pseudorandom function.
• Context bound to a given time window and client network: Construct redemption context as F(current time window, client ASN), where F is a pseudorandom function.

Preventing double spending on tokens requires the origin to keep state associated with the redemption context. An empty redemption context is not bound to any property of the client request, so state to prevent double spending needs to be stored and shared across all origin servers that can accept tokens until token-key expiration or rotation. For a non-empty redemption context, the double spend state only needs to be stored across the set of origin servers that will accept tokens with that redemption context. Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention. Origins should consider the operational complexity of this shared state before choosing to share redemption contexts. Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context.

Sending Token Challenges When used in an authentication challenge, the "PrivateToken" scheme uses the following parameters:

• "challenge", which contains a base64url-encoded TokenChallenge value. This document follows the default padding behavior described in , so the base64url value MUST include padding. As an Authentication Parameter (auth-param from ), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. This parameter 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. See for more information about how this public key is used by the issuance protocols in that specification. The encoding of the public key is determined by the token type; see . As with "challenge", the base64url value MUST include padding. As an Authentication Parameter (auth-param from ), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. This parameter MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.
• "max-age", an optional parameter that consists of the number of seconds for which the challenge will be accepted by the origin.

The header field MAY also include the standard "realm" parameter, if desired. Issuance protocols MAY define other parameters, some of which might be required. Clients MUST ignore parameters in challenges that are not defined for the issuance protocol corresponding to the token type in the challenge. As an example, the WWW-Authenticate header field could look like this:

Sending Multiple Token Challenges It is possible for the WWW-Authenticate header field to include multiple challenges (). This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts. For example, the WWW-Authenticate header field could look like this: Origins should only include challenges for different types of issuance protocols with functionally equivalent properties. For instance, both issuance protocols in have the same functional properties, albeit with different mechanisms for verifying the resulting tokens during redemption. Since clients are free to choose which challenge they want to consume when presented with options, mixing multiple challenges with different functional properties for one use case is nonsensical. If the origin has a preference for one challenge over another (for example, if one uses a token type that is faster to verify), it can sort it to be first in the list of challenges as a hint to the client.

Processing Token Challenges Upon receipt of a challenge, a client validates the TokenChallenge structure before taking any action, such as fetching a new token or redeeming a token in a new request. Validation requirements are as follows:

• The token_type is recognized and supported by the client;
• The TokenChallenge structure is well-formed; and
• If the origin_info field is non-empty, the name of the origin that issued the authentication challenge is included in the list of origin names. Comparison of the origin name that issued the authentication challenge against elements in the origin_info list is done via case-insensitive equality checks.

If validation fails, the client MUST NOT fetch or redeem a token based on the challenge. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to ignore challenges that list origin names for which the current connection is not authoritative (according to the TLS certificate). Caching and pre-fetching of tokens is discussed in .

Token Caching Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use. This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol. Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match. Note that each token has a unique client nonce, which is sent in token redemption (). If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies , or if there is a network change and the client does not have any origin-specific state like HTTP cookies. Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client.

Token Redemption The output of the issuance protocol is a token that corresponds to the origin's challenge (see ).

Token Structure 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. This value determines the structure and semantics of the rest of token structure. This document defines the default token structure that can be used across token types, although future token types MAY extend or modify the structure of the token; see for the registry information which establishes and defines the relationship between "token_type" and the contents of the Token structure. The default Token message has the following structure: The structure fields are defined as follows:

• "token_type" is a 2-octet integer, in network byte order, as described above.
• "nonce" is a 32-octet value containing a client-generated random nonce.
• "challenge_digest" is a 32-octet value containing the hash of the original TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as defined in . Changing the hash function to something other than SHA-256 would require defining a new token type and token structure (since the contents of challenge_digest would be computed differently), which can be done in a future specification.
• "token_key_id" is a Nid-octet identifier for 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 is cryptographically bound to the preceding fields in the token; see for more information about how this field is used in verifying a token. The token_type and corresponding issuance protocol determine the value of the authenticator field and how it is computed. The value of constant Nk depends on token_type, as defined in .

The authenticator value in the Token structure is computed over the token_type, nonce, challenge_digest, and token_key_id fields. A token is considered a valid if token verification using succeeds; see for details about verifying the token and its authenticator value.

Sending Tokens When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Token struct. As with the challenge parameters (), the base64url value MUST include padding. As an Authentication Parameter (auth-param from ), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. 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 field as follows: For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token. A TokenChallenge can be bound to a specific TLS session with a client, but origins can also accept tokens for valid challenges in new sessions. Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice. Double-spend prevention ensures that clients cannot replay tokens for previous challenges. See for more information about replay attacks. For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness.

Token Verification A token consists of some input cryptographically bound to an authenticator value, such as a digital signature. Verifying a token consists of checking that the authenticator value is correct. The authenticator value is as computed when running and finalizing the issuance protocol corresponding to the token type with the following value as the input: The value of these fields are as described in . The cryptographic verification check depends on the token type; see and for verification instructions for the issuance protocols described in . As such, the security properties of the token, e.g., the probability that one can forge an authenticator value without invoking the issuance protocol, depend on the cryptographic algorithm used by the issuance protocol as determined by the token type.

Client Behavior When a client receives one or more token challenges in response to a request, the client has a set of choices to make:

• Whether or not to redeem a token via a new request to the origin.
• Whether to redeem a previously issued and cached token, or redeem a token freshly issued from the issuance protocol.
• If multiple challenges were sent, which challenge to use for redeeming a token on a subsequent request.

The approach to these choices depends on the use case of the application, as well as the deployment model (see for discussion of the different deployment models).

Choosing to Redeem Tokens Some applications of tokens might require clients to always present a token as authentication in order to successfully make requests. For example, a restricted service that wants to only allow access to valid users, but do so without learning specific user credential information, could use tokens that are based on attesting user credentials. In these kinds of use cases, clients will need to always redeem a token in order to successfully make a request. Many other use cases for Privacy Pass tokens involve open services that must work with any client, including those that either cannot redeem tokens, or can only sometimes redeem tokens. For example, a service can use tokens as a way to reduce the incidence of presenting CAPTCHAs to users. In such use cases, services will regularly encounter clients that cannot redeem a token or choose not to. In order to mitigate the risk of these services relying on always receiving tokens, clients that are capable of redeeming tokens can ignore token challenges (and instead behave as if they were a client that either doesn't support redeeming tokens or is unable to generate a new token, by not sending a new request that contains a token to redeem) with some non-trivial probability. See for further considerations on avoiding discriminatory behavior across clients when using Privacy Pass tokens. Clients might also choose to not redeem tokens in subsequent requests when the token challenges indicate erroneous or malicious behavior on the part of the challenging origin. For example, if a client's ability to generate tokens via an attester and issuer is limited to a certain rate, a malicious origin could send an excessive number of token challenges with unique redemption contexts in order to cause the client to exhaust its ability to generate new tokens, or to overwhelm issuance servers. The limits here will vary based on the specific deployment, but clients SHOULD have some implementation-specific policy to minimize the number of tokens that can be retrieved by origins.

Choosing Between Multiple Challenges A single response from an origin can include multiple token challenges. For example, a set of challenges could include different token types and issuers, to allow clients to choose a preferred issuer or type. The choice of which challenge to use for redeeming tokens is up to client policy. This can involve which token types are supported or preferred, which issuers are supported or preferred, or whether or not the client is able to use cached tokens based on the redemption context or origin information in the challenge. See for more discussion on token caching. Regardless of how the choice is made, it SHOULD be done in a consistent manner to ensure that the choice does not reveal information about the specific client; see for more details on the privacy implications of issuance consistency.

Origin Behavior Origins choose what token challenges to send to clients, which will vary depending on the use case and deployment model. The origin chooses which token types, issuers, redemption contexts, and origin info to include in challenges. If an origin sends multiple challenges, each challenge SHOULD be equivalent in terms of acceptability for token redemption, since clients are free to choose to generate tokens based on any of the challenges. Origins ought to consider the time involved in token issuance. Particularly, a challenge that includes a unique redemption context will prevent a client from using cached tokens, and thus can add more delay before the client is able to redeem a token. Origins SHOULD minimize the number of challenges sent to a particular client context (referred to as the "redemption context" in ), to avoid overwhelming clients and issuers with token requests that might cause clients to hit rate limits.

Greasing In order to prevent clients becoming incompatible with new token challenges, origins SHOULD include random token types, from the Reserved list of "greased" types (defined in ), with some non-trivial probability. Additionally, for deployments where tokens are not required (such as when tokens are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly
 choose to not challenge clients for tokens with some non-trivial probability. This helps origins ensure that their behavior for handling clients that cannot redeem tokens is maintained and exercised consistently.

Security Considerations This section contains security considerations for the PrivateToken authentication scheme described in this document.

Randomness Requirements All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness ().

Replay Attacks Applications SHOULD constrain tokens to a single origin unless the use case can accommodate replay attacks. Replaying tokens is not necessarily a security or privacy problem. As an example, it is reasonable for clients to replay tokens in contexts where token redemption does not induce side effects and in which client requests are already linkable. One possible setting where this applies is where tokens are sent as part of 0-RTT data. If successful token redemption produces side effects, origins SHOULD implement an anti-replay mechanism to mitigate the harm of such replays. See and for details about anti-replay mechanisms, as well as for discussion about safety considerations for 0-RTT HTTP data.

Reflection Attacks The security properties of token challenges vary depending on whether the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not. For example, cross-origin tokens with empty contexts can be reflected from one party by another, as shown below.

Replay attack example | | | +-- (reflect challenge) ->| | |<-------- Token ---------+ |<-- (reflect token) -+ | | | ]]>

Token Exhaustion Attacks When a Client holds cross-origin tokens with empty contexts, it is possible for any Origin in the cross-origin set to deplete that Client set of tokens. To prevent this from happening, tokens can be scoped to single Origins (with non-empty origin_info) such that they can only be redeemed for a single Origin. Alternatively, if tokens are cross-Origin, Clients can use alternate methods to prevent many tokens from being redeemed at once. For example, if the Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already occurred in a given time window. Token challenges that include non-empty origin_info bind tokens to one or more specific origins. As described in , clients only accept such challenges from origin names listed in the origin_info string. Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has a match for the origin_info. For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com". On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token.

Timing Correlation Attacks Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past. This can make it more likely that issuance and redemption events will occur at approximately the same time. For example, if a client is challenged for a token with a unique context at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client. This linkability is less feasible as the number of issuance events at time T2 increases. Depending on the "max-age" token challenge parameter, clients MAY try to add delay to the time between being challenged and redeeming a token to make this sort of linkability more difficult. For more discussion on correlation risks between token issuance and redemption, see .

Cross-Context Linkability Attacks As discussed in , clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an origin using the redemption context state as a cookie to recognize clients.

IANA Considerations

Authentication Scheme This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined in .

Authentication Scheme Name:

PrivateToken

Pointer to specification text:

of this document

Token Type Registry IANA is requested to create a new "Privacy Pass Token Type" registry in a new "Privacy Pass Parameters" page to list 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. New registrations need to list the following attributes:

Value:

The two-byte identifier for the algorithm

Name:

Name of the issuance protocol

Token Structure:

The contents of the Token structure in

Token Key Encoding:

The encoding of the "token-key" parameter in

TokenChallenge Structure:

The contents of the TokenChallenge structure in

Public Verifiability:

A Y/N value indicating if the output tokens have the public verifiability property; see for more details about this property.

Public Metadata:

A Y/N value indicating if the output tokens can contain public metadata; see for more details about this property.

Private Metadata:

A Y/N value indicating if the output tokens can contain private metadata; see for more details about this property.

Nk:

The length in bytes of an output authenticator

Nid:

The length of the token key identifier

Reference:

Where this algorithm is defined

Notes:

Any notes associated with the entry

New entries in this registry are subject to the Specification Required registration policy (). Designated experts need to ensure that the token type is defined to be used for both token issuance and redemption. Additionally, the experts can reject registrations on the basis that they do not meet the security and privacy requirements for issuance protocols defined in . defines entries for this registry.

Reserved Values This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and redemptions to ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by ). Implementations SHOULD select reserved values at random when including them in greased messages. Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values. Clients can include these in Token structures when they are not able to present a real token. The contents of the Token structure SHOULD be filled with random bytes when using greased values. The initial contents for this registry consists of multiple reserved values, with the following attributes, which are repeated for each registration:

Value:

0x0000, 0x02AA, 0x1132, 0x2E96, 0x3CD3, 0x4473, 0x5A63, 0x6D32, 0x7F3F, 0x8D07, 0x916B, 0xA6A4, 0xBEAB, 0xC3F3, 0xDA42, 0xE944, 0xF057

Name:

RESERVED

Token Structure:

Random bytes

Token Key Encoding:

Random bytes

TokenChallenge Structure:

Random bytes

Publicly Verifiable:

N/A

Public Metadata:

N/A

Private Metadata:

N/A

Nk:

N/A

Nid:

N/A

Reference:

This document

Notes:

None

References Normative References LIP Fastly Cloudflare This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model that helps ensure the desired security and privacy goals are fulfilled. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] National Institute of Standards and Technology Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Brave Software Brave Software Google LLC Cloudflare This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. Google LLC Google LLC Apple, Inc This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes how Transport Layer Security (TLS) is used to secure QUIC. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

Test Vectors This section includes test vectors for the HTTP authentication scheme specified in this document. It consists of the following types of test vectors:

1. Test vectors for the challenge and redemption protocols. Implementations can use these test vectors for verifying code that builds and encodes TokenChallenge structures, as well as code that produces a well-formed Token bound to a TokenChallenge.
2. Test vectors for the HTTP headers used for authentication. Implementations can use these test vectors for validating whether they parse HTTP authentication headers correctly to produce TokenChallenge structures and the other associated parameters, such as the token-key and max-age values.

Challenge and Redemption Structure Test Vectors This section includes test vectors for the challenge and redemption functionalities described in and . Each test vector lists the following values:

• token_type: The type of token issuance protocol, a value from . For these test vectors, token_type is 0x0002, corresponding to the issuance protocol in .
• issuer_name: The name of the issuer in the TokenChallenge structure, represented as a hexadecimal string.
• redemption_context: The redemption context in the TokenChallenge structure, represented as a hexadecimal string.
• origin_info: The origin info in the TokenChallenge structure, represented as a hexadecimal string.
• nonce: The nonce in the Token structure, represented as a hexadecimal string.
• token_key: The public token-key, encoded based on the corresponding token type, represented as a hexadecimal string.
• token_authenticator_input: The values in the Token structure used to compute the Token authenticator value, represented as a hexadecimal string.

Test vectors are provided for each of the following TokenChallenge configurations:

1. TokenChallenge with a single origin and non-empty redemption context
2. TokenChallenge with a single origin and empty redemption context
3. TokenChallenge with an empty origin and redemption context
4. TokenChallenge with an empty origin and non-empty redemption context
5. TokenChallenge with a multiple origins and non-empty redemption context

These test vectors are below.

HTTP Header Test Vectors This section includes test vectors the contents of the HTTP authentication headers. Each test vector consists of one or more challenges that comprise a WWW-Authenticate header. For each challenge, the token-type, token-key, max-age, and token-challenge parameters are listed. Each challenge also includes an unknown (not specified) parameter that implementations are meant to ignore. The parameters for each challenge are indexed by their position in the WWW-Authentication challenge list. For example, token-key-0 denotes the token-key parameter for the first challenge in the list, whereas token-key-1 denotes the token-key for the second challenge in the list. The resulting wire-encoded WWW-Authentication header based on this list of challenges is then listed at the end. Line folding is only used to fit the document formatting constraints and not unsupported in actual requests.