doc: Add RFC documents

1 files changed, 1375 insertions, 0 deletions

diff --git a/doc/rfc/rfc9576.txt b/doc/rfc/rfc9576.txt
new file mode 100644
index 0000000..d99f1be
--- /dev/null
+++ b/doc/rfc/rfc9576.txt
@@ -0,0 +1,1375 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       A. Davidson
+Request for Comments: 9576       NOVA LINCS, Universidade NOVA de Lisboa
+Category: Informational                                       J. Iyengar
+ISSN: 2070-1721                                                   Fastly
+                                                              C. A. Wood
+                                                              Cloudflare
+                                                               June 2024
+
+
+                     The Privacy Pass Architecture
+
+Abstract
+
+   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, to help ensure that the desired security
+   and privacy goals are fulfilled.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see 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/rfc9576.
+
+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
+   2.  Terminology
+   3.  Architecture
+     3.1.  Overview
+     3.2.  Use Cases
+     3.3.  Privacy Goals and Threat Model
+     3.4.  Redemption Protocol
+     3.5.  Issuance Protocol
+       3.5.1.  Attester Role
+       3.5.2.  Issuer Role
+       3.5.3.  Issuance Metadata
+       3.5.4.  Future Issuance Protocol Requirements
+     3.6.  Information Flow
+       3.6.1.  Token Challenge Flow
+       3.6.2.  Attestation Flow
+       3.6.3.  Issuance Flow
+       3.6.4.  Token Redemption Flow
+   4.  Deployment Models
+     4.1.  Shared Origin, Attester, Issuer
+     4.2.  Joint Attester and Issuer
+     4.3.  Joint Origin and Issuer
+     4.4.  Split Origin, Attester, Issuer
+   5.  Deployment Considerations
+     5.1.  Discriminatory Treatment
+     5.2.  Centralization
+   6.  Privacy Considerations
+     6.1.  Partitioning by Issuance Metadata
+     6.2.  Partitioning by Issuance Consistency
+     6.3.  Partitioning by Side Channels
+   7.  Security Considerations
+     7.1.  Token Caching
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Privacy Pass is an architecture for authorization based on privacy-
+   preserving authentication mechanisms.  In other words, relying
+   parties authenticate Clients in a privacy-preserving way, i.e.,
+   without learning any unique, per-Client information through the
+   authentication protocol, and then make authorization decisions on the
+   basis of that authentication succeeding or failing.  Possible
+   authorization decisions might be to provide Clients with read access
+   to a particular resource or write access to a particular resource.
+
+   Typical approaches for authorizing Clients, such as through the use
+   of long-term state (cookies), are not privacy friendly, since they
+   allow servers to track Clients across sessions and interactions.
+   Privacy Pass takes a different approach: instead of presenting
+   linkable state-carrying information to servers, e.g., a cookie
+   indicating whether or not the Client is an authorized user or has
+   completed some prior challenge, Clients present unlinkable proofs
+   that attest to this information.  These proofs, or tokens, are
+   private in the sense that a given token cannot be linked to the
+   protocol interaction where that token was initially issued.
+
+   At a high level, the Privacy Pass architecture consists of two
+   protocols: redemption and issuance.  The redemption protocol,
+   described in [AUTHSCHEME], runs between Clients and Origins
+   (servers).  It allows Origins to challenge Clients to present tokens
+   for consumption.  Origins verify the token to authenticate the Client
+   -- without learning any specific information about the Client -- and
+   then make an authorization decision on the basis of the token
+   verifying successfully or not.  Depending on the type of token, e.g.,
+   whether or not it can be cached, the Client either presents a
+   previously obtained token or invokes an issuance protocol, e.g., the
+   protocols described in [ISSUANCE], to acquire a token to present as
+   authorization.
+
+   This document describes requirements for both redemption and issuance
+   protocols and how they interact.  It also provides recommendations on
+   how the architecture should be deployed to ensure the privacy of
+   Clients and the security of all participating entities.
+
+2.  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.
+
+   The following terms are used throughout this document:
+
+   Client:  An entity that seeks authorization to an Origin.  Using
+      terminology from [RFC9334], Clients implement the Remote
+      ATtestation procedureS (RATS) Attester role.
+
+   Token:  A cryptographic authentication message used for authorization
+      decisions, produced as output from an issuance mechanism or
+      protocol.
+
+   Origin:  An entity that consumes tokens presented by Clients and uses
+      them to make authorization decisions.
+
+   Token challenge:  The mechanism by which Origins request tokens from
+      Clients, often denoted TokenChallenge.
+
+   Token request:  A message used by Clients to request a token from an
+      Issuer, often denoted TokenRequest.
+
+   Token response:  A message used by Issuers to send tokens to a
+      Client, often denoted TokenResponse.
+
+   Redemption:  The mechanism by which Clients present tokens to Origins
+      for the purposes of authorization.
+
+   Issuer:  An entity that issues tokens to Clients for properties
+      attested to by the Attester.
+
+   Issuance:  The mechanism by which an Issuer produces tokens for
+      Clients.
+
+   Attester:  An entity that attests to properties of Clients for the
+      purposes of token issuance.  Using terminology from [RFC9334],
+      Attesters implement the RATS Verifier role.
+
+   Attestation procedure:  The procedure by which an Attester determines
+      whether or not a Client has the specific set of properties that
+      are necessary for token issuance.
+
+   The trust relationships between each of the entities in this list are
+   further elaborated upon in Section 3.3.
+
+3.  Architecture
+
+   The Privacy Pass architecture consists of four logical entities --
+   Client, Origin, Issuer, and Attester -- that work in concert for
+   token redemption and issuance.  This section presents an overview of
+   Privacy Pass, a high-level description of the threat model and
+   privacy goals of the architecture, and the goals and requirements of
+   the redemption and issuance protocols.  Deployment variations for the
+   Origin, Issuer, and Attester in this architecture, including
+   considerations for implementing these entities, are further discussed
+   in Section 4.
+
+3.1.  Overview
+
+   This section describes the typical interaction flow for Privacy Pass,
+   as shown in Figure 1.
+
+   1.  A Client interacts with an Origin by sending a request or
+       otherwise interacting with the Origin in a way that triggers a
+       response containing a token challenge.  The token challenge
+       indicates a specific Issuer to use.
+
+   2.  If the Client already has a token available that satisfies the
+       token challenge, e.g., because the Client has a cache of
+       previously issued tokens, it can skip to step 6 and redeem its
+       token; see Section 7.1 for security considerations regarding
+       cached tokens.
+
+   3.  If the Client does not have a token available and decides it
+       wants to obtain one (or more) bound to the token challenge, it
+       then invokes the issuance protocol.  As a prerequisite to the
+       issuance protocol, the Client runs the deployment-specific
+       attestation process that is required for the designated Issuer.
+       Client attestation can be done via proof of solving a CAPTCHA,
+       checking device or hardware attestation validity, etc.; see
+       Section 3.5.1 for more details.
+
+   4.  If the attestation process completes successfully, the Client
+       creates a token request to send to the designated Issuer
+       (generally via the Attester, though it is not required to be sent
+       through the Attester).  The Attester and Issuer might be
+       functions on the same server, depending on the deployment model
+       (see Section 4).  Depending on the attestation process, it is
+       possible for attestation to run alongside the issuance protocol,
+       e.g., where Clients send necessary attestation information to the
+       Attester along with their token request.  If the attestation
+       process fails, the Client receives an error and issuance aborts
+       without a token.
+
+   5.  The Issuer generates a token response based on the token request,
+       which is returned to the Client (generally via the Attester).
+       Upon receiving the token response, the Client computes a token
+       from the token challenge and token response.  This token can be
+       validated by anyone with the per-Issuer key but cannot be linked
+       to the content of the token request or token response.
+
+   6.  If the Client has a token, it includes it in a subsequent request
+       to the Origin, as authorization.  This token is sent only once in
+       reaction to a challenge; Clients do not send tokens more than
+       once, even if they receive duplicate or redundant challenges.
+       The Origin validates that the token was generated by the expected
+       Issuer and has not already been redeemed for the corresponding
+       token challenge.  If the Client does not have a token, perhaps
+       because issuance failed, the Client does not reply to the
+       Origin's challenge with a new request.
+
+   +--------+            +--------+         +----------+ +--------+
+   | Origin |            | Client |         | Attester | | Issuer |
+   +---+----+            +---+----+         +----+-----+ +---+----+
+       |                     |                   |           |
+       |<----- Request ------+                   |           |
+       +-- TokenChallenge -->|                   |           |
+       |                     |<== Attestation ==>|           |
+       |                     |                   |           |
+       |                     +--------- TokenRequest ------->|
+       |                     |<-------- TokenResponse -------+
+       |<-- Request+Token ---+                   |           |
+       |                     |                   |           |
+
+    Figure 1: Privacy Pass Redemption and Issuance Protocol Interaction
+
+3.2.  Use Cases
+
+   Use cases for Privacy Pass are broad and depend greatly on the
+   deployment model as discussed in Section 4.  The initial motivating
+   use case for Privacy Pass [PrivacyPassCloudflare] was to help rate-
+   limit malicious or otherwise abusive traffic from services such as
+   Tor [DMS2004].  The generalized and evolved architecture described in
+   this document also works for this use case.  However, for added
+   clarity, some more possible use cases are described below.
+
+   *  Low-quality, anti-fraud signal for open Internet services.  Tokens
+      can attest that the Client behind the user agent is likely not a
+      bot attempting to perform some form of automated attack such as
+      credential stuffing.  Example attestation procedures for this use
+      case might be solving some form of CAPTCHA or presenting evidence
+      of a valid, unlocked device in good standing.
+
+   *  Privacy-preserving authentication for proprietary services.
+      Tokens can attest that the Client is a valid subscriber for a
+      proprietary service, such as a deployment of Oblivious HTTP
+      [OHTTP].
+
+3.3.  Privacy Goals and Threat Model
+
+   The end-to-end flow for Privacy Pass described in Section 3.1
+   involves three different types of contexts:
+
+   Redemption context:  The interactions and set of information shared
+      between the Client and Origin, i.e., the information that is
+      provided or otherwise available to the Origin during redemption
+      that might be used to identify a Client and construct a token
+      challenge.  This context includes all information associated with
+      redemption, such as the timestamp of the event, Client-visible
+      information (including the IP address), and the Origin name.
+
+   Issuance context:  The interactions and set of information shared
+      between the Client, Attester, and Issuer, i.e., the information
+      that is provided or otherwise available to the Attester and Issuer
+      during issuance that might be used to identify a Client.  This
+      context includes all information associated with issuance, such as
+      the timestamp of the event, any Client-visible information
+      (including the IP address), and the Origin name (if revealed
+      during issuance).  This does not include the token challenge in
+      its entirety, as that is kept secret from the Issuer during the
+      issuance protocol.
+
+   Attestation context:  The interactions and set of information shared
+      between the Client and Attester only, for the purposes of
+      attesting the validity of the Client, that is provided or
+      otherwise available during attestation that might be used to
+      identify the Client.  This context includes all information
+      associated with attestation, such as the timestamp of the event
+      and any Client-visible information, including information needed
+      for the attestation procedure to complete.
+
+   The privacy goals of Privacy Pass assume a threat model in which
+   Origins trust specific Issuers to produce tokens, and Issuers in turn
+   trust one or more Attesters to correctly run the attestation
+   procedure with Clients.  This arrangement ensures that tokens that
+   validate for a given Issuer were only issued to a Client that
+   successfully completed attestation with an Attester that the Issuer
+   trusts.  Moreover, this arrangement means that if an Origin accepts
+   tokens issued by an Issuer that trusts multiple Attesters, then a
+   Client can use any one of these Attesters to issue and redeem tokens
+   for the Origin.  Whether or not these different entities in the
+   architecture collude for learning redemption, issuance, or
+   attestation contexts, as well as the necessary preconditions for
+   context unlinkability, depends on the deployment model; see Section 4
+   for more details.
+
+   The mechanisms for establishing trust between each entity in this
+   arrangement are deployment specific.  For example, in settings where
+   Clients interact with Issuers through an Attester, Attesters and
+   Issuers might use mutually authenticated TLS to authenticate one
+   another.  In settings where Clients do not communicate with Issuers
+   through an Attester, the Attesters might convey this trust via a
+   digital signature that Issuers can verify.
+
+   Clients explicitly trust Attesters to perform attestation correctly
+   and in a way that does not violate their privacy.  In particular,
+   this means that Attesters that may be privy to private information
+   about Clients are trusted to not disclose this information to non-
+   colluding parties.  Colluding parties are assumed to have access to
+   the same information; see Section 4 for more about different
+   deployment models and non-collusion assumptions.  However, Clients
+   assume that Issuers and Origins are malicious.
+
+   Given this threat model, the privacy goals of Privacy Pass are
+   oriented around unlinkability based on redemption, issuance, and
+   attestation contexts, as described below.
+
+   1.  Origin-Client unlinkability.  This means that given two
+       redemption contexts, the Origin cannot determine if both
+       redemption contexts correspond to the same Client or two
+       different Clients.  Informally, this means that a Client in a
+       redemption context is indistinguishable from any other Client
+       that might use the same redemption context.  The set of Clients
+       that share the same redemption context is referred to as a
+       redemption anonymity set.
+
+   2.  Issuer-Client unlinkability.  This is similar to Origin-Client
+       unlinkability in that a Client in an issuance context is
+       indistinguishable from any other Client that might use the same
+       issuance context.  The set of Clients that share the same
+       issuance context is referred to as an issuance anonymity set.
+
+   3.  Attester-Origin unlinkability.  This is similar to Origin-Client
+       and Issuer-Client unlinkability.  It means that given two
+       attestation contexts, the Attester cannot determine if both
+       contexts correspond to the same Origin or two different Origins.
+       The set of Origins that share the same attestation context is
+       referred to as an attestation anonymity set.
+
+   4.  Redemption context unlinkability.  Given two redemption contexts,
+       the Origin cannot determine which issuance and attestation
+       contexts each redemption corresponds to, even with the
+       collaboration of the Issuer and Attester (should these be
+       different parties).  This means that any information that may be
+       learned about the Client during the issuance and attestation
+       flows cannot be used by the Origin to compromise Client privacy.
+
+   These unlinkability properties ensure that only the Clients are able
+   to correlate information that might be used to identify them with
+   activity on the Origin.  The Attester, Issuer, and Origin only
+   receive the information necessary to perform their respective
+   functions.
+
+   The manner in which these unlinkability properties are achieved
+   depends on the deployment model, type of attestation, and issuance
+   protocol details.  For example, as discussed in Section 4, in some
+   cases it is necessary to use an anonymization service that hides
+   Client IP addresses, such as Tor [DMS2004].  In general,
+   anonymization services ensure that all Clients that use the service
+   are indistinguishable from one another, though in practice there may
+   be small distinguishing features (TLS fingerprints, HTTP headers,
+   etc.).  Moreover, Clients generally trust these services to not
+   disclose private Client information (such as IP addresses) to
+   untrusted parties.  Failure to use an anonymization service when
+   interacting with Attesters, Issuers, or Origins can allow the set of
+   possible Clients to be partitioned by the Client's IP address and can
+   therefore lead to unlinkability violations.  Similarly, malicious
+   Origins may attempt to link two redemption contexts together by using
+   Client-specific Issuer Public Keys.  See Sections 5 and 6 for more
+   information.
+
+   Sections 3.4 and 3.5 describe the functional properties and security
+   requirements of the redemption and issuance protocols in more detail.
+   Section 3.6 describes how information flows between the Issuer,
+   Origin, Client, and Attester through these protocols.
+
+3.4.  Redemption Protocol
+
+   The Privacy Pass redemption protocol, described in [AUTHSCHEME], is
+   an authorization protocol wherein Clients present tokens to Origins
+   for authorization.  Normally, redemption is preceded by a challenge,
+   wherein the Origin challenges Clients for a token with a
+   TokenChallenge ([AUTHSCHEME], Section 2.1) and, if possible, Clients
+   present a valid token ([AUTHSCHEME], Section 2.2) in reaction to the
+   challenge.  This interaction is shown below.
+
+   +--------+            +--------+
+   | Origin |            | Client |
+   +---+----+            +---+----+
+       |                     |
+       |<----- Request ------+
+       +-- TokenChallenge -->|
+       |                     | <== Issuance protocol ==>
+       |<-- Request+Token ---+
+       |                     |
+
+          Figure 2: Challenge and Redemption Protocol Interaction
+
+   Alternatively, when configured to do so, Clients may
+   opportunistically present token values to Origins without a
+   corresponding TokenChallenge.
+
+   The structure and semantics of the TokenChallenge and token messages
+   depend on the issuance protocol and token type being used; see
+   [AUTHSCHEME] for more information.
+
+   The challenge provides the Client with the information necessary to
+   obtain tokens that the server might subsequently accept in the
+   redemption context.  There are a number of ways in which the token
+   may vary based on this challenge, including the following:
+
+   *  Issuance protocol.  The challenge identifies the type of issuance
+      protocol required for producing the token.  Different issuance
+      protocols have different security properties, e.g., some issuance
+      protocols may produce tokens that are publicly verifiable, whereas
+      others may not have this property.
+
+   *  Issuer identity.  Token challenges identify which Issuers are
+      trusted for a given issuance protocol.  As described in
+      Section 3.3, the choice of Issuer determines the type of Attesters
+      and attestation procedures possible for a token from the specified
+      Issuer, but the Origin does not learn exactly which Attester was
+      used for a given token issuance event.
+
+   *  Redemption context.  Challenges can be bound to a given redemption
+      context, which influences a Client's ability to pre-fetch and
+      cache tokens.  For example, an empty redemption context always
+      allows tokens to be issued and redeemed non-interactively, whereas
+      a fresh and random redemption context means that the redeemed
+      token must be issued only after the Client receives the challenge.
+      See Section 2.1.1 of [AUTHSCHEME] for more details.
+
+   *  Per-Origin or cross-Origin.  Challenges can be constrained to the
+      Origin for which the challenge originated (referred to as per-
+      Origin tokens) or can be used across multiple Origins (referred to
+      as cross-Origin tokens).  The set of Origins for which a cross-
+      Origin token is applicable is referred to as the cross-Origin set.
+      Opting into this set is done by explicitly agreeing on the
+      contents of the set.  Every Origin in a cross-Origin set, by
+      opting in, agrees to admit tokens for any other Origin in the set.
+      See Section 2.1.1 of [AUTHSCHEME] for more information on how this
+      set is created.
+
+   Origins that admit cross-Origin tokens bear some risk of allowing
+   tokens issued for one Origin to be spent in an interaction with
+   another Origin.  In particular, cross-Origin tokens issued based on a
+   challenge for one Origin can be redeemed at another Origin in the
+   cross-Origin set, which can make it difficult to regulate token
+   consumption.  Depending on the use case, Origins may need to maintain
+   state to track redeemed tokens.  For example, Origins that accept
+   cross-Origin tokens across shared redemption contexts SHOULD track
+   which tokens have already been redeemed in those redemption contexts,
+   since these tokens can be issued and then spent multiple times for
+   any such challenge.  Note that Clients that redeem the same token to
+   multiple Origins do risk those Origins being able to link Client
+   activity together, which can disincentivize this behavior.  See
+   Section 2.1.1 of [AUTHSCHEME] for discussion.
+
+   How Clients respond to token challenges can have privacy
+   implications.  For example, if an Origin allows the Client to choose
+   an Issuer, then the choice of Issuer can reveal information about the
+   Client used to partition anonymity sets; see Section 6.2 for more
+   information about these privacy considerations.
+
+3.5.  Issuance Protocol
+
+   The Privacy Pass issuance protocols, such as those described in
+   [ISSUANCE], are two-message protocols that take as input a
+   TokenChallenge from the redemption protocol ([AUTHSCHEME],
+   Section 2.1) and produce a token ([AUTHSCHEME], Section 2.2), as
+   shown in Figure 1.
+
+   The structure and semantics of the TokenRequest and TokenResponse
+   messages depend on the issuance protocol and token type being used;
+   see [ISSUANCE] for more information.
+
+   Clients interact with the Attester and Issuer to produce a token for
+   a challenge.  The context in which an Attester vouches for a Client
+   during issuance is referred to as the attestation context.  This
+   context includes all information associated with the issuance event,
+   such as the timestamp of the event and Client-visible information,
+   including the IP address or other information specific to the type of
+   attestation done.
+
+   Each issuance protocol may be different, e.g., in the number and
+   types of participants, underlying cryptographic constructions used
+   when issuing tokens, and even privacy properties.
+
+   Clients initiate the issuance protocol using the token challenge, a
+   randomly generated nonce, and a public key for the Issuer, all of
+   which are the Client's private input to the protocol and ultimately
+   bound to an output token; see Section 2.2 of [AUTHSCHEME] for
+   details.  Future specifications may change or extend the Client's
+   input to the issuance protocol to produce tokens with a different
+   structure.
+
+   Token properties vary based on the issuance protocol.  Important
+   properties supported in this architecture are described below.
+
+   1.  Public verifiability.  This means that the token can be verified
+       using the Issuer Public Key. A token that does not have public
+       verifiability can only be verified using the Issuer secret key.
+
+   2.  Public metadata.  This means that the token can be
+       cryptographically bound to arbitrary public information.  See
+       Section 6.1 for privacy considerations regarding public metadata.
+
+   3.  Private metadata.  This means that the token can be
+       cryptographically bound to arbitrary private information, i.e.,
+       information that the Client does not observe during token
+       issuance or redemption.  See Section 6.1 for privacy
+       considerations regarding private metadata.
+
+   The issuance protocol itself can be any interactive protocol between
+   the Client, Issuer, or other parties that produces a valid token
+   bound to the Client's private input, subject to the following
+   security requirements.
+
+   1.  Unconditional input secrecy.  The issuance protocol MUST NOT
+       reveal anything about the Client's private input, including the
+       challenge and nonce, to the Attester or Issuer, regardless of the
+       hardness assumptions of the underlying cryptographic protocol(s).
+       This property is sometimes also referred to as blindness.
+
+   2.  One-more forgery security.  The issuance protocol MUST NOT allow
+       malicious Clients or Attesters (acting as Clients) to forge
+       tokens offline or otherwise without interacting with the Issuer
+       directly.
+
+   3.  Concurrent security.  The issuance protocol MUST be safe to run
+       concurrently with arbitrarily many Clients, Attesters, and
+       Issuers.
+
+   See Section 3.5.4 for requirements on new issuance protocol variants
+   and related extensions.
+
+   In the sections below, we describe the Attester and Issuer roles in
+   more detail.
+
+3.5.1.  Attester Role
+
+   In Privacy Pass, attestation is the process by which an Attester
+   bears witness to, confirms, or authenticates a Client so as to verify
+   properties about the Client that are required for issuance.  Issuers
+   trust Attesters to perform attestation correctly, i.e., to implement
+   attestation procedures in such a way that those procedures are not
+   subverted or bypassed by malicious Clients.
+
+   [RFC9334] describes an architecture for attestation procedures.
+   Using that architecture as a conceptual basis, Clients are RATS
+   Attesters that produce attestation evidence, and Attesters are RATS
+   Verifiers that appraise the validity of attestation evidence.
+
+   The type of attestation procedure is a deployment-specific option and
+   outside the scope of the issuance protocol.  Example attestation
+   procedures are below.
+
+   *  Solving a CAPTCHA.  Clients that solve CAPTCHA challenges can be
+      attested to have this capability for the purpose of being ruled
+      out as a bot or otherwise automated Client.
+
+   *  Presenting evidence of Client device validity.  Some Clients run
+      on trusted hardware that is capable of producing device-level
+      attestation evidence.
+
+   *  Proving properties about Client state.  Clients can be associated
+      with state, and the Attester can verify this state.  Examples of
+      state include the Client's geographic region and whether the
+      Client has a valid application-layer account.
+
+   Attesters may support different types of attestation procedures.
+
+   Each attestation procedure has different security properties.  For
+   example, attesting to having a valid account is different from
+   attesting to running on trusted hardware.  Supporting multiple
+   attestation procedures is an important step towards ensuring
+   equitable access for Clients; see Section 5.1.
+
+   The role of the Attester in the issuance protocol and its impact on
+   privacy depend on the type of attestation procedure, issuance
+   protocol, and deployment model.  For instance, increasing the number
+   of required attestation procedures could decrease the overall
+   anonymity set size.  As an example, the number of Clients that have
+   solved a CAPTCHA in the past day, that have a valid account, and that
+   are running on a trusted device is less than the number of Clients
+   that have solved a CAPTCHA in the past day.  See Section 6.2 for more
+   discussion of how the variety of attestation procedures can
+   negatively impact Client privacy.
+
+   Depending on the issuance protocol, the Issuer might learn
+   information about the Origin.  To ensure Issuer-Client unlinkability,
+   the Issuer should be unable to link that information to a specific
+   Client.  For such issuance protocols where the Attester has access to
+   Client-specific information, such as is the case for attestation
+   procedures that involve Client-specific information (such as
+   application-layer account information) or for deployment models where
+   the Attester learns Client-specific information (such as Client IP
+   addresses), Clients trust the Attester to not share any Client-
+   specific information with the Issuer.  In deployments where the
+   Attester does not learn Client-specific information or where the
+   Attester and Issuer are operated by the same entity (such as in the
+   Joint Attester and Issuer model described in Section 4.2), the Client
+   does not need to explicitly trust the Attester in this regard.
+
+   Issuers trust Attesters to correctly and reliably perform
+   attestation.  However, certain types of attestation procedures can
+   vary in value over time, e.g., if the attestation procedure is
+   compromised.  Broken attestation procedures are considered
+   exceptional events and require configuration changes to address the
+   underlying cause.  For example, if an attestation procedure is
+   compromised or subverted because of a zero-day exploit on devices
+   that implement the attestation procedure, then the corresponding
+   attestation procedure should be untrusted until the exploit is
+   patched.  Addressing changes in attestation quality is therefore a
+   deployment-specific task.  In Split Origin, Attester, and Issuer
+   deployments (see Section 4.4), Issuers can choose to remove
+   compromised Attesters from their trusted set until the compromise is
+   patched.
+
+   From the perspective of an Origin, tokens produced by an Issuer with
+   at least one compromised Attester cannot be trusted, assuming that
+   the Origin does not know which attestation procedure was used for
+   issuance.  This is because the Origin cannot distinguish between
+   tokens that were issued via compromised Attesters and tokens that
+   were issued via uncompromised Attesters, absent some distinguishing
+   information in the tokens themselves or from the Issuer.  As a
+   result, until the attestation procedure is fixed, the Issuer cannot
+   be trusted by Origins.  Moreover, as a consequence, any tokens issued
+   by an Issuer with a compromised Attester may no longer be trusted by
+   Origins, even if those tokens were issued to Clients interacting with
+   an uncompromised Attester.
+
+3.5.2.  Issuer Role
+
+   In Privacy Pass, the Issuer is responsible for completing the
+   issuance protocol for Clients that complete attestation through a
+   trusted Attester.  As described in Section 3.5.1, Issuers explicitly
+   trust Attesters to correctly and reliably perform attestation.
+   Origins explicitly trust Issuers to only issue tokens from trusted
+   Attesters.  Clients do not explicitly trust Issuers.
+
+   Depending on the deployment model case, issuance may require some
+   form of Client anonymization service, similar to an IP-hiding proxy,
+   so that Issuers cannot learn information about Clients.  This can be
+   provided by an explicit participant in the issuance protocol, or it
+   can be provided via external means, such as through the use of an IP-
+   hiding proxy service like Tor [DMS2004].  In general, Clients SHOULD
+   minimize or remove identifying information where possible when
+   invoking the issuance protocol.
+
+   Issuers are uniquely identifiable by all Clients with a consistent
+   identifier.  In a web context, this identifier might be the Issuer
+   hostname.  Issuers maintain one or more configurations, including
+   issuance key pairs, for use in the issuance protocol.  Each
+   configuration is assumed to have a unique and canonical identifier,
+   sometimes referred to as a key identifier or key ID.  Issuers can
+   rotate these configurations as needed to mitigate the risk of
+   compromise; see Section 6.2 for more considerations around
+   configuration rotation.  The Issuer Public Key for each active
+   configuration is made available to Origins and Clients for use in the
+   issuance and redemption protocols.
+
+3.5.3.  Issuance Metadata
+
+   Certain instantiations of the issuance protocol may permit public or
+   private metadata to be cryptographically bound to a token.  As an
+   example, one trivial way to include public metadata is to assign a
+   unique Issuer Public Key for each value of metadata, such that N keys
+   yield log_2(N) bits of metadata.  Metadata may be public or private.
+
+   Public metadata is metadata that Clients can observe as part of the
+   token issuance flow.  Public metadata can be either transparent or
+   opaque.  For example, transparent public metadata is a value that
+   either the Client generates itself or the Issuer provides during the
+   issuance flow and that the Client can check for correctness.  Opaque
+   public metadata is metadata the Client can see but cannot check for
+   correctness.  As an example, the opaque public metadata might be a
+   "fraud detection signal", computed on behalf of the Issuer, during
+   token issuance.  Generally speaking, Clients cannot determine if this
+   value is generated in a way that permits tracking.
+
+   Private metadata is metadata that Clients cannot observe as part of
+   the token issuance flow.  Such instantiations can be built on the
+   private metadata bit construction from Kreuter et al. [KLOR20] or the
+   attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF)
+   from Huang et al. [HIJK21].
+
+   Metadata can be arbitrarily long or bounded in length.  The amount of
+   permitted metadata may be determined by an application or by the
+   underlying cryptographic protocol.  The total amount of metadata bits
+   included in a token is the sum of public and private metadata bits.
+   Every bit of metadata can be used to partition the Client issuance or
+   redemption anonymity sets; see Section 6.1 for more information.
+
+3.5.4.  Future Issuance Protocol Requirements
+
+   The Privacy Pass architecture and ecosystem are both intended to be
+   receptive to extensions that expand the current set of
+   functionalities through new issuance protocols.  Each new issuance
+   protocol and extension MUST adhere to the following requirements:
+
+   1.  Include a detailed analysis of the privacy impacts of the
+       extension, why these impacts are justified, and guidelines on how
+       to use the protocol to mitigate or minimize negative deployment
+       or privacy consequences discussed in Sections 5 and 6,
+       respectively.
+
+   2.  Adhere to the guidelines specified in Section 3.5.2 for managing
+       Issuer Public Key data.
+
+   3.  Clearly specify how to interpret and validate TokenChallenge and
+       token messages that are exchanged during the redemption protocol.
+
+3.6.  Information Flow
+
+   The end-to-end process of redemption and issuance protocols involves
+   information flowing between the Issuer, Origin, Client, and Attester.
+   That information can have implications on the privacy goals that
+   Privacy Pass aims to provide as outlined in Section 3.3.  In this
+   section, we describe the flow of information between each party.  How
+   this information affects the privacy goals in particular deployment
+   models is further discussed in Section 4.
+
+3.6.1.  Token Challenge Flow
+
+   To use Privacy Pass, Origins choose an Issuer from which they are
+   willing to accept tokens.  Origins then construct a token challenge
+   using this specified Issuer and information from the redemption
+   context it shares with the Client.  This token challenge is then
+   delivered to a Client.  The token challenge conveys information about
+   the Issuer and the redemption context, such as whether the Origin
+   desires a per-Origin or cross-Origin token.  Any entity that sees the
+   token challenge might learn things about the Client as known to the
+   Origin.  This is why input secrecy is a requirement for issuance
+   protocols, as it ensures that the challenge is not directly available
+   to the Issuer.
+
+3.6.2.  Attestation Flow
+
+   Clients interact with the Attester to prove that they meet some
+   required set of properties.  In doing so, Clients contribute
+   information to the attestation context, which might include sensitive
+   information such as application-layer identities, IP addresses, and
+   so on.  Clients can choose whether or not to contribute this
+   information based on local policy or preference.
+
+3.6.3.  Issuance Flow
+
+   Clients use the issuance protocol to produce a token bound to a token
+   challenge.  In doing so, there are several ways in which the issuance
+   protocol contributes information to the attestation or issuance
+   contexts.  For example, a token request may contribute information to
+   the attestation or issuance contexts as described below.
+
+   *  Issuance protocol.  The type of issuance protocol can contribute
+      information about the Issuer's capabilities to the attestation or
+      issuance contexts, as well as the capabilities of a given Client.
+      For example, if a Client is presented with multiple issuance
+      protocol options, then the choice of which issuance protocol to
+      use can contribute information about the Client's capabilities.
+
+   *  Issuer configuration.  Information about the Issuer configuration,
+      such as its identity or the public key used to validate tokens it
+      creates, can be revealed during issuance and contribute to the
+      attestation or issuance contexts.
+
+   *  Attestation information.  The issuance protocol can contribute
+      information to the attestation or issuance contexts based on what
+      attestation procedure the Issuer uses to trust a token request.
+      In particular, a token request that is validated by a given
+      Attester means that the Client that generated the token request
+      must be capable of completing the designated attestation
+      procedure.
+
+   *  Origin information.  The issuance protocol can contribute
+      information about the Origin that challenged the Client; see
+      Section 3.6.1.  In particular, a token request designated for a
+      specific Issuer might imply that the resulting token is for an
+      Origin that trusts the specified Issuer.  However, this is not
+      always true, as some token requests can correspond to cross-Origin
+      tokens, i.e., they are tokens that would be accepted at any Origin
+      that accepts the cross-Origin token.
+
+   Moreover, a token may contribute information to the issuance
+   attestation or contexts as described below.
+
+   *  Origin information.  The issuance protocol can contribute
+      information about the Origin in how it responds to a token
+      request.  For example, if an Issuer learns the Origin during
+      issuance and is also configured to respond in some way on the
+      basis of that information, and the Client interacts with the
+      Issuer transitively through the Attester, that response can reveal
+      information to the Attester.
+
+   *  Token.  The token produced by the issuance protocol can contain
+      information from the issuance context.  In particular, depending
+      on the issuance protocol, tokens can contain public or private
+      metadata, and Issuers can choose that metadata on the basis of
+      information in the issuance context.
+
+   Exceptional cases in the issuance protocol, such as when either the
+   Attester or Issuer aborts the protocol, can contribute information to
+   the attestation or issuance contexts.  The extent to which
+   information in this context harms the Issuer-Client or Attester-
+   Origin unlinkability goals as discussed in Section 3.3 depends on the
+   deployment model; see Section 4.  Clients can choose whether or not
+   to contribute information to these contexts based on local policy or
+   preference.
+
+3.6.4.  Token Redemption Flow
+
+   Clients send tokens to Origins during the redemption protocol.  Any
+   information that is added to the token during issuance can therefore
+   be sent to the Origin.  Information can be either (1) explicitly
+   passed in a token or (2) implicit in the way the Client responds to a
+   token challenge.  For example, if a Client fails to complete issuance
+   and consequently fails to redeem a token for a token challenge, this
+   can reveal information to the Origin that it might not otherwise have
+   access to.  However, an Origin cannot necessarily distinguish between
+   a Client that fails to complete issuance and one that ignores the
+   token challenge altogether.
+
+4.  Deployment Models
+
+   The Origin, Attester, and Issuer portrayed in Figure 1 can be
+   instantiated and deployed in a number of ways.  The deployment model
+   directly influences the manner in which attestation, issuance, and
+   redemption contexts are separated to achieve Origin-Client, Issuer-
+   Client, and Attester-Origin unlinkability.
+
+   This section covers some expected deployment models and their
+   corresponding security and privacy considerations.  Each deployment
+   model is described in terms of the trust relationships and
+   communication patterns between the Client, Attester, Issuer, and
+   Origin.  Entities drawn within the same bounding box are assumed to
+   be operated by the same party and are therefore able to collude.
+   Collusion can enable linking of attestation, issuance, and redemption
+   contexts.  Entities not drawn within the same bounding box (i.e.,
+   operated by separate parties) are assumed to not collude.  Mechanisms
+   for enforcing non-collusion are out of scope for this architecture.
+
+4.1.  Shared Origin, Attester, Issuer
+
+   In this model, the Origin, Attester, and Issuer are all operated by
+   the same entity, as shown in Figure 3.
+
+                    +---------------------------------------------.
+   +--------+       |  +----------+     +--------+     +--------+  |
+   | Client |       |  | Attester |     | Issuer |     | Origin |  |
+   +---+----+       |  +-----+----+     +----+---+     +---+----+  |
+       |             `-------|---------------|-------------|------'
+       |<-------------------------------- TokenChallenge --+
+       |                     |               |             |
+       |<=== Attestation ===>|               |             |
+       |                     |               |             |
+       +----------- TokenRequest ----------->|             |
+       |<---------- TokenResponse -----------+             |
+       |                                                   |
+       +--------------------- Token ----------------------->
+       |                                                   |
+
+                     Figure 3: Shared Deployment Model
+
+   This model represents the initial deployment of Privacy Pass, as
+   described in [PrivacyPassCloudflare].  In this model, the Attester,
+   Issuer, and Origin share the attestation, issuance, and redemption
+   contexts.  As a result, attestation mechanisms that can uniquely
+   identify a Client, e.g., requiring that Clients authenticate with
+   some type of application-layer account, are not appropriate, as they
+   could lead to unlinkability violations.
+
+   Origin-Client, Issuer-Client, and Attester-Origin unlinkability
+   requires that issuance and redemption events be separated over time,
+   such as through the use of tokens that correspond to token challenges
+   with an empty redemption context (see Section 3.4), or that they be
+   separated over space, such as through the use of an anonymizing
+   service when connecting to the Origin.
+
+4.2.  Joint Attester and Issuer
+
+   In this model, the Attester and Issuer are operated by the same
+   entity, separate from the Origin.  The Origin trusts the joint
+   Attester and Issuer to perform attestation and issue tokens.  Clients
+   interact with the joint Attester and Issuer for attestation and
+   issuance.  This arrangement is shown in Figure 4.
+
+                      +------------------------------.
+   +--------+         |  +----------+     +--------+  |  +--------+
+   | Client |         |  | Attester |     | Issuer |  |  | Origin |
+   +---+----+         |  +-----+----+     +----+---+  |  +---+----+
+       |               `-------|---------------|-----'       |
+       |<---------------------------------- TokenChallenge --+
+       |                       |               |             |
+       |<==== Attestation ====>|               |             |
+       |                       |               |             |
+       +------------- TokenRequest ----------->|             |
+       |<----------- TokenResponse ------------+             |
+       |                                                     |
+       +----------------------- Token ----------------------->
+       |                                                     |
+
+            Figure 4: Joint Attester and Issuer Deployment Model
+
+   This model is useful if an Origin wants to offload attestation and
+   issuance to a trusted entity.  In this model, the Attester and Issuer
+   share an attestation and issuance context for the Client, separate
+   from the Origin's redemption context.
+
+   Similar to the shared Origin, Attester, Issuer model, Issuer-Client
+   and Origin-Client unlinkability in this model requires that issuance
+   and redemption events, respectively, be separated over time or space.
+   Attester-Origin unlinkability requires that the Attester and Issuer
+   do not learn the Origin for a particular token request.  For this
+   reason, issuance protocols that require the Issuer to learn
+   information about the Origin, such as the issuance protocol described
+   in [RATE-LIMITED], are not appropriate, since they could lead to
+   Attester-Origin unlinkability violations through the Origin name.
+
+4.3.  Joint Origin and Issuer
+
+   In this model, the Origin and Issuer are operated by the same entity,
+   separate from the Attester, as shown in Figure 5.  The Issuer accepts
+   token requests that come from trusted Attesters.  Since the Attester
+   and Issuer are separate entities, this model requires some mechanism
+   by which Issuers establish trust in the Attester (as described in
+   Section 3.3).  For example, in settings where the Attester is a
+   Client-trusted service that directly communicates with the Issuer,
+   one way to establish this trust is via mutually authenticated TLS.
+   However, alternative authentication mechanisms are possible.  In this
+   model, the Origin and Issuer are operated by the same entity,
+   separate from the Attester, as shown in the figure below.
+
+                                     +----------------------------.
+   +--------+          +----------+  |  +--------+     +--------+  |
+   | Client |          | Attester |  |  | Issuer |     | Origin |  |
+   +---+----+          +-----+----+  |  +----+---+     +---+----+  |
+       |                     |        `------|-------------|------'
+       |<-------------------------------- TokenChallenge --+
+       |                     |               |             |
+       |<=== Attestation ===>|               |             |
+       |                     |               |             |
+       +------------ TokenRequest ---------->|             |
+       |<---------- TokenResponse -----------+             |
+       |                                                   |
+       +--------------------- Token ----------------------->
+       |                                                   |
+
+             Figure 5: Joint Origin and Issuer Deployment Model
+
+   This model is useful for Origins that require Client-identifying
+   attestation, e.g., through the use of application-layer account
+   information, but do not otherwise want to learn information about
+   individual Clients beyond what is observed during the token
+   redemption, such as Client IP addresses.
+
+   In this model, attestation contexts are separate from Issuer and
+   redemption contexts.  As a result, any type of attestation is
+   suitable in this model.
+
+   Moreover, assuming that there is more than one Origin involved, any
+   type of token challenge is suitable, since no single party will have
+   access to the identifying Client information and unique Origin
+   information.  Issuers that produce tokens for a single Origin are not
+   suitable in this model, since an Attester can infer the Origin from a
+   token request, as described in Section 3.6.3.  However, since the
+   issuance protocol provides input secrecy, the Attester does not learn
+   details about the corresponding token challenge, such as whether the
+   token challenge is per Origin or across Origins.
+
+4.4.  Split Origin, Attester, Issuer
+
+   In this model, the Origin, Attester, and Issuer are all operated by
+   different entities.  As with the Joint Origin and Issuer model
+   (Section 4.3), the Issuer accepts token requests that come from
+   trusted Attesters, and the details of that trust establishment depend
+   on the issuance protocol and relationship between the Attester and
+   Issuer; see Section 3.3.  This arrangement is shown in Figure 1.
+
+   This is the most general deployment model and is necessary for some
+   types of issuance protocols where the Attester plays a role in token
+   issuance; see [RATE-LIMITED] for one such type of issuance protocol.
+
+   In this model, the Attester, Issuer, and Origin have a separate view
+   of the Client: the Attester sees potentially sensitive Client-
+   identifying information, such as account identifiers or IP addresses;
+   the Issuer sees only the information necessary for issuance; and the
+   Origin sees token challenges, corresponding tokens, and Client source
+   information, such as their IP address.  As a result, attestation,
+   issuance, and redemption contexts are separate, and therefore any
+   type of token challenge is suitable in this model as long as there is
+   more than a single Origin.
+
+   As with the Joint Origin and Issuer model (Section 4.3), and as
+   described in Section 3.6.3, if the Issuer produces tokens for a
+   single Origin, then per-Origin tokens are not appropriate, since the
+   Attester can infer the Origin from a token request.
+
+5.  Deployment Considerations
+
+   Section 4 discusses deployment models that are possible in practice.
+   Beyond possible implications on security and privacy properties of
+   the resulting system, Privacy Pass deployments can impact the overall
+   ecosystem in two important ways: (1) discriminatory treatment of
+   Clients and the gated access to otherwise open services and
+   (2) centralization.  This section describes considerations relevant
+   to these topics.
+
+5.1.  Discriminatory Treatment
+
+   Origins can use tokens as a signal for distinguishing between
+   (1) Clients that are capable of completing attestation with one
+   Attester trusted by the Origin's chosen Issuer and (2) Clients that
+   are not capable of doing the same.  A consequence of this is that
+   Privacy Pass could enable discriminatory treatment of Clients based
+   on attestation support.  For example, an Origin could only authorize
+   Clients that successfully authenticate with a token, prohibiting
+   access to all other Clients.
+
+   The types of attestation procedures supported for a particular
+   deployment depend greatly on the use case.  For example, consider a
+   proprietary deployment of Privacy Pass that authorizes Clients to
+   access a resource such as an anonymization service.  In this context,
+   it is reasonable to support specific types of attestation procedures
+   that demonstrate that Clients can access the resource, such as with
+   an account or specific type of device.  However, in open deployments
+   of Privacy Pass that are used to safeguard access to otherwise open
+   or publicly accessible resources, diversity in attestation procedures
+   is critically important so as to not discriminate against Clients
+   that choose certain software, hardware, or identity providers.
+
+   In principle, Issuers should strive to mitigate discriminatory
+   behavior by providing equitable access to all Clients.  This can be
+   done by working with a set of Attesters that are suitable for all
+   Clients.  In practice, this may require trade-offs in what type of
+   attestation Issuers are willing to trust so as to enable more
+   widespread support.  In other words, trusting a variety of Attesters
+   with a diverse set of attestation procedures would presumably
+   increase support among Clients, though most likely at the expense of
+   decreasing the overall value of tokens issued by the Issuer.
+
+   For example, to disallow discriminatory behavior between Clients with
+   and without device attestation support, an Issuer may wish to support
+   Attesters that support CAPTCHA-based attestation.  This means that
+   the overall attestation value of a Privacy Pass token is bound by the
+   difficulty in spoofing or bypassing either one of these attestation
+   procedures.
+
+5.2.  Centralization
+
+   A consequence of limiting the number of participants (Attesters or
+   Issuers) in Privacy Pass deployments for meaningful privacy is that
+   it forces concentrated centralization among those participants.
+   [CENTRALIZATION] discusses several ways in which this might be
+   mitigated.  For example, a multi-stakeholder governance model could
+   be established to determine what candidate participants are fit to
+   operate as participants in a Privacy Pass deployment.  This is
+   precisely the system used to control the Web's trust model.
+
+   Alternatively, Privacy Pass deployments might mitigate this problem
+   through implementation.  For example, rather than centralize the role
+   of attestation in one or a few entities, attestation could be a
+   distributed function performed by a quorum of many parties, provided
+   that neither Issuers nor Origins learn which Attester implementations
+   were chosen.  As a result, Clients could have more opportunities to
+   switch between attestation participants.
+
+6.  Privacy Considerations
+
+   The previous section discusses the impact of deployment details on
+   Origin-Client, Issuer-Client, and Attester-Origin unlinkability.  The
+   value these properties afford to end users depends on the size of
+   anonymity sets in which Clients or Origins are unlinkable.  For
+   example, consider two different deployments, one wherein there exists
+   a redemption anonymity set of size two and another wherein there
+   exists a redemption anonymity set of size 2^32.  Although Origin-
+   Client unlinkability guarantees that the Origin cannot link any two
+   requests to the same Client based on these contexts, respectively,
+   the smaller these sets become, the higher the probability of
+   determining the "true" Client.
+
+   In practice, there are a number of ways in which the size of
+   anonymity sets may be reduced or partitioned, though they all center
+   around the concept of consistency.  In particular, by definition, all
+   Clients in an anonymity set share a consistent view of information
+   needed to run the issuance and redemption protocols.  The Issuer
+   Public Key is an example of the type of information needed to run
+   these protocols.  When two Clients have inconsistent information,
+   these Clients effectively have different redemption contexts and
+   therefore belong in different anonymity sets.
+
+   The following subsections discuss issues that can influence anonymity
+   set size.  For each issue, we discuss mitigations or safeguards to
+   protect against the underlying problem.
+
+6.1.  Partitioning by Issuance Metadata
+
+   Any public or private metadata bits of information can be used to
+   further segment the size of the Client anonymity set.  Any Issuer
+   that wanted to track a single Client could add a single metadata bit
+   to Client tokens.  For the tracked Client, it would set the bit to 1,
+   and 0 otherwise.  Adding additional bits provides an exponential
+   increase in tracking granularity in a manner similar to introducing
+   more Issuers (though with more potential targeting).
+
+   For this reason, deployments should take the amount of metadata used
+   by an Issuer in creating tokens, together with the bits of
+   information that Issuers may learn about Clients through other means,
+   into account.  Since this metadata may be useful for practical
+   deployments of Privacy Pass, Issuers must balance this against the
+   reduction in Client privacy.
+
+   The number of permitted metadata values often depends on deployment-
+   specific details.  In general, limiting the amount of metadata
+   permitted helps limit the extent to which metadata can uniquely
+   identify individual Clients.  Failure to bound the number of possible
+   metadata values can therefore lead to a reduction in Client privacy.
+   Most token types do not admit any metadata, so this bound is
+   implicitly enforced.
+
+6.2.  Partitioning by Issuance Consistency
+
+   Anonymity sets can be partitioned by information used for the
+   issuance protocol, including metadata, Issuer configuration (keys),
+   and Issuer selection.
+
+   Any issuance metadata bits of information can be used to partition
+   the Client anonymity set.  For example, any Issuer that wanted to
+   track a single Client could add a single metadata bit to Client
+   tokens.  For the tracked Client, it would set the bit to 1, and 0
+   otherwise.  Adding additional bits provides an exponential increase
+   in tracking granularity in a manner similar to introducing more
+   Issuers (though with more potential targeting).
+
+   The number of active Issuer configurations also contributes to
+   anonymity set partitioning.  In particular, when an Issuer updates
+   their configuration and the corresponding key pair, any Client that
+   invokes the issuance protocol with this configuration becomes part of
+   a set of Clients that also ran the issuance protocol using the same
+   configuration.  Issuer configuration updates, e.g., due to key
+   rotation, are an important part of hedging against long-term private
+   key compromise.  In general, key rotations represent a trade-off
+   between Client privacy and Issuer security.  Therefore, it is
+   important that key rotations occur on a regular cycle to reduce the
+   harm of an Issuer key compromise.
+
+   Lastly, if Clients are willing to issue and redeem tokens from a
+   large number of Issuers for a specific Origin and that Origin accepts
+   tokens from all Issuers, partitioning can occur.  As an example, if a
+   Client obtains tokens from many Issuers and an Origin later
+   challenges that Client for a token from each Issuer, the Origin can
+   learn information about the Client.  This arrangement might happen if
+   Clients request tokens from different Issuers, each of which has
+   different Attester preferences.  Each per-Issuer token that a Client
+   holds essentially corresponds to a bit of information about the
+   Client that the Origin learns.  Therefore, there is an exponential
+   loss in privacy relative to the number of Issuers.
+
+   The fundamental problem here is that the number of possible issuance
+   configurations, including the keys in use and the Issuer identities
+   themselves, can partition the Client anonymity set.  To mitigate this
+   problem, Clients SHOULD bound the number of active issuance
+   configurations per Origin as well as across Origins.  Moreover,
+   Clients SHOULD employ some form of consistency mechanism to ensure
+   that they receive the same configuration information and are not
+   being actively partitioned into smaller anonymity sets.  See
+   [CONSISTENCY] for possible consistency mechanisms.  Depending on the
+   deployment, the Attester might assist the Client in applying these
+   consistency checks across Clients.  Failure to apply a consistency
+   check can allow Client-specific keys to violate Origin-Client
+   unlinkability.
+
+6.3.  Partitioning by Side Channels
+
+   Side-channel attacks, such as those based on timing correlation,
+   could be used to reduce anonymity set size.  In particular, for
+   interactive tokens that are bound to a Client-specific redemption
+   context, the anonymity set of Clients during the issuance protocol
+   consists of those Clients that started issuance between the time of
+   the Origin's challenge and the corresponding token redemption.
+   Depending on the number of Clients using a particular Issuer during
+   that time window, the set can be small.  Applications should take
+   such side channels into consideration before choosing a particular
+   deployment model and type of token challenge and redemption context.
+
+7.  Security Considerations
+
+   This document describes security and privacy requirements for the
+   Privacy Pass redemption and issuance protocols.  It also describes
+   deployment models built around non-collusion assumptions and privacy
+   considerations for using Privacy Pass within those models.  Ensuring
+   Client privacy -- separation of attestation and redemption contexts
+   -- requires active work on behalf of the Client, especially in the
+   presence of malicious Issuers and Origins.  Implementing the
+   mitigations discussed in Sections 4 and 6 is therefore necessary to
+   ensure that Privacy Pass offers meaningful privacy improvements to
+   end users.
+
+7.1.  Token Caching
+
+   Depending on the Origin's token challenge, Clients can request and
+   cache more than one token using an issuance protocol.  Cached tokens
+   help improve privacy by separating the time of token issuance from
+   the time of token redemption; they also allow Clients to reduce the
+   overhead of receiving new tokens via the issuance protocol.
+
+   As a consequence, Origins that send token challenges that are
+   compatible with cached tokens need to take precautions to ensure that
+   tokens are not replayed.  This is typically done via keeping track of
+   tokens that are redeemed for the period of time in which cached
+   tokens would be accepted for particular challenges.
+
+   Moreover, since tokens are not intrinsically bound to Clients, it is
+   possible for malicious Clients to collude and share tokens in a so-
+   called "hoarding attack".  As an example of this attack, many
+   distributed Clients could obtain cacheable tokens and then share them
+   with a single Client to redeem the tokens in a way that would violate
+   an Origin's attempt to limit tokens to any one particular Client.  In
+   general, mechanisms for mitigating hoarding attacks depend on the
+   deployment model and use case.  For example, in the Joint Origin and
+   Issuer model, comparing the issuance and redemption contexts can help
+   detect hoarding attacks, i.e., if the distribution of redemption
+   contexts is noticeably different from the distribution of issuance
+   contexts.  Rate-limiting issuance, at either the Client, Attester, or
+   Issuer, can also help mitigate these attacks.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [AUTHSCHEME]
+              Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
+              HTTP Authentication Scheme", RFC 9577,
+              DOI 10.17487/RFC9577, June 2024,
+              <https://www.rfc-editor.org/info/rfc9577>.
+
+   [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>.
+
+   [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>.
+
+9.2.  Informative References
+
+   [CENTRALIZATION]
+              Nottingham, M., "Centralization, Decentralization, and
+              Internet Standards", RFC 9518, DOI 10.17487/RFC9518,
+              December 2023, <https://www.rfc-editor.org/info/rfc9518>.
+
+   [CONSISTENCY]
+              Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
+              "Key Consistency and Discovery", Work in Progress,
+              Internet-Draft, draft-ietf-privacypass-key-consistency-01,
+              10 July 2023, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-privacypass-key-consistency-01>.
+
+   [DMS2004]  Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
+              Second-Generation Onion Router", May 2004,
+              <https://svn.torproject.org/svn/projects/design-paper/tor-
+              design.html>.
+
+   [HIJK21]   Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee,
+              C-K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S.,
+              Sung, Y-C., and A. Zhang, "DIT: De-Identified
+              Authenticated Telemetry at Scale", January 2021,
+              <https://research.fb.com/privatestats>.
+
+   [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>.
+
+   [KLOR20]   Kreuter, B., Lepoint, T., Orrù, M., Raykova, M., and
+              Springer International Publishing, "Anonymous Tokens with
+              Private Metadata Bit", Advances in Cryptology - CRYPTO
+              2020, pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, 2020,
+              <https://doi.org/10.1007/978-3-030-56784-2_11>.
+
+   [OHTTP]    Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
+              DOI 10.17487/RFC9458, January 2024,
+              <https://www.rfc-editor.org/info/rfc9458>.
+
+   [PrivacyPassCloudflare]
+              Sullivan, N., "Cloudflare supports Privacy Pass", November
+              2017, <https://blog.cloudflare.com/cloudflare-supports-
+              privacy-pass/>.
+
+   [RATE-LIMITED]
+              Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and
+              C. A. Wood, "Rate-Limited Token Issuance Protocol", Work
+              in Progress, Internet-Draft, draft-ietf-privacypass-rate-
+              limit-tokens-06, 1 April 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-
+              privacypass-rate-limit-tokens-06>.
+
+   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
+              W. Pan, "Remote ATtestation procedureS (RATS)
+              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
+              2023, <https://www.rfc-editor.org/info/rfc9334>.
+
+Acknowledgements
+
+   The authors would like to thank Eric Kinnear, Scott Hendrickson,
+   Tommy Pauly, Christopher Patton, Benjamin Schwartz, Martin Thomson,
+   Steven Valdez, and other contributors of the Privacy Pass Working
+   Group for many helpful contributions to this document.
+
+Authors' Addresses
+
+   Alex Davidson
+   NOVA LINCS, Universidade NOVA de Lisboa
+   Largo da Torre
+   Caparica
+   Portugal
+   Email: alex.davidson92@gmail.com
+
+
+   Jana Iyengar
+   Fastly
+   Email: jri@fastly.com
+
+
+   Christopher A. Wood
+   Cloudflare
+   101 Townsend St
+   San Francisco, CA 94107
+   United States of America
+   Email: caw@heapingbits.net