Privacy Pass (privacypass) Internet Drafts

      
 Privacy Pass Issuance Protocol
 
 draft-ietf-privacypass-protocol-16.txt
 Date: 03/10/2023
 Authors: Sofia Celi, Alex Davidson, Steven Valdez, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 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 issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key.
 The Privacy Pass Architecture
 
 draft-ietf-privacypass-architecture-16.txt
 Date: 25/09/2023
 Authors: Alex Davidson, Jana Iyengar, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 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 that helps ensure the desired security and privacy goals are fulfilled.
 The Privacy Pass HTTP Authentication Scheme
 
 draft-ietf-privacypass-auth-scheme-15.txt
 Date: 23/10/2023
 Authors: Tommy Pauly, Steven Valdez, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme 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.
 Rate-Limited Token Issuance Protocol
 
 draft-ietf-privacypass-rate-limit-tokens-06.txt
 Date: 01/04/2024
 Authors: Scott Hendrickson, Jana Iyengar, Tommy Pauly, Steven Valdez, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients.
 Batched Token Issuance Protocol
 
 draft-ietf-privacypass-batched-tokens-01.txt
 Date: 08/04/2024
 Authors: Raphael Robert, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to isse more than one token at a time.
 Checking Resource Consistency with HTTP Mirrors
 
 draft-ietf-privacypass-consistency-mirror-00.txt
 Date: 30/01/2024
 Authors: Benjamin Beurdouche, Matthew Finkel, Steven Valdez, Christopher Wood, Tommy Pauly
 Working Group: Privacy Pass (privacypass)
 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.
 The PrivateToken HTTP Authentication Scheme Extensions Parameter
 
 draft-ietf-privacypass-auth-scheme-extensions-00.txt
 Date: 01/04/2024
 Authors: Scott Hendrickson, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 This document specifies a new parameter for the "PrivateToken" HTTP authentication scheme. This purpose of this parameter is to carry extensions for Privacy Pass protocols that support public metadata.
 Privacy Pass Issuance Protocols with Public Metadata
 
 draft-ietf-privacypass-public-metadata-issuance-00.txt
 Date: 10/04/2024
 Authors: Scott Hendrickson, Christopher Wood
 Working Group: Privacy Pass (privacypass)
 This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token.

data-group-menu-data-url="/group/groupmenu.json">

Privacy Pass (privacypass)

WG Name Privacy Pass
Acronym privacypass
Area Security Area (sec)
State Active
Charter charter-ietf-privacypass-01 Approved
Status update Show Changed 2020-05-17
Document dependencies
Additional resources GitHub Organization
Issue tracker
Wiki
Zulip steam
Personnel Chairs Benjamin M. Schwartz, Joseph A. Salowey
Area Director Paul Wouters
Mailing list Address privacy-pass@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/privacy-pass
Archive https://mailarchive.ietf.org/arch/browse/privacy-pass/
Chat Room address https://zulip.ietf.org/#narrow/stream/privacypass

Charter for Working Group

The Privacy Pass protocol provides a performant, application-layer
mechanism for token creation and anonymous redemption. Servers (Issuers)
create and later verify tokens that are redeemed by an ecosystem of
clients, such that:

  • An Issuer cannot link a redeemed token to one of N previously created tokens
    using the same key with probability non-negligibly larger than 1/N.
  • Clients can verify that a token created by an Issuer corresponds to a
    committed keypair.
  • Tokens are unforgeable.
  • The token issuance and redemption mechanisms are efficient.

The primary purpose of the Privacy Pass Working Group is to develop and
standardize a protocol that meets these requirements, influenced by
applications that have arisen from the wider community. The aims of the
Working Group can be split into three distinct goals:

First, specify an extensible protocol for creating and redeeming
anonymous and transferrable tokens. The protocol should permit suitable
cryptographic ciphersuites and security parameterization for
cryptographic agility. The cryptographic profile used by the protocol
participants will be determined by the specific instantiation of the
protocol, and it will be fixed for the duration of an Issuer's committed
keypair. We will work closely with
the CFRG in determining acceptable cryptographic ciphersuites and parameters
that satisfy the security and privacy properties of the protocol. The
Working Group will specify a preliminary set of extensions, including
Issuer-supplied metadata and cryptographic instantiations
that additionally support public verifiability of Issued tokens, and may
consider any
additional extensions that arise in the future. Security and privacy
properties of the protocol shall be well-documented. Formal analysis of
the protocol will ensure that the security and privacy properties of the
protocol are well-understood and well-documented.

Second, describe and develop protocol use cases and properties thereof.
This includes, though is not limited to:

  1. Describing use cases and interfaces that allow the protocol to be
    used for those use cases.
  2. Defining the privacy goals for each Client during protocol execution,
    along with expectations placed on the Issuers and the ecosystem at
    large.
  3. Describing recommended parameterization(s) of variables associated with
    the protocol ecosystem that control the size of the anonymity set
    that the client belongs to.
  4. Describing verification mechanisms for trusting Issuers and their
    corresponding keying material. Such mechanisms should prevent Issuers
    from presenting any key material that could be used to deanonymize
    clients.
  5. Describing the procedure for including small amounts of metadata with
    Issued tokens, as well as the associated impacts on privacy.
  6. Describing the risk and possible ramifications of Issuer
    centralization, and exploring possible mechanisms to mitigate these
    risks.

Third, and finally, specify a HTTP-layer API for the protocol. This
includes a common understanding of how Privacy Pass is integrated with
HTTP requests and responses for web-based applications.

The following milestones (along with the approximate dates of
completion) will be used to judge the progress of the working group:

  • Specification of protocol & surrounding architecture - February 2021.
  • Risk assessment for centralization in Privacy Pass deployments for
    multiple design options - February 2021
  • Specification of application-layer requirements (including HTTP
    integration) - June 2021.
  • Specification of HTTP browser API (in coordination with W3C) - October
    2021.

Note that the specifications developed by this working group will be
informed by the following initial drafts:

These existing drafts may be further developed into the core
deliverables of the working group, supplemented by any additional
extensions. Alternatively, they may contribute indirectly to a future
set of documents that meet the core goals of the working group.