Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9576.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Privacy Pass is an architecture for authorization based on privacy-preserving authentication mechanisms. In other words, relying parties authenticate Clients in a privacy-preserving way, i.e., without learning any unique, per-Client information through the authentication protocol, and then make authorization decisions on the basis of that authentication succeeding or failing. Possible authorization decisions might be to provide Clients with read access to a particular resource or write access to a particular resource.¶

Typical approaches for authorizing Clients, such as through the use of long-term state (cookies), are not privacy friendly, since they allow servers to track Clients across sessions and interactions. Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the Client is an authorized user or has completed some prior challenge, Clients present unlinkable proofs that attest to this information. These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued.¶

At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance. The redemption protocol, described in [AUTHSCHEME], runs between Clients and Origins (servers). It allows Origins to challenge Clients to present tokens for consumption. Origins verify the token to authenticate the Client -- without learning any specific information about the Client -- and then make an authorization decision on the basis of the token verifying successfully or not. Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained token or invokes an issuance protocol, e.g., the protocols described in [ISSUANCE], to acquire a token to present as authorization.¶

This document describes requirements for both redemption and issuance protocols and how they interact. It also provides recommendations on how the architecture should be deployed to ensure the privacy of Clients and the security of all participating entities.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are used throughout this document:¶

Client:

An entity that seeks authorization to an Origin. Using terminology from [RFC9334], Clients implement the Remote ATtestation procedureS (RATS) Attester role.¶

Token:

A cryptographic authentication message used for authorization decisions, produced as output from an issuance mechanism or protocol.¶

Origin:

An entity that consumes tokens presented by Clients and uses them to make authorization decisions.¶

Token challenge:

The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.¶

Token request:

A message used by Clients to request a token from an Issuer, often denoted TokenRequest.¶

Token response:

A message used by Issuers to send tokens to a Client, often denoted TokenResponse.¶

Redemption:

The mechanism by which Clients present tokens to Origins for the purposes of authorization.¶

Issuer:

An entity that issues tokens to Clients for properties attested to by the Attester.¶

Issuance:

The mechanism by which an Issuer produces tokens for Clients.¶

Attester:

An entity that attests to properties of Clients for the purposes of token issuance. Using terminology from [RFC9334], Attesters implement the RATS Verifier role.¶

Attestation procedure:

The procedure by which an Attester determines whether or not a Client has the specific set of properties that are necessary for token issuance.¶

The trust relationships between each of the entities in this list are further elaborated upon in Section 3.3.¶

3. Architecture

The Privacy Pass architecture consists of four logical entities -- Client, Origin, Issuer, and Attester -- that work in concert for token redemption and issuance. This section presents an overview of Privacy Pass, a high-level description of the threat model and privacy goals of the architecture, and the goals and requirements of the redemption and issuance protocols. Deployment variations for the Origin, Issuer, and Attester in this architecture, including considerations for implementing these entities, are further discussed in Section 4.¶