]> Cloudflare Inc.

ot-ietf@thibault.uk

Security Privacy Pass This document specifies an instantiation of Privacy Pass Architecture that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue a state update to the Client in response to a request in which a token is redeemed. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Privacy Pass Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies an instantiation of Privacy Pass Architecture that allows for a reverse flow from the Origin to the Client. In other words, it specifies a way for an Origin to act as an Attester + Issuer. This document does not replace . Each issuance and redemption step still follows that architecture. The gap is composition: does not define how token redemption at an Origin causes that Origin to issue new Client-held state in the same exchange. Reverse Flow defines that composition, including Client coordination, transport binding, and the privacy effects of letting the Origin's redemption decision shape later tokens.

Motivation With Privacy Pass issuance as described in , once a token is presented by a Client, it is considered spent and cannot be reused in order to guarantee unlinkability. If a token was to be presented twice, the two requests would be linkable by the Origin. However, requiring that all tokens are spent only once means that Clients need to request more tokens to perform more requests. This is true even if the initial request didn't need a token presentation, for instance due to a cost being insignificant to the Origin. This draft provides a mechanism for an Origin to provide a requesting Client with an updated state, allowing them to present new tokens on future requests. Origin act as a new Attester/Issuer entity. Below, we present different use cases.

Refunding tokens Certain Origins use Privacy Pass tokens to rate-limit requests they receive over a certain time window because of resource constraints. If a Client sends a request that can be served without utilising that resource, the Origin would like to authorise them to do a second request. This is the case for request requiring compute and the compute is low, or when the request leads to a redirection instead of content generation for instance. With a reverse flow, a Client that has already been authorised by an Origin can maintain that authorization, without losing the unlinkability property provided by Privacy Pass.

Bootstrapping Issuer An Origin wants to grant 30 access for Clients that solved a CAPTCHA. To do so, it consumes a type 0x0002 public verifiable token from an initial Issuer that guarantees a CAPTCHA has been solved, and use it to issue 30 type 0x0001 private tokens. Without a reverse flow, the Origin would have to require 30 0x0002 Issuer tokens, which have lower performance and a higher number of requests going to the Issuer.

Attester feedback loop In , a Client gets a token from an Issuer and redeems it at an Origin. However, if the Client's request is deemed unwanted by the Origin at redemption time, there is no mechanism that prevents the Client from going back to the initial Issuer to get a new token and be authorized again. With a reverse flow, the initial Issuer may require Clients to present an Origin-issued token before providing them with a second token. This allows for a feedback loop between the Origin and the initial Issuer, without breaking Client unlinkability.

Anonymous credential composition Privacy Pass Architecture as defined by centers around tokens, which issuance flows are defined in . More recent explorations (, , ) are providing credentials to clients, which presentation result in a scoped token. These schemes are instantiation of a reverse flow, both because the Client holds a state it can use to perform multiple token presentation, as well as because the Origin can provides an updated state to requesting Client. In additions, these schemes are more costly, and usage specific. With a reverse flow, the initial Issuer and the Origin issuer may use different credentials, which are suited to their use case. One use case is rate limiting and blocking. provides rate-limit per origin with a unique credentials, while allows to rate-limit a specific session once it's been established.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. We reuse terminology from . The following terms are used throughout this document:

Flow:

Direction from PrivateToken issuance to its redemption. The entity starting the flow acts as an Issuer, while the end of the flow acts as an Origin. The Client is always included, as it finalises the CredentialResponse, and coordinate interactions.

Initial Flow:

Issuer -> Attester -> Client -> Origin. This flow produces a PrivateToken that is used by the Origin to kickstart a Reverse Flow.

Reverse Flow:

Issuer <- Attester <- Client <- Origin. This flow allows the Origin to issue a PrivateToken. In the reverse flow, the Origin operates one or more Issuer, and the Client MAY provide these tokens either to the Initial Attester/Issuer, or use them against the Origin

Initial Attester/Issuer:

Attester/Issuer part of the Initial Flow

Origin Issuer:

Issuer operated by the Origin

Origin PrivateToken:

PrivateToken issued by the Origin

Reverse Origin:

An entity that consumes the Origin PrivateToken. It can be the Origin, or the Initial Attester/Issuer

Architecture overview Along with sending their PrivateToken for authentication (as specified in ), Client sends CredentialRequest

Architecture of Privacy Pass with a Reverse Flow | | | | | | | | | | |<== Attestation ==>| | | | +------ CredentialRequest ----->| | | |<----- CredentialResponse -----+ | | CredentialFinalization | | | | | | | | | CredentialPresentation | | | |<------------ Request+Token --------------+ | | |<-- CredentialRequest ---+ +CredentialRequest(Origin) | | | +--- CredentialResponse ->| | | | | |-- Response+CredentialResponse(Origin) -->| | | | | CredentialFinalization | | | | | | | ]]>

The initial flow matches the one defined by . A Client gets challenged when accessing a resource on an Origin. The Client goes to the Attester to get issued a Token. The Client learns that the Origin acts as a Reverse Flow Issuer through the Origin Issuer's configuration (). This is an extension of . The redemption flow of a Privacy Pass token is defined in . Reverse flow extends this so that redemption flow is interleaved with the issuance flow described in . This is denoted in the diagram above by the Client sending Request+Token+CredentialRequest(Origin). The Origin runs the issuance protocol, and returns Response+CredentialResponse(Origin). Such flow can be performed through various means, such as HTTP headers (), MOQ Parameters (), or even a dedicated endpoint.

CredentialRequest, CredentialResponse, and CredentialFinalization In , the Client sends an CredentialRequest and receives an CredentialResponse. These are meant to abstract request from different protocol to the Issuer. As specified in ,

• The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used.

The introduction of Privacy Pass issuance protocol based on Anonymous Credentials, such as or , modifies TokenRequest (resp. TokenResponse) to use CredentialRequest instead (resp. CredentialResponse). Upon receiving an CredentialResponse, the Client has to finalise the Credential so it can be presented to an Origin. This may be a Finalization for type 0x0002 as defined in , a presentation for , or even a TokenRefund for . All three examples ensure that an Origin Issuer provides the Client with a state update that it needs to finalize, and present.

Client behaviour Along with sending a finalised token from the Initial Issuer to the Origin that it sends through an authorization response as defined in , the Client may send a TokenRequest as defined in , , or . In all these definitions, CredentialRequest MUST prepended by a uint16_t representing the token type. The same security and privacy guarantees applies as to the initial issuance flow. The Client is responsible to coordinate between the different entities. Specifically, if the Reverse Origin is the Initial Attester/Issuer, the Client SHOULD account for possible privacy leakage.

Origin Issuer discovery and consistency An Origin Issuer is an Issuer. It advertises its token types and keys in a directory as defined in , and Clients retrieve this configuration as they would for any other Issuer. If an Origin Issuer can vary this configuration freely, it can partition or track Clients, for instance by serving a targeted Client a unique configuration it can later recognise. Deployments SHOULD make configuration material consistent across Clients and resistant to split views, using , , , or another mechanism with similar properties.

Deployment modes Similar to , Privacy Pass with a Reverse Flow supports multiple deployment modes. Any deployment needs a transport to carry the CredentialRequest and CredentialResponse from alongside the regular Client-Origin exchange. Transport and deployment model are independent choices. Options include MOQ Parameters (), an HTTP header (), or a dedicated endpoint — each covered in its own document.

Origin/Issuer/Attester deployment In this model, the Origin, Attester, and Issuer are all operated by the same entity, as shown in . The Reverse Flow is the same as the Initial Flow, except for the request/response encapsulation. The Origin is the Reverse Origin.

Shared Deployment Model | |<--------------- TokenChallenge ----------------+ | | | | |<====== Attestation =====>| | | +--------- CredentialRequest --------->| | |<-------- CredentialResponse ---------+ | CredentialFinalization | | | | | CredentialPresentation | +--- Request+Token+CredentialRequest(Origin) --->| |<----- Response+CredentialResponse(Origin) -----+ | | ]]>

Similar to the original Shared Deployment Model (), the Attester, Issuer, and Origin share the attestation, issuance, and redemption contexts. Even if this context changes between the Initial and Reverse Flow, attestation mechanism that can uniquely identify a Client are not appropriate as they could lead to unlinkability violations.

Split Origin-Attester deployment In this model, the Attester and Issuer are operated by the same entity that is separate from the Origin. The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens. Origin Tokens can then be sent by Client on new requests, as long as the Reverse Origin trusts the Origin to perform attestation and issue Tokens.

Joint Attester and Issuer Deployment Model | | | | | | | | | | |<== Attestation ==>| | | | +------ CredentialRequest ----->| | | |<----- CredentialResponse -----+ | | CredentialFinalization | | | | | | | | | CredentialPresentation | | | |<-- Request+Token+CredentialRequest(Origin) --+ | | |<-- CredentialRequest ---+ | | | +-- CredentialResponse -->| | | | | +--- Response+CredentialResponse(Origin) ----->| | | | | | | | ]]>

The Origin Issuer MUST NOT issue privately verifiable tokens, as this would lead to secret material being shared between the Origin and the Reverse Origin. A particular deployment model is when the Reverse Origin is the Attester/Issuer. This model is described in

Joint Attester and Issuer Deployment Model with reverse | | | | | | | | | | |<== Attestation ==>| | | | +------ CredentialRequest ----->| | | |<----- CredentialResponse -----+ | | CredentialFinalization | | | | | | | | | CredentialPresentation | | | |<-- Request+Token+CredentialRequest(Origin) --+ | | |<-- CredentialRequest ---+ | | | +--- CredentialResponse ->| | | | | +--- Response+CredentialResponse(Origin) ----->| | | | | CredentialFinalization | | | | | | | | | CredentialPresentation | | | | +------------ Token ----------->| | | | | | ]]>

This deployment SHOULD not allow the Reverse Origin such as an Initial Issuer to infer the request made to the Origin, as it would break unlinkability.

Privacy Considerations Privacy Pass states

• In general, limiting the amount of metadata permitted helps limit the extent to which metadata can uniquely identify individual Clients. Failure to bound the number of possible metadata values can therefore lead to a reduction in Client privacy. Most token types do not admit any metadata, so this bound is implicitly enforced.

In Privacy Pass with a reverse flow, Clients are provided with new PrivateTokens depending on their request. They can present these tokens to continue making further requests. While the tokens are still unlinkable, the token_key_id associated to them represent metadata. It leaks some information about the Client. The following subsections discuss the issues that influence the anonymity set, and possible mitigations/safeguards to protect against this underlying problem.

Issuer face values When setting up a reverse flow deployment, an Origin MAY operate multiple Issuers, and assign them some metadata to them. The amount of possible metadata grows as 2^(origin_issuers). We RECOMMEND that:

1. Origins define their anonymity sets, and deploy no more than log2(#anonymity_sets). This bounds the possible anonymity sets by design.
2. Clients to only send 1 PrivateToken per request. This is consistent with and which only allows one challenge response to be provided as part of Authorization HTTP header.
3. Issuers metadata to be publicly disclosed via an Origin endpoint, and externally monitored.

Token for specific Clients In Privacy Pass with a reverse flow, an Origin MAY operate multiple Issuers, with arbitrary metadata associated to them. A malicious Origin MAY uses this opportunity to associate certain token values to a specific set of Clients. Let's consider the following deployment: the Origin operates two Issuers A and B. The Client sends Token_A, and (CredentialRequest_A, CredentialRequest_B). Issuer B is associated to people that like croissant. Issuer A is for the rest of the clients. If a Client requests croissant, or sends Token_B, the Origin provides CredentialResponse_B. If not, it provides CredentialResponse_A. Over time, this means the Origin is able to track people that like croissants. To mitigate this, we RECOMMEND:

1. The initial PrivateToken to be provided by an Issuer not in control of the Origin.
2. Clients to reset their state regularly with the initial Issuer.

Swap endpoint and its privacy implication With multiple Issuers, a Client MAY end up with a bunch of tokens, for various Issuers. Origins MAY propose a swap endpoint at which a Client can exchange one or more Origin tokens against one or more new Origin tokens. The Origin SHOULD ensure this endpoint receives enough traffic to not reduce the anonymity sets.

Security Considerations The security considerations of apply. Each issuance and redemption step in a reverse flow is a regular Privacy Pass exchange; this section covers risks introduced by their composition.

Redemption gates issuance The redeemed token is the attestation for the reverse flow. An Origin MUST verify the presented token before processing the accompanying CredentialRequest, and MUST NOT return a CredentialResponse if verification fails or the Client presents no token.

Issuance amplification A reverse flow can issue more value than it redeems (), and Origin PrivateTokens can themselves start further reverse flows, so issuance compounds. Origins MUST bound the total value issued per redeemed token, and SHOULD limit Origin PrivateToken validity, for instance by rotating Origin Issuer keys, so stockpiled tokens expire.

Double-spend prevention Double-spend prevention follows . When the Reverse Origin is not the Origin Issuer (), the two MUST share redemption state, or each token MUST be redeemable at exactly one Reverse Origin.

IANA Considerations This document has no IANA actions.

References Normative References Phoenix R&D Cloudflare Cloudflare Inc. This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Inria & Mozilla Apple Inc. Google LLC Cloudflare Apple Inc. This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. Cisco Cisco Cloudflare Inc. This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. Google Cloudflare Inc. This document specifies the issuance and redemption protocols for tokens based on the Anonymous Credit Tokens (ACT) protocol. Apple, Inc. Apple, Inc. Cloudflare This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) cryptographic protocol. Akamai Technologies Existing token types in privacy pass conflate attribution with rate limiting. This document describes a token type where the issuer attests to a set of properties of the client, which the client can then selectively prove to the origin. Repeated showings of the same credential are unlinkable, unlike other token types in privacy pass. Cloudflare Inc. This document specifies an instantiation of Privacy Pass Reverse Flow [REVERSE-FLOW] where HTTP is used as a transport mechanism. It describes a novel HTTP header field that Clients and Origins can use to carry reverse flow data. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements.

Acknowledgments The author would like to thank Tommy Pauly, Chris Wood, Raphael Robert, and Armando Faz Hernandez for helpful discussion on Privacy Pass architecture and its considerations.

Changelog v06

• Add Security Considerations: redemption gates issuance, issuance amplification, double-spend prevention
• Add Origin Issuer discovery and consistency section, following directory and referencing consistency mechanisms

v05

• Clarify why Reverse Flow is more than applying twice
• Add transport requirement text to Deployment Modes
• Add anonymous credential composition motivation
• Update terminology and diagrams to use Credential vocabulary
• Use "Origin Issuer" consistently for the entity providing Client state updates

v04

• Fix: Client finalises a Credential, not a Token, upon receiving a CredentialResponse
• Use "Origin Issuer" consistently when referring to the entity that provides the Client with a state update

v03

• Add "Anonymous credential composition" motivation use case
• Rename section and update diagrams to use Credential vocabulary: CredentialRequest, CredentialResponse, CredentialFinalization, CredentialPresentation (previously TokenRequest, TokenResponse, Finalisation)
• Update PRIVACYPASS-ARC reference to IETF working group draft (draft-ietf-privacypass-arc-protocol)
• Update PRIVACYPASS-ACT reference to use proper I-D reference (draft-schlesinger-privacypass-act)
• Add normative reference to RFC9577
• Editorial pass and spelling fixes

v02

• Diagrams now use Credential instead of Token, and use both Finalization and Presentation as keyword
• Rework the intro to make it consistent with Anonymous credentials evolutions
• Have Anonymous credentials use case, given it needs a new architecture
• Editorial pass on PrivacyPass-Reverse header

v01

• Editorial pass on the introduction
• Add a motivation section: refunding tokens, bootstraping issuer, attester feedback loop
• Split protocol overview via HTTP headers in its own section
• Add consideration about anonymous credentials in joint origin/issuer deployment

v00

• Initial draft
• Possibility of a new HTTP request for inlining request
• Privacy considerations about additional metadata