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

This html diff was produced by rfcdiff 1.48.