RFC 9576
The Privacy Pass Architecture
The Privacy Pass Architecture 🦋
Okay bestie, this is RFC 9576, and it's called The Privacy Pass Architecture ✨. It comes from the Internet Engineering Task Force (IETF) and it's dated June 2024. Its category is Informational 💅, and its ISSN is 2070-1721. The authors are A. Davidson (NOVA LINCS, Universidade NOVA de Lisboa), J. Iyengar (Fastly), and C. A. Wood (Cloudflare) 🫶. The header doesn't list anything it obsoletes or updates.
Abstract
okay so the abstract says this doc specifies the Privacy Pass architecture and the requirements for its building-block protocols 🧚. Those protocols are used for authorization that's based on privacy-preserving authentication mechanisms 🔐. It walks through the conceptual model, the security and privacy goals, practical deployment models, and recommendations for each deployment model, all so the security and privacy goals actually get met 💖.
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes 📚.
It's a product of the IETF, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9576 🔗.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date. Please read them carefully, because they spell out your rights and restrictions for this doc 📝. Any Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License ⚖️.
Table of Contents
1. Introduction
2. Terminology
3. Architecture
3.1. Overview
3.2. Use Cases
3.3. Privacy Goals and Threat Model
3.4. Redemption Protocol
3.5. Issuance Protocol
3.5.1. Attester Role
3.5.2. Issuer Role
3.5.3. Issuance Metadata
3.5.4. Future Issuance Protocol Requirements
3.6. Information Flow
3.6.1. Token Challenge Flow
3.6.2. Attestation Flow
3.6.3. Issuance Flow
3.6.4. Token Redemption Flow
4. Deployment Models
4.1. Shared Origin, Attester, Issuer
4.2. Joint Attester and Issuer
4.3. Joint Origin and Issuer
4.4. Split Origin, Attester, Issuer
5. Deployment Considerations
5.1. Discriminatory Treatment
5.2. Centralization
6. Privacy Considerations
6.1. Partitioning by Issuance Metadata
6.2. Partitioning by Issuance Consistency
6.3. Partitioning by Side Channels
7. Security Considerations
7.1. Token Caching
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction
Privacy Pass is an architecture for authorization built on privacy-preserving authentication mechanisms 🦋. Here's the vibe: relying parties authenticate Clients in a privacy-preserving way, meaning they don't learn any unique, per-Client info through the authentication protocol 🙈. Then they make an authorization decision based on whether that authentication worked or failed ✅. The decision could be giving a Client read access to a resource, or write access to one 📖✍️.
Typical ways of authorizing Clients, like long-term state in cookies, aren't very privacy friendly 😬. They let servers track Clients across sessions and interactions. Privacy Pass goes a different route 💜. Instead of showing a server linkable state, like a cookie saying "this person is an authorized user" or "this person finished some earlier challenge," the Client shows unlinkable proofs that attest to that same info ✨. These proofs, called tokens, are private in the sense that a given token can't be linked back to the protocol interaction where it was first issued 🫣.
At a high level, the architecture has two protocols: redemption and issuance 🧩. The redemption protocol, described in [AUTHSCHEME], runs between Clients and Origins (servers). Origins can challenge Clients to present tokens to be consumed 🎀. The Origin verifies the token to authenticate the Client, all without learning anything specific about the Client 🤐. Then it makes an authorization decision based on whether the token verified successfully. Depending on the kind of token (for example, whether it can be cached), the Client either presents a token it already got, or it runs an issuance protocol, like the ones described in [ISSUANCE], to get a fresh token to present as authorization 🌸.
This document lays out the requirements for both the redemption and issuance protocols, and how they work together 🧚♀️. It also gives recommendations on how the architecture should be deployed so Clients stay private and all the participating entities stay secure 🔒💅.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀. That's the rule, bestie, so pay attention to the capitals 👀.
Here are the terms used all throughout this doc 📚:
- Client: An entity that seeks authorization to an Origin. Using terminology from [RFC9334], Clients implement the Remote ATtestation procedureS (RATS) Attester role 💁♀️.
- Token: A cryptographic authentication message used for authorization decisions. It's the output of an issuance mechanism or protocol 🔑.
- Origin: An entity that consumes the tokens Clients present and uses them to make authorization decisions 👑.
- Token challenge: The mechanism Origins use to request tokens from Clients. It's often denoted TokenChallenge 🙋♀️.
- Token request: A message Clients use to request a token from an Issuer. It's often denoted TokenRequest 📨.
- Token response: A message Issuers use to send tokens to a Client. It's often denoted TokenResponse 📬.
- Redemption: The mechanism by which Clients present tokens to Origins for authorization purposes 🎟️.
- Issuer: An entity that issues tokens to Clients for properties the Attester has attested to 🏷️.
- Issuance: The mechanism by which an Issuer produces tokens for Clients 🏭.
- Attester: An entity that attests to properties of Clients for token issuance. Using terminology from [RFC9334], Attesters implement the RATS Verifier role 🕵️♀️.
- Attestation procedure: The procedure an Attester uses to decide whether a Client has the specific set of properties needed for token issuance 🔍.
The trust relationships between each of the entities on this list get broken down further in Section 3.3 🧠.
3. Architecture
The Privacy Pass architecture has four logical entities (Client, Origin, Issuer, and Attester) that work together for token redemption and issuance 🤝. This section gives an overview of Privacy Pass, a high-level look at the architecture's threat model and privacy goals, and the goals and requirements of the redemption and issuance protocols 🦋. Deployment variations for the Origin, Issuer, and Attester, including what to think about when implementing these entities, get covered in Section 4 💖.
(Part 1 of 7. More coming up, bestie 🌈✨)
3.1. Overview ✨
okay so this section walks through the typical flow for Privacy Pass, and there's a diagram (Figure 1) to go with it 🦋 let's go step by step bestie 💅
- A Client talks to an Origin by sending a request or doing something else that makes the Origin respond with a token challenge 📩. The token challenge names a specific Issuer to use 🎯.
- If the Client already has a token that works for the token challenge, like because it's got a cache of tokens it got earlier, it can skip ahead to step 6 and redeem that token 🏃♀️💨. Be careful though! Check Section 7.1 for the security stuff about cached tokens 😭🔥.
- If the Client doesn't have a token and wants one bound to the token challenge, it starts the issuance protocol 🎀. But first, the Client has to go through the deployment-specific attestation process that the designated Issuer requires 🛡️. Attestation can look like solving a CAPTCHA, checking that a device or hardware attestation is valid, and so on. See Section 3.5.1 for more details 🌸.
- If attestation finishes successfully, the Client makes a token request for the designated Issuer 💌. This usually goes through the Attester, but it doesn't HAVE to, so no cap it's flexible 🫶. The Attester and Issuer might be functions on the same server, depending on the deployment model (see Section 4) 🖥️. Depending on the attestation process, attestation can run alongside the issuance protocol, like when Clients send the attestation info to the Attester together with their token request 🧚. If attestation fails, the Client gets an error and issuance aborts without a token 💀.
- The Issuer makes a token response based on the token request and sends it back to the Client, usually through the Attester 📬. Once the Client gets the token response, it computes a token from the token challenge and the token response ✨. Anyone who has the per-Issuer key can validate this token, but it can't be linked back to the content of the token request or token response 🔐🙈.
- If the Client has a token, it puts it in a later request to the Origin as authorization 👑. A token is only sent once in reaction to a challenge. Clients don't send tokens more than once, even if they get duplicate or redundant challenges 🚫. The Origin checks that the token came from the expected Issuer and hasn't already been redeemed for the matching token challenge 🔍. If the Client doesn't have a token, maybe because issuance failed, it does not answer the Origin's challenge with a new request 🙅♀️.
+--------+ +--------+ +----------+ +--------+
| Origin | | Client | | Attester | | Issuer |
+---+----+ +---+----+ +----+-----+ +---+----+
| | | |
|<----- Request ------+ | |
+-- TokenChallenge -->| | |
| |<== Attestation ==>| |
| | | |
| +--------- TokenRequest ------->|
| |<-------- TokenResponse -------+
|<-- Request+Token ---+ | |
| | | |Figure 1: Privacy Pass Redemption and Issuance Protocol Interaction 🎨
3.2. Use Cases 🌈
okay so use cases for Privacy Pass are super broad and totally depend on the deployment model (Section 4 has the deets) 💖. The original big motivating use case for Privacy Pass [PrivacyPassCloudflare] was helping rate-limit malicious or abusive traffic from services like Tor [DMS2004] 🧅. The generalized, evolved architecture in this document works for that use case too 🙌. But for extra clarity, here are some more possible use cases 👀.
- Low-quality, anti-fraud signal for open Internet services. Tokens can show that the Client behind the user agent is likely not a bot trying some kind of automated attack, like credential stuffing 🤖🚫. Example attestation procedures for this use case might be solving some form of CAPTCHA or showing evidence of a valid, unlocked device in good standing 🔓✨.
- Privacy-preserving authentication for proprietary services. Tokens can show that the Client is a valid subscriber for a proprietary service, such as a deployment of Oblivious HTTP [OHTTP] 🔒💜.
3.3. Privacy Goals and Threat Model 🔒✨
okay bestie, so the end-to-end flow from Section 3.1 has three different contexts 🦋
- Redemption context 🌸: this is the stuff shared between the Client and the Origin. It's everything the Origin gets to see during redemption that could identify a Client or help build a token challenge. That includes the timestamp, Client-visible info (like the IP address), and the Origin name.
- Issuance context 💌: this is what the Client, Attester, and Issuer share. It's everything the Attester and Issuer can see during issuance that might identify a Client. That covers the timestamp, Client-visible info (IP address again), and the Origin name if it gets revealed during issuance. The full token challenge is NOT in here, because it's kept secret from the Issuer during the issuance protocol 🙈
- Attestation context 🧚: this one is just between the Client and the Attester, only for checking that the Client is valid. It has the timestamp, Client-visible info, and anything the attestation procedure needs to finish.
The privacy goals of Privacy Pass rely on a threat model where Origins trust specific Issuers to make tokens, and Issuers trust one or more Attesters to run attestation with Clients properly 👑. That's the whole point: a token that validates for a given Issuer was only issued to a Client who passed attestation with an Attester that Issuer trusts. Also, if an Origin accepts tokens from an Issuer that trusts several Attesters, the Client can pick any one of them to issue and redeem tokens for that Origin. Whether the entities collude to learn the redemption, issuance, or attestation contexts (and what's needed for context unlinkability) depends on the deployment model. See Section 4 for the deets 💅
How trust gets set up between each entity is deployment-specific. For example, when Clients go to Issuers through an Attester, the Attesters and Issuers might use mutually authenticated TLS to authenticate each other 🔐. When Clients don't go through an Attester, the Attesters might pass along that trust using a digital signature the Issuers can verify.
Clients explicitly trust Attesters to do attestation correctly and without violating their privacy. Like, Attesters who might know private info about Clients are trusted NOT to spill it to non-colluding parties 🤐. Colluding parties are assumed to have access to the same information (see Section 4 for deployment models and non-collusion assumptions). But Clients assume Issuers and Origins are malicious 💀
With all that in mind, the privacy goals are all about unlinkability based on the redemption, issuance, and attestation contexts:
- Origin-Client unlinkability. Given two redemption contexts, the Origin can't tell whether they belong to the same Client or two different Clients. Basically, a Client in a redemption context looks the same as any other Client that could use that redemption context. The group of Clients sharing a redemption context is called a redemption anonymity set 🎀
- Issuer-Client unlinkability. This is like Origin-Client unlinkability. A Client in an issuance context is indistinguishable from any other Client that could use that same issuance context. The group sharing an issuance context is an issuance anonymity set 🌈
- Attester-Origin unlinkability. This is similar to the other two. Given two attestation contexts, the Attester can't tell whether they correspond to the same Origin or to different Origins. The group of Origins sharing an attestation context is an attestation anonymity set 🍓
- Redemption context unlinkability. Given two redemption contexts, the Origin can't figure out which issuance and attestation contexts each redemption matches up with, even if the Issuer and Attester team up (in case they're different parties). So anything that can be learned about the Client during issuance and attestation can't be used by the Origin to hurt Client privacy ✨
These unlinkability properties make sure only the Clients get to connect the dots between info that could identify them and what they do on the Origin. The Attester, Issuer, and Origin only get the info they need for their own jobs 💜
How these properties actually get achieved depends on the deployment model, the type of attestation, and the details of the issuance protocol. For example, as covered in Section 4, sometimes you need an anonymization service that hides Client IP addresses, like Tor [DMS2004] 🧅 Generally, anonymization services make sure all Clients using the service look the same to each other. In practice, though, there may be small giveaways (TLS fingerprints, HTTP headers, etc.) 👀 Clients usually trust these services not to disclose private info (like IP addresses) to untrusted parties. And if you DON'T use an anonymization service when talking to Attesters, Issuers, or Origins, the set of possible Clients can get split up by IP address, which can lead to unlinkability violations 😭 Malicious Origins might also try to link two redemption contexts together by using Client-specific Issuer Public Keys. See Sections 5 and 6 for more.
Sections 3.4 and 3.5 go deeper into the functional properties and security requirements of the redemption and issuance protocols. Section 3.6 explains how information flows between the Issuer, Origin, Client, and Attester through these protocols 🦋
3.4. Redemption Protocol 🎟️
The Privacy Pass redemption protocol, described in [AUTHSCHEME], is an authorization protocol where Clients present tokens to Origins for authorization. Usually, redemption comes after a challenge: the Origin challenges the Client for a token with a TokenChallenge ([AUTHSCHEME], Section 2.1), and if it can, the Client presents a valid token ([AUTHSCHEME], Section 2.2) in response. Here's how that goes:
+--------+ +--------+
| Origin | | Client |
+---+----+ +---+----+
| |
|<----- Request ------+
+-- TokenChallenge -->|
| | <== Issuance protocol ==>
|<-- Request+Token ---+
| |Figure 2: Challenge and Redemption Protocol Interaction
Alternatively, if it's configured to, a Client may just throw token values at Origins without a matching TokenChallenge 🤷♀️
The structure and meaning of the TokenChallenge and token messages depend on the issuance protocol and token type in use. Check [AUTHSCHEME] for the details 📚
The challenge gives the Client what it needs to get tokens the server might accept later in the redemption context. The token can vary based on the challenge in a few ways:
- Issuance protocol. The challenge says which issuance protocol is needed to make the token. Different issuance protocols have different security properties. Like, some might make tokens that are publicly verifiable, and others might not 🔍
- Issuer identity. Token challenges say which Issuers are trusted for a given issuance protocol. As Section 3.3 explained, the choice of Issuer decides which Attesters and attestation procedures are possible for a token from that Issuer. But the Origin doesn't learn exactly which Attester was used for a given issuance event 🫣
- Redemption context. Challenges can be tied to a redemption context, which affects whether a Client can pre-fetch and cache tokens. For example, an empty redemption context always lets tokens be issued and redeemed non-interactively. A fresh and random redemption context means the redeemed token has to be issued only AFTER the Client gets the challenge. See Section 2.1.1 of [AUTHSCHEME] for more 🌸
- Per-Origin or cross-Origin. Challenges can be limited to the Origin they came from (per-Origin tokens) or work across several Origins (cross-Origin tokens). The set of Origins a cross-Origin token applies to is called the cross-Origin set. Joining that set means explicitly agreeing on what's in it. By opting in, every Origin in a cross-Origin set agrees to accept tokens for any other Origin in the set 🤝 See Section 2.1.1 of [AUTHSCHEME] for how the set gets created.
Origins that accept cross-Origin tokens take on some risk, because a token issued for one Origin can be spent at another Origin in the cross-Origin set. That makes it hard to regulate how tokens get used 🚨
Depending on the use case, Origins might need to keep state to track redeemed tokens. For example, Origins that accept cross-Origin tokens across shared redemption contexts SHOULD track which tokens have already been redeemed in those contexts, since these tokens can be issued and then spent multiple times for any such challenge 🧾 Also, Clients that redeem the same token at multiple Origins risk letting those Origins link their activity together, which can discourage that behavior. See Section 2.1.1 of [AUTHSCHEME] for the discussion.
How Clients respond to token challenges can have privacy implications too. For example, if an Origin lets the Client pick an Issuer, that choice can reveal info about the Client, which can be used to split up anonymity sets. See Section 6.2 for more on these privacy considerations 💖
3.5. Issuance Protocol 🎀
okay so the Privacy Pass issuance protocols (like the ones in [ISSUANCE]) are two-message protocols 💅 They take a TokenChallenge from the redemption protocol ([AUTHSCHEME], Section 2.1) as input and spit out a token ([AUTHSCHEME], Section 2.2). See Figure 1 for the visual, it's so cute 🦋
The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used. Check [ISSUANCE] for the deets ✨
Clients work with the Attester and Issuer to get a token for a challenge 🌸 The context where an Attester vouches for a Client during issuance is called the attestation context. It holds all the info about the issuance event, like the timestamp and the Client-visible stuff, such as the IP address or whatever else is specific to the type of attestation being done 👀
Each issuance protocol can be totally different 💖 Like, the number and types of participants, the cryptographic constructions used when issuing tokens, and even the privacy properties can all change from one to the next 🧚
Clients kick off the issuance protocol with the token challenge, a randomly generated nonce, and a public key for the Issuer. All of these are the Client's private input to the protocol and get bound to an output token in the end. See Section 2.2 of [AUTHSCHEME] for the full details. Future specifications may change or extend what the Client puts in to make tokens with a different structure 🌈
Token properties depend on the issuance protocol. These are the important ones this architecture supports ✨
- Public verifiability. This means the token can be verified using the Issuer Public Key. A token that doesn't have public verifiability can only be verified using the Issuer secret key.
- Public metadata. This means the token can be cryptographically bound to arbitrary public information. See Section 6.1 for privacy considerations regarding public metadata.
- Private metadata. This means the token can be cryptographically bound to arbitrary private information, i.e., information that the Client doesn't observe during token issuance or redemption. See Section 6.1 for privacy considerations regarding private metadata 🔐
The issuance protocol itself can be any interactive protocol between the Client, Issuer, or other parties, as long as it produces a valid token bound to the Client's private input. It has to meet these security requirements, no exceptions 😤
- Unconditional input secrecy. The issuance protocol MUST NOT reveal anything about the Client's private input, including the challenge and nonce, to the Attester or Issuer, regardless of the hardness assumptions of the underlying cryptographic protocol(s). This property is sometimes also referred to as blindness 🙈
- One-more forgery security. The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens offline or otherwise without interacting with the Issuer directly 🚫
- Concurrent security. The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients, Attesters, and Issuers 💜
See Section 3.5.4 for requirements on new issuance protocol variants and related extensions.
In the sections below, we get into the Attester and Issuer roles in more detail 🫶
3.5.1. Attester Role
In Privacy Pass, attestation is how an Attester bears witness to, confirms, or authenticates a Client so it can verify properties about the Client that are required for issuance. Issuers trust Attesters to do attestation correctly, which means implementing the attestation procedures so that malicious Clients can't subvert or bypass them 🛡️
[RFC9334] describes an architecture for attestation procedures. Using that as the conceptual basis, Clients are RATS Attesters that produce attestation evidence, and Attesters are RATS Verifiers that appraise the validity of that evidence 🤓
The type of attestation procedure is a deployment-specific choice and is outside the scope of the issuance protocol. Some example attestation procedures are below ✨
- Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to have this capability, so they can be ruled out as a bot or some other automated Client 🤖
- Presenting evidence of Client device validity. Some Clients run on trusted hardware that can produce device-level attestation evidence 📱
- Proving properties about Client state. Clients can be associated with state, and the Attester can verify this state. Examples of state include the Client's geographic region and whether the Client has a valid application-layer account 🌍
Attesters may support different types of attestation procedures 🦋
Each attestation procedure has different security properties. For example, attesting to having a valid account is not the same as attesting to running on trusted hardware. Supporting multiple attestation procedures is an important step toward equitable access for Clients, see Section 5.1 👑
The role of the Attester in the issuance protocol and its impact on privacy depend on the type of attestation procedure, the issuance protocol, and the deployment model. For instance, increasing the number of required attestation procedures could shrink the overall anonymity set size. Like, the number of Clients that have solved a CAPTCHA in the past day, that have a valid account, and that are running on a trusted device is less than the number of Clients that have solved a CAPTCHA in the past day 😭 See Section 6.2 for more on how a variety of attestation procedures can hurt Client privacy.
Depending on the issuance protocol, the Issuer might learn information about the Origin. To get Issuer-Client unlinkability, the Issuer should be unable to link that information to a specific Client. For issuance protocols where the Attester has access to Client-specific information (like attestation procedures that involve Client-specific information such as application-layer account info, or deployment models where the Attester learns Client-specific information such as Client IP addresses), Clients trust the Attester to not share any Client-specific information with the Issuer. In deployments where the Attester doesn't learn Client-specific information, or where the Attester and Issuer are run by the same entity (like in the Joint Attester and Issuer model described in Section 4.2), the Client doesn't need to explicitly trust the Attester about this 🙌
Issuers trust Attesters to correctly and reliably perform attestation. However, some types of attestation procedures can change in value over time, e.g., if the procedure gets compromised. Broken attestation procedures are treated as exceptional events and need configuration changes to fix the underlying cause. For example, if an attestation procedure gets compromised or subverted because of a zero-day exploit on devices that implement it, then the corresponding attestation procedure should be untrusted until the exploit is patched. So addressing changes in attestation quality is a deployment-specific task 🛠️ In Split Origin, Attester, and Issuer deployments (see Section 4.4), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched.
Okay, this next part is the big spicy one 🚨 From the perspective of an Origin, tokens produced by an Issuer with at least one compromised Attester can't be trusted, assuming the Origin doesn't know which attestation procedure was used for issuance. That's because the Origin can't tell tokens issued via compromised Attesters apart from tokens issued via uncompromised ones, unless there's some distinguishing info in the tokens themselves or from the Issuer. So until the attestation procedure is fixed, the Issuer can't be trusted by Origins. And as a consequence, any tokens issued by an Issuer with a compromised Attester may no longer be trusted by Origins, even the ones given to Clients who interacted with an uncompromised Attester. Yikes 💀
3.5.2. Issuer Role
In Privacy Pass, the Issuer is responsible for completing the issuance protocol for Clients that complete attestation through a trusted Attester. As described in Section 3.5.1, Issuers explicitly trust Attesters to correctly and reliably perform attestation. Origins explicitly trust Issuers to only issue tokens from trusted Attesters. Clients do not explicitly trust Issuers 🫡
Depending on the deployment model, issuance may need some form of Client anonymization service, kind of like an IP-hiding proxy, so that Issuers can't learn info about Clients. This can come from an explicit participant in the issuance protocol, or from external means, like an IP-hiding proxy service such as Tor [DMS2004]. In general, Clients SHOULD minimize or remove identifying information where possible when invoking the issuance protocol 🕶️
Issuers are uniquely identifiable by all Clients with a consistent identifier. In a web context, this identifier might be the Issuer hostname 🌐 Issuers maintain one or more configurations, including issuance key pairs, for use in the issuance protocol. Each configuration is assumed to have a unique and canonical identifier, sometimes called a key identifier or key ID. Issuers can rotate these configurations as needed to reduce the risk of compromise, see Section 6.2 for more considerations around configuration rotation 🔄 The Issuer Public Key for each active configuration is made available to Origins and Clients for use in the issuance and redemption protocols 💖
3.5.3. Issuance Metadata ✨
Okay, so some versions of the issuance protocol can let public or private metadata get cryptographically bound to a token 🎀. A super simple way to add public metadata is to give each value its own Issuer Public Key, so N keys give you log_2(N) bits of metadata 🧚. Metadata can be public or private 💅.
Public metadata is stuff the Client can see during the token issuance flow 👀. It can be transparent or opaque. Transparent public metadata is a value that either the Client makes up itself or the Issuer hands over during the flow, and the Client can double-check that it's correct 💖. Opaque public metadata is something the Client can see but can't verify 🙈. For example, opaque public metadata might be a "fraud detection signal" that gets computed for the Issuer during token issuance. Honestly, Clients generally can't tell whether that value was made in a way that allows tracking 💀.
Private metadata is stuff the Clients can't observe during the token issuance flow 🔒. These setups can be built on the private metadata bit construction from Kreuter et al. [KLOR20] or on the attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) from Huang et al. [HIJK21] 🦋.
Metadata can be arbitrarily long or have a bounded length 📏. An application or the underlying cryptographic protocol decides how much metadata is allowed 🍓. The total number of metadata bits in a token is the public bits plus the private bits added together ✨. Every single bit of metadata can be used to split the Client issuance or redemption anonymity sets, so check out Section 6.1 for more on that 🌈.
3.5.4. Future Issuance Protocol Requirements 🔮
The Privacy Pass architecture and ecosystem are both designed to be open to new stuff, like new issuance protocols that add extra functionality 🚀. Every new issuance protocol and extension MUST follow these requirements, no exceptions bestie 👑:
- Include a detailed analysis of the privacy impacts of the extension, explain why those impacts are justified, and give guidelines on how to use the protocol to reduce or minimize any negative deployment or privacy consequences from Sections 5 and 6, respectively 🛡️.
- Follow the guidelines in Section 3.5.2 for managing Issuer Public Key data 🗝️.
- Clearly specify how to interpret and validate TokenChallenge and token messages that get exchanged during the redemption protocol 📬.
3.6. Information Flow 🌊
The whole end-to-end process of redemption and issuance involves information flowing between the Issuer, Origin, Client, and Attester 💫. That info can affect the privacy goals Privacy Pass is trying to provide, as laid out in Section 3.3 🎯. In this section we walk through how info moves between each party. How this info plays into the privacy goals in specific deployment models gets covered in Section 4 💅.
3.6.1. Token Challenge Flow 🎀
Okay, so to use Privacy Pass, Origins pick an Issuer that they're willing to accept tokens from 🏷️. Then the Origin builds a token challenge using that Issuer and some info from the redemption context it shares with the Client 🧩. That token challenge gets delivered to a Client 📨. The token challenge tells you stuff about the Issuer and the redemption context, like whether the Origin wants a per-Origin or a cross-Origin token 🌍. Anyone who sees the token challenge might learn things about the Client as the Origin knows them 👀. This is why input secrecy is a requirement for issuance protocols, since it makes sure the challenge isn't directly available to the Issuer 🔐. Main character protection, honestly 👑.
3.6.2. Attestation Flow 🛂
Clients interact with the Attester to prove that they meet some required set of properties ✅. While they do that, Clients add info to the attestation context, which could include sensitive stuff like application-layer identities, IP addresses, and so on 😬. Clients get to choose whether or not to share this info, based on their local policy or preferences 💜.
3.6.3. Issuance Flow 🪄
Clients use the issuance protocol to make a token that's bound to a token challenge 💌. Along the way, the issuance protocol can add info to the attestation or issuance contexts in a few different ways. For example, a token request can add info to those contexts, as described below 🍰.
- Issuance protocol. The type of issuance protocol can reveal info about the Issuer's capabilities to the attestation or issuance contexts, plus the capabilities of a given Client 🧠. For example, if a Client gets offered multiple issuance protocol options, then which one it picks can reveal stuff about that Client's capabilities 🎨.
- Issuer configuration. Info about the Issuer configuration, like its identity or the public key it uses to validate the tokens it makes, can get revealed during issuance and add to the attestation or issuance contexts 🔑.
- Attestation information. The issuance protocol can add info to the attestation or issuance contexts depending on which attestation procedure the Issuer uses to trust a token request 🕵️♀️. Specifically, a token request validated by a given Attester means the Client that made that request must be able to complete the designated attestation procedure 💪.
- Origin information. The issuance protocol can reveal info about the Origin that challenged the Client; check out Section 3.6.1 🗺️. Specifically, a token request designated for a specific Issuer might imply that the resulting token is for an Origin that trusts that Issuer 🤝. But that's not always true, because some token requests can correspond to cross-Origin tokens, meaning tokens that would be accepted at any Origin that accepts the cross-Origin token 🌐.
Also, a token can add info to the issuance attestation or contexts as described below 🫶.
- Origin information. The issuance protocol can reveal info about the Origin through how it responds to a token request 📣. For example, if an Issuer learns the Origin during issuance and is also set up to respond in some way based on that info, and the Client interacts with the Issuer indirectly through the Attester, then that response can reveal info to the Attester 🫢.
- Token. The token made by the issuance protocol can contain info from the issuance context 🎁. Specifically, depending on the issuance protocol, tokens can contain public or private metadata, and Issuers can choose that metadata based on info in the issuance context 🧁.
Exceptional cases in the issuance protocol, like when either the Attester or the Issuer aborts the protocol, can add info to the attestation or issuance contexts 🚨. How much info in this context harms the Issuer-Client or Attester-Origin unlinkability goals from Section 3.3 depends on the deployment model, so check out Section 4 💅. Clients get to choose whether or not to add info to these contexts, based on local policy or preference ✨.
3.6.4. Token Redemption Flow 🎟️
Clients send tokens to Origins during the redemption protocol 📤. So any info added to the token during issuance can get sent to the Origin 💌. Info can be either (1) passed explicitly in a token or (2) implied by the way the Client responds to a token challenge 🕊️. For example, if a Client fails to finish issuance and therefore can't redeem a token for a token challenge, that can reveal info to the Origin that it wouldn't otherwise have 😳. However, an Origin can't necessarily tell apart a Client that failed to complete issuance from one that just ignored the token challenge completely 🤷♀️.
4. Deployment Models 🏡
The Origin, Attester, and Issuer shown in Figure 1 can be set up and deployed in a bunch of different ways 🏗️. The deployment model directly affects how the attestation, issuance, and redemption contexts get separated to achieve Origin-Client, Issuer-Client, and Attester-Origin unlinkability 🔗.
This section covers some of the deployment models we expect, along with their security and privacy considerations 🧐. Each deployment model is described in terms of the trust relationships and communication patterns between the Client, Attester, Issuer, and Origin 🤓. Entities drawn inside the same bounding box are assumed to be run by the same party, so they're able to collude 🤝. Collusion can let someone link attestation, issuance, and redemption contexts together 🧵. Entities not drawn inside the same bounding box (in other words, run by separate parties) are assumed to not collude 🙅♀️. Mechanisms for enforcing non-collusion are out of scope for this architecture 🚫.
4.1. Shared Origin, Attester, Issuer 🍭
In this model, the Origin, Attester, and Issuer are all run by the same entity, as shown in Figure 3 💁♀️.
+---------------------------------------------.
+--------+ | +----------+ +--------+ +--------+ |
| Client | | | Attester | | Issuer | | Origin | |
+---+----+ | +-----+----+ +----+---+ +---+----+ |
| `-------|---------------|-------------|------'
|<-------------------------------- TokenChallenge --+
| | | |
|<=== Attestation ===>| | |
| | | |
+----------- TokenRequest ----------->| |
|<---------- TokenResponse -----------+ |
| |
+--------------------- Token ----------------------->
| |Figure 3: Shared Deployment Model 🖼️
This model is the initial deployment of Privacy Pass, as described in [PrivacyPassCloudflare] 🌟. In this model, the Attester, Issuer, and Origin share the attestation, issuance, and redemption contexts 🫂. Because of that, attestation mechanisms that can uniquely identify a Client are not appropriate, like requiring that Clients log in with some kind of application-layer account, since that could lead to unlinkability violations 🚨. Yikes, not a vibe 😭.
Origin-Client, Issuer-Client, and Attester-Origin unlinkability needs issuance and redemption events to be separated over time 🕰️. You can do that with tokens that match token challenges with an empty redemption context (see Section 3.4) ⏳. Or they can be separated over space, like by using an anonymizing service when connecting to the Origin 🌬️. Iykyk, separation is everything 💖.
4.2. Joint Attester and Issuer 💅
okay so in this model, the Attester and Issuer are run by the SAME entity, and that entity is separate from the Origin 🎀. The Origin trusts this joint Attester and Issuer to handle attestation and hand out tokens. Clients talk to the joint Attester and Issuer for both attestation and issuance. Check out Figure 4, it's giving one-stop shop 🧚
+------------------------------.
+--------+ | +----------+ +--------+ | +--------+
| Client | | | Attester | | Issuer | | | Origin |
+---+----+ | +-----+----+ +----+---+ | +---+----+
| `-------|---------------|-----' |
|<---------------------------------- TokenChallenge --+
| | | |
|<==== Attestation ====>| | |
| | | |
+------------- TokenRequest ----------->| |
|<----------- TokenResponse ------------+ |
| |
+----------------------- Token ----------------------->
| |Figure 4: Joint Attester and Issuer Deployment Model
This model is useful if an Origin wants to offload attestation and issuance to a trusted entity ✨. Here the Attester and Issuer share an attestation and issuance context for the Client, and that context is separate from the Origin's redemption context 🦋.
Similar to the shared Origin, Attester, Issuer model, Issuer-Client and Origin-Client unlinkability in this model requires that issuance and redemption events, respectively, be separated over time or space 💖. Attester-Origin unlinkability requires that the Attester and Issuer do not learn the Origin for a particular token request 🙈. For this reason, issuance protocols that require the Issuer to learn information about the Origin, such as the issuance protocol described in [RATE-LIMITED], are not appropriate, since they could lead to Attester-Origin unlinkability violations through the Origin name 💀.
4.3. Joint Origin and Issuer 🌸
In this model, the Origin and Issuer are run by the same entity, separate from the Attester, as shown in Figure 5 🍓. The Issuer accepts token requests that come from trusted Attesters. Since the Attester and Issuer are separate entities, this model needs some mechanism by which Issuers establish trust in the Attester (as described in Section 3.3) 🔐. For example, in settings where the Attester is a Client-trusted service that talks directly to the Issuer, one way to set that trust up is via mutually authenticated TLS. However, alternative authentication mechanisms are possible. ok I know I already said this, but in this model the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below 🙃
+----------------------------.
+--------+ +----------+ | +--------+ +--------+ |
| Client | | Attester | | | Issuer | | Origin | |
+---+----+ +-----+----+ | +----+---+ +---+----+ |
| | `------|-------------|------'
|<-------------------------------- TokenChallenge --+
| | | |
|<=== Attestation ===>| | |
| | | |
+------------ TokenRequest ---------->| |
|<---------- TokenResponse -----------+ |
| |
+--------------------- Token ----------------------->
| |Figure 5: Joint Origin and Issuer Deployment Model
This model is useful for Origins that need Client-identifying attestation, e.g., through the use of application-layer account information, but that don't otherwise want to learn information about individual Clients beyond what gets observed during token redemption, such as Client IP addresses 🥹.
In this model, attestation contexts are separate from Issuer and redemption contexts. As a result, any type of attestation is suitable here ✅.
Moreover, assuming that there is more than one Origin involved, any type of token challenge is suitable, since no single party will have access to the identifying Client information and the unique Origin information 👑. Issuers that produce tokens for a single Origin are not suitable in this model, since an Attester can infer the Origin from a token request, as described in Section 3.6.3 🚨. However, since the issuance protocol provides input secrecy, the Attester does not learn details about the corresponding token challenge, such as whether the token challenge is per Origin or across Origins 🫶.
4.4. Split Origin, Attester, Issuer 🪄
In this model, the Origin, Attester, and Issuer are all operated by different entities. As with the Joint Origin and Issuer model (Section 4.3), the Issuer accepts token requests that come from trusted Attesters, and the details of that trust depend on the issuance protocol and the relationship between the Attester and Issuer; see Section 3.3. This arrangement is shown in Figure 1 🌈.
This is the most general deployment model, and it's necessary for some types of issuance protocols where the Attester plays a role in token issuance; see [RATE-LIMITED] for one such type of issuance protocol 💜.
In this model, the Attester, Issuer, and Origin each have a separate view of the Client 👀. The Attester sees potentially sensitive Client-identifying information, such as account identifiers or IP addresses. The Issuer sees only the information necessary for issuance. The Origin sees token challenges, corresponding tokens, and Client source information, such as their IP address. As a result, attestation, issuance, and redemption contexts are separate, and therefore any type of token challenge is suitable in this model as long as there is more than a single Origin 🦋.
As with the Joint Origin and Issuer model (Section 4.3), and as described in Section 3.6.3, if the Issuer produces tokens for a single Origin, then per-Origin tokens are not appropriate, since the Attester can infer the Origin from a token request 🙅♀️.
5. Deployment Considerations 🎀
Section 4 covers deployment models that are possible in practice. Beyond the possible implications for the security and privacy properties of the resulting system, Privacy Pass deployments can affect the overall ecosystem in two important ways: (1) discriminatory treatment of Clients and the gated access to otherwise open services, and (2) centralization. This section describes considerations relevant to these topics 📚.
5.1. Discriminatory Treatment 🚫
Origins can use tokens as a signal for telling apart (1) Clients that are capable of completing attestation with one Attester trusted by the Origin's chosen Issuer and (2) Clients that are not capable of doing the same 🫣. A consequence of this is that Privacy Pass could enable discriminatory treatment of Clients based on attestation support. For example, an Origin could only authorize Clients that successfully authenticate with a token, prohibiting access to all other Clients 😤.
The types of attestation procedures supported for a particular deployment depend heavily on the use case 🧩. For example, picture a proprietary deployment of Privacy Pass that authorizes Clients to access a resource such as an anonymization service. In that context, it's reasonable to support specific types of attestation procedures that demonstrate that Clients can access the resource, such as with an account or a specific type of device 🔑. However, in open deployments of Privacy Pass that safeguard access to otherwise open or publicly accessible resources, diversity in attestation procedures is critically important, so as not to discriminate against Clients that choose certain software, hardware, or identity providers 🌍.
In principle, Issuers should strive to mitigate discriminatory behavior by providing equitable access to all Clients 🤝. This can be done by working with a set of Attesters that are suitable for all Clients. In practice, this may require trade-offs in what type of attestation Issuers are willing to trust, so as to enable more widespread support 🥺. In other words, trusting a variety of Attesters with a diverse set of attestation procedures would presumably increase support among Clients, though most likely at the expense of decreasing the overall value of tokens issued by the Issuer 📉.
For example, to disallow discriminatory behavior between Clients with and without device attestation support, an Issuer may wish to support Attesters that support CAPTCHA-based attestation 🤖. This means that the overall attestation value of a Privacy Pass token is bound by the difficulty of spoofing or bypassing either one of these attestation procedures 🛡️.
5.2. Centralization 🏰
A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization among those participants 😬. [CENTRALIZATION] discusses several ways in which this might be mitigated. For example, a multi-stakeholder governance model could be established to decide which candidate participants are fit to operate in a Privacy Pass deployment. This is precisely the system used to control the Web's trust model 🕸️.
Alternatively, Privacy Pass deployments might mitigate this problem through implementation 🛠️. For example, rather than centralize the role of attestation in one or a few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which Attester implementations were chosen. As a result, Clients could have more opportunities to switch between attestation participants 🔄.
6. Privacy Considerations 🔒
The previous section discussed how deployment details affect Origin-Client, Issuer-Client, and Attester-Origin unlinkability 🕵️♀️. The value these properties give end users depends on the size of the anonymity sets in which Clients or Origins are unlinkable. For example, consider two different deployments: one where there's a redemption anonymity set of size two, and another where there's a redemption anonymity set of size 2^32. Although Origin-Client unlinkability guarantees that the Origin cannot link any two requests to the same Client based on these contexts, the smaller these sets become, the higher the probability of determining the "true" Client 😱.
In practice, there are a number of ways the size of anonymity sets may be reduced or partitioned, though they all center around the concept of consistency 🧠. In particular, by definition, all Clients in an anonymity set share a consistent view of the information needed to run the issuance and redemption protocols. The Issuer Public Key is one example of the type of information needed to run these protocols 🔑. When two Clients have inconsistent information, they effectively have different redemption contexts and therefore belong in different anonymity sets 💔.
The following subsections discuss issues that can influence anonymity set size. For each issue, we discuss mitigations or safeguards to protect against the underlying problem 🛡️✨.
6.1. Partitioning by Issuance Metadata 🎀
Okay, so any metadata bits, public or private, can be used to slice the Client anonymity set into smaller pieces. 😬 An Issuer that wanted to track one specific Client could add a single metadata bit to Client tokens. For the tracked Client, it sets the bit to 1, and it sets 0 for everyone else. Adding more bits gives an exponential increase in tracking granularity, kind of like adding more Issuers, except with more potential targeting. 🎯
So deployments should take into account how much metadata an Issuer uses when creating tokens, together with whatever else Issuers might learn about Clients through other means. 🔍 This metadata can be really useful for real Privacy Pass deployments, so Issuers must balance that usefulness against the drop in Client privacy. It's a whole vibe check. ⚖️
How many metadata values are allowed often depends on the details of each deployment. In general, limiting the amount of metadata that's permitted helps keep metadata from uniquely identifying individual Clients. If the number of possible metadata values isn't bounded, Client privacy can go down. Most token types don't admit any metadata at all, so that bound is implicitly enforced. 🙌
6.2. Partitioning by Issuance Consistency 🧩
Anonymity sets can get partitioned by whatever information gets used in the issuance protocol. That includes metadata, Issuer configuration (keys), and Issuer selection. 💅
Any issuance metadata bits can partition the Client anonymity set. Same story as before: an Issuer that wanted to track a single Client could add a single metadata bit to Client tokens, setting it to 1 for the tracked Client and 0 otherwise. More bits means an exponential increase in tracking granularity, similar to introducing more Issuers, though with more potential targeting. 👀
The number of active Issuer configurations also contributes to partitioning. When an Issuer updates its configuration and the corresponding key pair, any Client that runs the issuance protocol with this configuration becomes part of a set of Clients that also ran issuance using that same configuration. 🫣 Updating configurations, for example through key rotation, is an important part of hedging against long-term private key compromise. Key rotations are a trade-off between Client privacy and Issuer security, so it's important that they happen on a regular cycle to reduce the harm of an Issuer key compromise. 🔑
Lastly, if Clients are willing to issue and redeem tokens from a large number of Issuers for one specific Origin, and that Origin accepts tokens from all Issuers, partitioning can happen. 😭 For example, if a Client gets tokens from many Issuers and an Origin later challenges that Client for a token from each Issuer, the Origin can learn information about the Client. This could happen if Clients request tokens from different Issuers, each with different Attester preferences. Every per-Issuer token a Client holds basically corresponds to one bit of information about the Client that the Origin learns, so the privacy loss is exponential in the number of Issuers. 📉
The fundamental problem is that the number of possible issuance configurations, including the keys in use and the Issuer identities themselves, can partition the Client anonymity set. To mitigate this, Clients SHOULD bound the number of active issuance configurations per Origin, as well as across Origins. 🛑 Clients SHOULD also use some form of consistency mechanism, so they get the same configuration information and aren't being actively partitioned into smaller anonymity sets. See [CONSISTENCY] for possible consistency mechanisms. Depending on the deployment, the Attester might help the Client apply these consistency checks across Clients. 🤝 Skipping a consistency check can let Client-specific keys violate Origin-Client unlinkability, and nobody wants that. 🚫
6.3. Partitioning by Side Channels 🕵️♀️
Side-channel attacks, like ones based on timing correlation, could be used to shrink the anonymity set. 🌀 In particular, for interactive tokens that are bound to a Client-specific redemption context, the anonymity set of Clients during the issuance protocol is made up of the Clients that started issuance between the time of the Origin's challenge and the corresponding token redemption. If not many Clients are using a particular Issuer during that window, the set can get really small. 😬 Applications should take these side channels into consideration before they choose a deployment model and a type of token challenge and redemption context. 🧐
7. Security Considerations 🔐
Okay, this part is serious, bestie, so pay attention. 💀 This document describes the security and privacy requirements for the Privacy Pass redemption and issuance protocols. It also describes deployment models built around non-collusion assumptions, plus the privacy considerations for using Privacy Pass inside those models. 🦋 Ensuring Client privacy, which means keeping attestation and redemption contexts separate, takes active work from the Client, especially when malicious Issuers and Origins are around. 😤 So implementing the mitigations discussed in Sections 4 and 6 is necessary if Privacy Pass is going to offer meaningful privacy improvements to end users. No cap, it's non-negotiable. 👑
7.1. Token Caching 💾
Depending on the Origin's token challenge, Clients can request and cache more than one token through an issuance protocol. ✨ Cached tokens help privacy by separating the time of token issuance from the time of token redemption, and they also let Clients cut down on the overhead of getting new tokens through the issuance protocol. Iconic behavior, honestly. 🫶
That means Origins that send token challenges compatible with cached tokens need to take precautions so tokens don't get replayed. 🔁 This is typically done by keeping track of the tokens that were redeemed for as long as cached tokens would be accepted for those particular challenges. 🗂️
Also, since tokens aren't intrinsically bound to Clients, malicious Clients could collude and share tokens in a so-called "hoarding attack". 🐉 As an example, lots of distributed Clients could get cacheable tokens and then hand them to a single Client, who redeems them in a way that violates an Origin's attempt to limit tokens to any one particular Client. Not it. 🙅♀️ In general, the mechanisms for mitigating hoarding attacks depend on the deployment model and use case. For example, in the Joint Origin and Issuer model, comparing the issuance and redemption contexts can help detect hoarding attacks, meaning if the distribution of redemption contexts looks noticeably different from the distribution of issuance contexts. 🔎 Rate-limiting issuance, at the Client, the Attester, or the Issuer, can also help mitigate these attacks. 🚦
8. IANA Considerations 🌸
This document has no IANA actions. Nothing to register here, bestie. 💖
9. References 📚
9.1. Normative References 📌
These are the must-read ones, so here they are, word for word:
[AUTHSCHEME]
Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
HTTP Authentication Scheme", RFC 9577,
DOI 10.17487/RFC9577, June 2024,
<https://www.rfc-editor.org/info/rfc9577>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References 🌈
These are the extra-credit reads. 🧚 Copied exactly, because the details matter:
[CENTRALIZATION]
Nottingham, M., "Centralization, Decentralization, and
Internet Standards", RFC 9518, DOI 10.17487/RFC9518,
December 2023, <https://www.rfc-editor.org/info/rfc9518>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-01,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-01>.
[DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", May 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>.
[HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee,
C-K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S.,
Sung, Y-C., and A. Zhang, "DIT: De-Identified
Authenticated Telemetry at Scale", January 2021,
<https://research.fb.com/privatestats>.
[ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
"Privacy Pass Issuance Protocols", RFC 9578,
DOI 10.17487/RFC9578, June 2024,
<https://www.rfc-editor.org/info/rfc9578>.
[KLOR20] Kreuter, B., Lepoint, T., Orrù, M., Raykova, M., and
Springer International Publishing, "Anonymous Tokens with
Private Metadata Bit", Advances in Cryptology - CRYPTO
2020, pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, 2020,
<https://doi.org/10.1007/978-3-030-56784-2_11>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/info/rfc9458>.
[PrivacyPassCloudflare]
Sullivan, N., "Cloudflare supports Privacy Pass", November
2017, <https://blog.cloudflare.com/cloudflare-supports-
privacy-pass/>.
[RATE-LIMITED]
Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and
C. A. Wood, "Rate-Limited Token Issuance Protocol", Work
in Progress, Internet-Draft, draft-ietf-privacypass-rate-
limit-tokens-06, 1 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-rate-limit-tokens-06>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.Acknowledgements 💜
The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy Pauly, Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez, and other contributors of the Privacy Pass Working Group for many helpful contributions to this document. Huge thank-yous, the whole squad deserves it. 🫶✨
Authors' Addresses 📮
Alex Davidson
NOVA LINCS, Universidade NOVA de Lisboa
Largo da Torre
Caparica
Portugal
Email: alex.davidson92@gmail.com
Jana Iyengar
Fastly
Email: jri@fastly.com
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco, CA 94107
United States of America
Email: caw@heapingbits.net📦 where this page comes from
- ietf: rfc9576 2024-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms