doc: Add RFC documents

1 files changed, 1262 insertions, 0 deletions

diff --git a/doc/rfc/rfc9577.txt b/doc/rfc/rfc9577.txt
new file mode 100644
index 0000000..84b8190
--- /dev/null
+++ b/doc/rfc/rfc9577.txt
@@ -0,0 +1,1262 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          T. Pauly
+Request for Comments: 9577                                    Apple Inc.
+Category: Standards Track                                      S. Valdez
+ISSN: 2070-1721                                               Google LLC
+                                                              C. A. Wood
+                                                              Cloudflare
+                                                               June 2024
+
+
+              The Privacy Pass HTTP Authentication Scheme
+
+Abstract
+
+   This document defines an HTTP authentication scheme for Privacy Pass,
+   a privacy-preserving authentication mechanism used for authorization.
+   The authentication scheme specified 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9577.
+
+Copyright Notice
+
+   Copyright (c) 2024 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
+     1.1.  Terminology
+   2.  HTTP Authentication Scheme
+     2.1.  Token Challenge
+       2.1.1.  Token Challenge Structure
+       2.1.2.  Sending Token Challenges
+       2.1.3.  Processing Token Challenges
+       2.1.4.  Token Caching
+     2.2.  Token Redemption
+       2.2.1.  Token Structure
+       2.2.2.  Sending Tokens
+       2.2.3.  Token Verification
+   3.  Client Behavior
+     3.1.  Choosing to Redeem Tokens
+     3.2.  Choosing between Multiple Challenges
+   4.  Origin Behavior
+     4.1.  Greasing
+   5.  Security Considerations
+     5.1.  Randomness Requirements
+     5.2.  Replay Attacks
+     5.3.  Reflection Attacks
+     5.4.  Token Exhaustion Attacks
+     5.5.  Timing Correlation Attacks
+     5.6.  Cross-Context Linkability Attacks
+   6.  IANA Considerations
+     6.1.  Authentication Scheme
+     6.2.  Privacy Pass Token Types Registry
+       6.2.1.  Reserved Values
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Test Vectors
+     A.1.  Challenge and Redemption Structure Test Vectors
+     A.2.  HTTP Header Test Vectors
+   Authors' Addresses
+
+1.  Introduction
+
+   Privacy Pass tokens are unlinkable authenticators that can be used to
+   anonymously authorize a Client (see [ARCHITECTURE]).  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 ([HTTP],
+   Section 11), "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 one of the token issuance protocols defined in
+   [ISSUANCE].  The act of presenting a token in an Authorization
+   request header field is referred to as "token redemption".  This
+   interaction between the Client and Origin is shown below.
+
+   +--------+                              +--------+
+   | Origin |                              | Client |
+   +---+----+                              +---+----+
+       |                                       |
+       +-- WWW-Authenticate: TokenChallenge -->|
+       |                                       |
+       |                            (Run issuance protocol)
+       |                                       |
+       |<------ Authorization: token ----------+
+       |                                       |
+
+              Figure 1: Challenge and Redemption Protocol Flow
+
+   In addition to working with different token issuance protocols, this
+   scheme optionally supports the 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 (1) allow for
+   different deployment models to prevent double-spending and (2) allow
+   for both interactive (online challenges) and non-interactive (pre-
+   fetched) tokens.
+
+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 terms "Client", "Origin", "Issuer", "issuance
+   protocol", and "Token" as defined in [ARCHITECTURE].  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 the
+      following: a redemption context (see Section 2.1.1.2) and a list
+      of associated Origins.  These optional values can 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.
+
+2.  HTTP Authentication Scheme
+
+   Token redemption is performed using HTTP authentication ([HTTP],
+   Section 11), with the scheme "PrivateToken".  Origins challenge
+   Clients to present a token from a specific Issuer (Section 2.1).
+   Once a Client has received a token from that Issuer or already has a
+   valid token available, it presents the token to the Origin
+   (Section 2.2).  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.
+
+2.1.  Token Challenge
+
+   Origins send a token challenge to Clients in a 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 Section 2.1.1.2.
+
+   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
+       Section 3.4 of [ARCHITECTURE] 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
+   Section 2.1.1.  Origins send challenges as described in
+   Section 2.1.2, and Clients process them as described in
+   Sections 2.1.3 and 2.1.4.
+
+2.1.1.  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 Section 6.2 for the
+   registry information that 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; see Section 6.2.  Clients 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:
+
+   struct {
+       uint16_t token_type;
+       opaque issuer_name<1..2^16-1>;
+       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 as defined in Section 2.1.1.1.  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 the 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 Section 2.1.1.2 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 either is 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 as defined in Section 2.1.1.1.  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 that issued the challenge (which must always be present in the
+   list if it is non-empty; see Section 2.1.3).  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 Section 2.1.4
+   for more discussion about token caching.
+
+2.1.1.1.  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 Section 3.2 of [URI].  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".
+
+2.1.1.2.  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 the redemption
+      context as F(current time window), where F is a pseudorandom
+      function.
+
+   Context bound to a Client network based on Autonomous System
+   Number (ASN):  Construct the redemption context as F(Client ASN),
+      where F is a pseudorandom function.
+
+   Context bound to a given time window and Client network:  Construct
+      the 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.
+
+2.1.2.  Sending Token Challenges
+
+   When used in an authentication challenge, the "PrivateToken" scheme
+   uses the following parameters:
+
+   *  challenge, which contains a base64url TokenChallenge value,
+      encoded per [RFC4648].  This document follows the default padding
+      behavior described in Section 3.2 of [RFC4648], so the base64url
+      value MUST include padding.  As an authentication parameter (auth-
+      param from [HTTP], Section 11.2), 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 [ISSUANCE] for more information about how this public key is
+      used by the issuance protocols described in that specification.
+      The encoding of the public key is determined by the token type;
+      see Section 6.2.  As with challenge, the base64url value MUST
+      include padding.  As an authentication parameter (auth-param from
+      [HTTP], Section 11.2), 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, which is 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:
+
+   WWW-Authenticate:
+     PrivateToken challenge="abc...", token-key="123..."
+
+2.1.2.1.  Sending Multiple Token Challenges
+
+   It is possible for the WWW-Authenticate header field to include
+   multiple challenges ([HTTP], Section 11.6.1).  This allows the Origin
+   to indicate support for different token types or different Issuers,
+   or to include multiple redemption contexts.  For example, the WWW-
+   Authenticate header field could look like this:
+
+   WWW-Authenticate:
+     PrivateToken challenge="abc...", token-key="123...",
+     PrivateToken challenge="def...", token-key="234..."
+
+   Origins should only include challenges for different types of
+   issuance protocols with functionally equivalent properties.  For
+   instance, both issuance protocols in [ISSUANCE] 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.
+
+2.1.3.  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 are discussed in Section 2.1.4.
+
+2.1.4.  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 the 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 (Section 2.2).
+
+   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 [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.
+
+2.2.  Token Redemption
+
+   The output of the issuance protocol is a token that corresponds to
+   the Origin's challenge (see Section 2.1).
+
+2.2.1.  Token Structure
+
+   A token is a structure that begins with a 2-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 the 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 Section 6.2 for the registry
+   information that establishes and defines the relationship between
+   token_type and the contents of the token structure.
+
+   The default token message has the following structure:
+
+   struct {
+       uint16_t token_type;
+       uint8_t nonce[32];
+       uint8_t challenge_digest[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, 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 [SHS].  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
+      Section 2.2.3 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 Section 6.2.
+
+   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 valid if token verification succeeds; see
+   Section 2.2.3 for details about verifying the token and its
+   authenticator value.
+
+2.2.2.  Sending Tokens
+
+   When used for Client authorization, the "PrivateToken" authentication
+   scheme defines one parameter, token, which contains the base64url-
+   encoded token structure.  As with the challenge parameters
+   (Section 2.1), the base64url value MUST include padding.  As an
+   authentication parameter (auth-param from [HTTP], Section 11.2), 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:
+
+   Authorization: PrivateToken token="abc..."
+
+   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 Section 5.2 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.
+
+2.2.3.  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 values as the input:
+
+   struct {
+       uint16_t token_type;
+       uint8_t nonce[32];
+       uint8_t challenge_digest[32];
+       uint8_t token_key_id[Nid];
+   } AuthenticatorInput;
+
+   The values of these fields are as described in Section 2.2.1.  The
+   cryptographic verification check depends on the token type; see
+   Sections 5.4 and 6.4 of [ISSUANCE] for verification instructions for
+   the issuance protocols described in that specification.  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.
+
+3.  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 Section 4 of
+   [ARCHITECTURE] for discussion of the different deployment models).
+
+3.1.  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 wants to 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 Section 5.1 of
+   [ARCHITECTURE] for further considerations regarding 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
+   (1) cause the Client to exhaust its ability to generate new tokens or
+   (2) overwhelm issuance servers.  Based on the specific deployment,
+   the limits here will vary, but Clients SHOULD have some
+   implementation-specific policy to minimize the number of tokens that
+   can be retrieved by Origins.
+
+3.2.  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.
+
+   If Clients choose to respond, Clients should satisfy exactly one of
+   the challenges presented.  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 Section 2.1.4 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 Section 6.2 of
+   [ARCHITECTURE] for more details on the privacy implications of
+   issuance consistency.
+
+4.  Origin Behavior
+
+   Origins choose what token challenges to send to Clients; these token
+   challenges will vary, depending on the use case and deployment model.
+   The Origin chooses which token types, Issuers, redemption contexts,
+   and Origin information 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
+   Section 3.3 of [ARCHITECTURE]), to avoid overwhelming Clients and
+   Issuers with token requests that might cause Clients to hit rate
+   limits.
+
+4.1.  Greasing
+
+   In order to prevent Clients from becoming incompatible with new token
+   challenges, Origins SHOULD include random token types, from the
+   reserved list of "greased" types (defined in Section 6.2), with some
+   non-trivial probability.
+
+   Additionally, for deployments where tokens are not required (such as
+   when tokens are used as a way to avoid 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.
+
+5.  Security Considerations
+
+   This section contains security considerations for the "PrivateToken"
+   authentication scheme described in this document.
+
+5.1.  Randomness Requirements
+
+   All random values in the challenge and token MUST be generated using
+   a cryptographically secure source of randomness [RFC4086].
+
+5.2.  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 [TLS13], Section 8 and [RFC9001], Section 9.2 for
+   details about anti-replay mechanisms, as well as [RFC8470], Section 3
+   for discussion about safety considerations for 0-RTT HTTP data.
+
+5.3.  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 a per-Origin challenge or not.  For
+   example, cross-Origin tokens with empty contexts can be reflected
+   from one party by another, as shown below.
+
+   +--------+            +----------+                +--------+
+   | Origin |            | Attacker |                | Client |
+   +---+----+            +----+-----+                +---+----+
+       |                      |                          |
+       +--- TokenChallenge -->|                          |
+       |                      +-- (reflect challenge) -->|
+       |                      |<-------- Token ----------+
+       |<-- (reflect token) --+                          |
+       |                      |                          |
+
+                    Figure 2: Reflection Attack Example
+
+5.4.  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's 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 tokens, 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 Section 2.1.3, Clients
+   only accept such challenges from Origin names listed in the
+   origin_info string if it is non-empty.  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", "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.
+
+5.5.  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 Section 6.3 of [ARCHITECTURE].
+
+5.6.  Cross-Context Linkability Attacks
+
+   As discussed in Section 2.1, Clients SHOULD discard any context-bound
+   tokens upon flushing cookies or changing networks, to prevent an
+   Origin from using the redemption context state as a cookie to
+   recognize Clients.
+
+6.  IANA Considerations
+
+6.1.  Authentication Scheme
+
+   IANA has registered the "PrivateToken" authentication scheme in the
+   "HTTP Authentication Schemes" subregistry of the "Hypertext Transfer
+   Protocol (HTTP) Authentication Scheme Registry" as defined in [HTTP],
+   Section 16.4.
+
+   Authentication Scheme Name:  PrivateToken
+
+   Reference:  RFC 9577, Section 2
+
+6.2.  Privacy Pass Token Types Registry
+
+   IANA has created a new "Privacy Pass Token Types" registry in a new
+   "Privacy Pass" page to list identifiers for issuance protocols
+   defined for use with the Privacy Pass token authentication scheme.
+   These identifiers are 2-byte values, so the maximum possible value is
+   0xFFFF = 65535.
+
+   New registrations need to list the following attributes:
+
+   Value:  The 2-byte identifier for the algorithm.
+   Name:  Name of the issuance protocol.
+   Token Structure:  The contents of the token structure; see
+      Section 2.2.
+   Token Key Encoding:  The encoding of the token-key parameter; see
+      Section 2.1.2.
+   TokenChallenge Structure:  The contents of the TokenChallenge
+      structure; see Section 2.1.
+   Publicly Verifiable:  A Y/N value indicating if the output tokens
+      have the public verifiability property; see Section 3.5 of
+      [ARCHITECTURE] for more details about this property.
+   Public Metadata:  A Y/N value indicating if the output tokens can
+      contain public metadata; see Section 3.5 of [ARCHITECTURE] for
+      more details about this property.
+   Private Metadata:  A Y/N value indicating if the output tokens can
+      contain private metadata; see Section 3.5 of [ARCHITECTURE] for
+      more details about this property.
+   Nk:  The length in bytes of an output authenticator.
+   Nid:  The length of the token key identifier.
+   Change Controller:  The entity that is responsible for the definition
+      of the registration.
+   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 ([RFC8126], Section 4.6).  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
+   Section 3.2 of [ARCHITECTURE].
+
+   [ISSUANCE] defines entries for this registry.
+
+6.2.1.  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
+   [RFC8701]).  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 of this registry consist 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
+   Change Controller:  IETF
+   Reference:  RFC 9577
+   Notes:  None
+
+7.  References
+
+7.1.  Normative References
+
+   [ARCHITECTURE]
+              Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
+              Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
+              2024, <https://www.rfc-editor.org/info/rfc9576>.
+
+   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [SHS]      National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", NIST FIPS Publication 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://doi.org/10.6028/nist.fips.180-4>.
+
+   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+7.2.  Informative References
+
+   [COOKIES]  Bingler, S., Ed., West, M., Ed., and J. Wilander, Ed.,
+              "Cookies: HTTP State Management Mechanism", Work in
+              Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-
+              14, 2 May 2024, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-httpbis-rfc6265bis-14>.
+
+   [ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
+              "Privacy Pass Issuance Protocols", RFC 9578,
+              DOI 10.17487/RFC9578, June 2024,
+              <https://www.rfc-editor.org/info/rfc9578>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC8470]  Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
+              Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
+              2018, <https://www.rfc-editor.org/info/rfc8470>.
+
+   [RFC8701]  Benjamin, D., "Applying Generate Random Extensions And
+              Sustain Extensibility (GREASE) to TLS Extensibility",
+              RFC 8701, DOI 10.17487/RFC8701, January 2020,
+              <https://www.rfc-editor.org/info/rfc8701>.
+
+   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
+              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
+              <https://www.rfc-editor.org/info/rfc9001>.
+
+Appendix A.  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.
+
+A.1.  Challenge and Redemption Structure Test Vectors
+
+   This section includes test vectors for the challenge and redemption
+   functionalities described in Sections 2.1 and 2.2.  Each test vector
+   lists the following values:
+
+   token_type:  The type of token issuance protocol -- a value from
+      Section 6.2.  For these test vectors, token_type is 0x0002,
+      corresponding to the issuance protocol discussed in Section 6
+      ("Issuance Protocol for Publicly Verifiable Tokens") of
+      [ISSUANCE].
+
+   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 information in the TokenChallenge structure,
+      represented as a hexadecimal string.
+
+   nonce:  The nonce in the token structure, represented as a
+      hexadecimal string.
+
+   token_key_id:  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 a 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 a non-empty redemption
+       context.
+
+   5.  TokenChallenge with multiple Origins and a non-empty redemption
+       context.
+
+   6.  TokenChallenge for greasing.
+
+   These test vectors are below.
+
+   // Test vector 1:
+   //   token_type(0002), issuer_name(issuer.example),
+   //   origin_info(origin.example), redemption_context(non-empty)
+   token_type: 0002
+   issuer_name: 6973737565722e6578616d706c65
+   redemption_context:
+   476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+   origin_info: 6f726967696e2e6578616d706c65
+   nonce:
+   e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+   token_key_id:
+   ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+   token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+   14f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a
+   8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147
+   266121ddeb5632c07f1f71cd2708
+
+   // Test vector 2:
+   //   token_type(0002), issuer_name(issuer.example),
+   //   origin_info(origin.example), redemption_context(empty)
+   token_type: 0002
+   issuer_name: 6973737565722e6578616d706c65
+   redemption_context:
+   origin_info: 6f726967696e2e6578616d706c65
+   nonce:
+   e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+   token_key_id:
+   ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+   token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+   14f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d8
+   23bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147
+   266121ddeb5632c07f1f71cd2708
+
+   // Test vector 3:
+   //   token_type(0002), issuer_name(issuer.example),
+   //   origin_info(), redemption_context(empty)
+   token_type: 0002
+   issuer_name: 6973737565722e6578616d706c65
+   redemption_context:
+   origin_info:
+   nonce:
+   e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+   token_key_id:
+   ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+   token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+   14f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec161289
+   6d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147
+   266121ddeb5632c07f1f71cd2708
+
+   // Test vector 4:
+   //   token_type(0002), issuer_name(issuer.example),
+   //   origin_info(), redemption_context(non-empty)
+   token_type: 0002
+   issuer_name: 6973737565722e6578616d706c65
+   redemption_context:
+   476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+   origin_info:
+   nonce:
+   e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+   token_key_id:
+   ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+   token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+   14f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40
+   837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147
+   266121ddeb5632c07f1f71cd2708
+
+   // Test vector 5:
+   //   token_type(0002), issuer_name(issuer.example),
+   //   origin_info(foo.example,bar.example),
+   //   redemption_context(non-empty)
+   token_type: 0002
+   issuer_name: 6973737565722e6578616d706c65
+   redemption_context:
+   476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bb
+   origin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65
+   nonce:
+   e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab
+   token_key_id:
+   ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708
+   token_authenticator_input: 0002e01978182c469e5e026d66558ee1865686
+   14f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2
+   735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147
+   266121ddeb5632c07f1f71cd2708
+
+   // Test vector 6:
+   //   token_type(0000), structure(random_bytes)
+   token_type: 0000
+   token_authenticator_input: 000058405ad31e286e874cb42d0ef9d50461ae
+   703bb71a21178beb429c43c0effe587456d856f0f2bdfc216ef93d5c225e2a93e
+   84cb686e63919788087f7ab1054aa817f09dcb919a0ed6f90fe887e8b08cd1eee
+   44d5be8d813eda9f2656db61c932db8d73f8690604ded0120157923bbd19d5549
+   e639e4de07530aee1d370f5187b678685715bd878dde24346751eb532a87b71ea
+   40bbe5a13218658e303c648eb03817453690bfcbe8255081bf27ff0891cd02ee2
+   483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5
+   b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223
+   f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe08834
+   2959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7d
+   b120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d
+   6cf7b522a5badd63b9cb
+
+A.2.  HTTP Header Test Vectors
+
+   This section includes test vectors for the contents of the HTTP
+   authentication headers.  Each test vector consists of one or more
+   challenges that comprise a WWW-Authenticate header; see Section 3.2.
+   For each challenge, the token-type, token-key, max-age, and token-
+   challenge parameters are listed.  Each challenge also includes an
+   unknown (unspecified) parameter that implementations are meant to
+   ignore.
+
+   The parameters for each challenge are indexed by their position in
+   the WWW-Authenticate 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-Authenticate 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 is not supported in
+   actual requests.
+
+   The last challenge in this list includes Basic authentication, a
+   grease challenge, and a valid challenge for token type 0x0001.
+   Correct Client implementations will ignore the Basic and grease
+   challenges.
+
+   token-type-0: 0x0002
+   token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
+   8016503040202a11a301806092a864886f70d010108300b060960864801650304020
+   2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
+   5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
+   ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
+   67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
+   f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
+   bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
+   91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
+   066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
+   e225a5f0203010001
+   max-age-0: 10
+   token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
+   8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+   e2e6578616d706c65
+
+   WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
+   o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
+    token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
+   SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
+   _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
+   JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
+   bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
+   7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
+   CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
+   nChallengeAttribute="ignore-me", max-age="10"
+
+   token-type-0: 0x0002
+   token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b060960864
+   8016503040202a11a301806092a864886f70d010108300b060960864801650304020
+   2a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab2
+   5b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9
+   ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f
+   67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9b
+   f6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6c
+   bbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e2
+   91317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106
+   066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7
+   e225a5f0203010001
+   max-age-0: 10
+   token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d9
+   8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+   e2e6578616d706c65
+   token-type-1: 0x0001
+   token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
+   53fabd489fac0f82bca86249a668f3a5bfab374c9
+   max-age-1: 10
+   token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
+   8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+   e2e6578616d706c65
+
+   WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlII
+   o-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==",
+    token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqG
+   SIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM
+   _KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWi
+   JNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtS
+   bvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE
+   7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDh
+   CRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknow
+   nChallengeAttribute="ignore-me", max-age="10", PrivateToken challeng
+   e="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPp
+   LODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBem
+   aF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ig
+   nore-me", max-age="10"
+
+   token-type-0: 0x0000
+   token-key-0: 856de3c710b892e7cca1ae5eb121af42ca8e779137a11224228c9b9
+   9b0729bf84d5057d030000309b8f0d06ccffa17561f9eacd4c312e985a6bc60ffbea
+   0610264dcb1726255313da81d665692686a1d8644f1516bf612cea009e6dff6d9a9a
+   959fb538e1b5b2343c092992942382bdde22d5b324b1e4618ed21d7806286c2ce
+   token-challenge-0: 0000acc3b25795c636fd9dd8b12982394abba8777d35978e8
+   77fc8848892a217233045ac25a3d55c07c54efe6372973fee0073e77fc61bf19ab88
+   0f20edf5d627502
+   token-type-1: 0x0001
+   token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a
+   53fabd489fac0f82bca86249a668f3a5bfab374c9
+   max-age-1: 10
+   token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d9
+   8005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696
+   e2e6578616d706c65
+
+   WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACs
+   w7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_G
+   G_GauIDyDt9dYnUC", token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbB
+   ym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2
+   GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=",
+   PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6
+   a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0z
+   gxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownC
+   hallengeAttribute="ignore-me", max-age="10"
+
+Authors' Addresses
+
+   Tommy Pauly
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California 95014
+   United States of America
+   Email: tpauly@apple.com
+
+
+   Steven Valdez
+   Google LLC
+   Email: svaldez@chromium.org
+
+
+   Christopher A. Wood
+   Cloudflare
+   Email: caw@heapingbits.net