Privacy Pass

Identity Protocol

A privacy-preserving authorization protocol that lets a client prove it has passed some check, such as solving a challenge or being a legitimate user of a device, without being tracked across requests. A server issues tokens that are cryptographically blinded, so that when a token is later redeemed the issuer cannot link it to the issuance. It is now an IETF standards-track family: RFC 9576 describes the architecture, RFC 9577 the HTTP authentication scheme, and RFC 9578 the issuance protocols (published June 2024). The original deployment was a browser extension that let people skip CAPTCHA challenges at sites behind Cloudflare .

Open Standard

Links

Visit Website See this tool in the graph Suggest an edit

Details

License

Open source: the original extension and server code are on the project's GitHub pages; the standards are IETF RFCs. https://github.com/privacypass; https://github.com/ietf-wg-privacypass/base-drafts

Dev Status 🟢 Active

Owner

IETF Privacy Pass Working Group (standards); the RFC authors include people from Cloudflare, Fastly, Apple, Brave Software and NOVA LINCS (Universidade NOVA de Lisboa)

Governing Body

IETF Privacy Pass Working Group (Internet Engineering Task Force)

Governing Body - List

Internet Engineering Task Force

Country

International (IETF working group; authors across several organisations and countries)

Start Year 2017

Stack

Verifiable, oblivious pseudorandom functions (VOPRFs) over elliptic curves in the original protocol; the standardised issuance protocols (RFC 9578) define two token types, VOPRF (P-384, SHA-384) and Blind RSA (2048-bit); HTTP authentication scheme

Funding Not stated by the project.

Last Investigated Oct 29, 2026

Topology view

This tool in the centre and the things it is directly related to. Each line names the kind of relationship.

Open in Graph Explorer

Use Case Domains

Identity & Trust

Affordances

Proof of humanity

Contextual disclosure

Identity Protocol Attributes

Origins

Reduce the burden of internet challenges (CAPTCHAs) for users, especially those on shared or anonymising networks, by letting them redeem blindly signed tokens anonymously; standardised through the IETF to support wider use cases such as device attestation

Database

N/A

Query Language

N/A

Data Formats

Tokens carried in an HTTP Authorization header with its own authentication scheme; token challenge and token structures defined in RFC 9577; issuance request and response structures in RFC 9578

Mobile Support

Via platform implementations that adopted the standard (the cited sources name no specific mobile client beyond the protocol authors' employers)

Web Support

Yes: browser extension and an HTTP authentication scheme

Native Apps

Library and platform-level; the browser extension is the project's own client

Terms

Free and open: IETF RFCs and open-source reference code

Funds

Not stated by the project.

Based On

VOPRFs and blind RSA signatures; the RFCs reference the original Privacy Pass work and related IETF cryptographic standards

Governing Body - List

Internet Engineering Task Force

Permissions

Origins choose which issuers to trust; clients choose which tokens to present

Authentication & Identity

No identity is revealed: a token proves only that the issuer's checks were passed; issuers and attesters decide what that means

Storage Model

Clients store unspent tokens locally; issuers and origins keep spent-token state to prevent reuse

Interoperability

A common HTTP scheme and issuance protocols let any compliant client, attester, issuer and origin interoperate

Data Portability

Tokens are bearer instruments held by the client and redeemable at any origin that accepts that issuer; they are not portable between issuers

Governance & Decision Making

IETF working-group consensus process, with the architecture, authentication scheme and issuance protocols as separate documents

Protocol Maturity / Standardization

IETF standards track: RFC 9577 and RFC 9578 are Standards Track and RFC 9576 is Informational, all published June 2024

Identity Standards

IETF RFCs 9576, 9577 and 9578; not a W3C DID or Verifiable Credentials scheme

DID Methods Supported

N/A

Key Management

The issuer holds a signing key and publishes the public key; clients hold unspent tokens; the architecture discusses key rotation and issuer directories

Credential Types

Anonymous bearer tokens bound to a challenge; not identity credentials

Verification Method

The origin verifies the token against the issuer's public key and rejects reuse

Privacy Features

Unlinkability between issuance and redemption through blinding; the architecture discusses the remaining risks (for example from small anonymity sets and colluding parties)

Authentication Methods

Blind-signed tokens redeemed over an HTTP Authorization header

Revocation Mechanism

Not a revocation model: tokens are single-use and expire by issuer key rotation

Agent Types Supported

Clients (people and devices), attesters, issuers and origins

Wallet/Client Types

Browsers and other HTTP clients; the original extension

Recovery Mechanisms

N/A: tokens are disposable

Compliance / Regulations

Not stated by the project.

Credential Exchange Protocols

HTTP authentication scheme for redemption (RFC 9577) and issuance protocols (RFC 9578)

Trust Framework

Trust in issuers and attesters chosen by the origin; the architecture requires them to be separable to protect privacy

Cost Model

Free to use; costs fall on the issuer and attester

Censorship Resistance

Low to moderate: issuance depends on issuers that a few large operators run today

Relationships

How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.

Hosted at: Internet Engineering Task Force
Standardized at: Internet Engineering Task Force
Stewarded by: Internet Engineering Task Force