Privacy Pass Reverse Flow
draft-meunier-privacypass-reverse-flow-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Thibault Meunier | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-meunier-privacypass-reverse-flow-07
Privacy Pass T. Meunier
Internet-Draft Cloudflare Inc.
Intended status: Informational 4 August 2026
Expires: 5 February 2027
Privacy Pass Reverse Flow
draft-meunier-privacypass-reverse-flow-07
Abstract
This document specifies an instantiation of the Privacy Pass
Architecture (RFC 9576) 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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://thibmeu.github.io/draft-meunier-privacypass-reverse-flow-
informational/draft-meunier-privacypass-reverse-flow.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-meunier-privacypass-reverse-
flow/.
Discussion of this document takes place on the Privacy Pass Working
Group mailing list (mailto:privacy-pass@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/privacy-pass/. Subscribe
at https://www.ietf.org/mailman/listinfo/privacy-pass/.
Source for this draft and an issue tracker can be found at
https://github.com/thibmeu/draft-meunier-privacypass-reverse-flow-
informational.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Meunier Expires 5 February 2027 [Page 1]
Internet-Draft Privacy Pass Reverse Flow August 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 February 2027.
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Refunding tokens . . . . . . . . . . . . . . . . . . . . 4
2.2. Bootstrapping Issuer . . . . . . . . . . . . . . . . . . 4
2.3. Attester feedback loop . . . . . . . . . . . . . . . . . 4
2.4. Anonymous credential composition . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Architecture overview . . . . . . . . . . . . . . . . . . . . 5
4.1. CredentialRequest, CredentialResponse, and
CredentialFinalization . . . . . . . . . . . . . . . . . 7
4.2. Client behaviour . . . . . . . . . . . . . . . . . . . . 7
4.3. State . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Retry and duplicate issuance . . . . . . . . . . . . 8
4.4. Origin Issuer discovery and consistency . . . . . . . . . 9
5. Deployment modes . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Origin/Issuer/Attester deployment . . . . . . . . . . . . 9
5.2. Split Origin-Attester deployment . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Issuer face values . . . . . . . . . . . . . . . . . . . 13
6.2. Token for specific Clients . . . . . . . . . . . . . . . 13
6.3. Swap endpoint and its privacy implication . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Redemption gates issuance . . . . . . . . . . . . . . . . 14
7.2. Issuance amplification . . . . . . . . . . . . . . . . . 14
7.3. Double-spend prevention . . . . . . . . . . . . . . . . . 14
Meunier Expires 5 February 2027 [Page 2]
Internet-Draft Privacy Pass Reverse Flow August 2026
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
This document specifies an instantiation of Privacy Pass Architecture
[RFC9576] 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 [RFC9576]. Each issuance and
redemption step still follows that architecture. The gap is
composition: [RFC9576] 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.
2. Motivation
With Privacy Pass issuance as described in [RFC9576], once a token is
presented by a Client, it is considered spent and cannot be reused.
If a token were to be presented twice, the two requests would be
linkable by the Origin, which breaks unlinkability.
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 did not need a token
presentation, for instance because its cost to the Origin was
insignificant.
This draft gives an Origin a way to hand a requesting Client an
updated state, so that the Client can present new tokens on future
requests. The Origin acts as a new Attester/Issuer entity.
Below, we present different use cases.
Meunier Expires 5 February 2027 [Page 3]
Internet-Draft Privacy Pass Reverse Flow August 2026
2.1. 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 make a second
request. This is the case for a request that needs little compute,
or one that leads to a redirection instead of content generation.
With a reverse flow, a Client that has already been authorised by an
Origin can maintain that authorisation, without losing the
unlinkability property provided by Privacy Pass.
2.2. Bootstrapping Issuer
An Origin wants to grant 30 accesses to Clients that solved a
CAPTCHA. To do so, it consumes a type 0x0002 publicly verifiable
token from an initial Issuer that guarantees a CAPTCHA has been
solved, and uses it to issue 30 type 0x0001 privately verifiable
tokens. Without a reverse flow, the Origin would have to require 30
tokens of type 0x0002, which are more expensive and require more
requests to the Issuer.
2.3. Attester feedback loop
In [RFC9576], 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 authorised 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.
2.4. Anonymous credential composition
Privacy Pass Architecture as defined by [RFC9576] is built around
tokens, whose issuance flows are defined in [RFC9578].
More recent explorations ([PRIVACYPASS-ARC], [PRIVACYPASS-BBS],
[PRIVACYPASS-ACT]) provide Clients with credentials, whose
presentation results in a scoped token. These schemes are
instantiations of a reverse flow, both because the Client holds a
state it can use to perform multiple token presentations, and because
the Origin can provide a requesting Client with an updated state.
Meunier Expires 5 February 2027 [Page 4]
Internet-Draft Privacy Pass Reverse Flow August 2026
In addition, these schemes are more costly and usage specific. With
a reverse flow, the initial Issuer and the Origin Issuer may use
different credentials, each suited to their use case. One use case
is rate limiting and blocking. [PRIVACYPASS-ARC] provides a per-
Origin rate limit with a single credential, while [PRIVACYPASS-ACT]
allows an Origin to rate-limit a specific session once it has been
established.
3. 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.
We reuse terminology from [RFC9576].
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
4. Architecture overview
Along with sending their PrivateToken for authentication (as
specified in [RFC9576]), the Client sends a CredentialRequest.
Meunier Expires 5 February 2027 [Page 5]
Internet-Draft Privacy Pass Reverse Flow August 2026
+---------------+ +--------+ +--------+ +----------+ +--------+
| Origin Issuer | | Origin | | Client | | Attester | | Issuer |
+--+------------+ +---+----+ +---+----+ +----+-----+ +---+----+
| | | | |
| |<---------------- Request ----------------+ | |
| +-------- TokenChallenge (Issuer) -------->| | |
| | | | |
| | |<== Attestation ==>| |
| | +------ CredentialRequest ----->|
| | |<----- CredentialResponse -----+
| | CredentialFinalization | |
| | | | |
| | CredentialPresentation | |
| |<------------ Request+Token --------------+ | |
|<-- CredentialRequest ---+ +CredentialRequest(Origin) | | |
+--- CredentialResponse ->| | | |
| |-- Response+CredentialResponse(Origin) -->| | |
| | CredentialFinalization | |
| | | | |
Figure 1: Architecture of Privacy Pass with a Reverse Flow
The initial flow matches the one defined by [RFC9576]. 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 operates an Origin Issuer through
the Origin Issuer's configuration (Section 4.4).
This is an extension of [RFC9576]. The redemption flow of a Privacy
Pass token is defined in Section 3.6.4 of [RFC9576]. Reverse flow
extends this so that redemption flow is interleaved with the issuance
flow described in Section 3.6.3 of [RFC9576]. 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).
Seen from the Origin Issuer, the redeemed token is what attests the
Client. A reverse flow is the architecture of [RFC9576] with
redemption in the place of attestation. The difference is that the
Origin does not decide on token validity alone. It may also use what
it learned serving the request, such as whether the request consumed
the resource the token vouched for.
Such flow can be performed through various means, such as HTTP
headers ([REVERSE-FLOW-HTTP-HEADER]), MOQ Parameters
([MOQ-PRIVACYPASS]), or even a dedicated endpoint.
Meunier Expires 5 February 2027 [Page 6]
Internet-Draft Privacy Pass Reverse Flow August 2026
4.1. CredentialRequest, CredentialResponse, and CredentialFinalization
In Figure 1, the Client sends a CredentialRequest and receives a
CredentialResponse. These are meant to abstract requests from
different protocols to the Issuer.
As specified in Section 3.5 of [RFC9576],
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 [PRIVACYPASS-ARC] or [PRIVACYPASS-ACT], modifies
TokenRequest (resp. TokenResponse) to use CredentialRequest instead
(resp. CredentialResponse).
Upon receiving a 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 Section 7 of [RFC9578], a
presentation for [PRIVACYPASS-ARC], or even a TokenRefund for
[PRIVACYPASS-ACT].
All three examples ensure that an Origin Issuer provides the Client
with a state update that it needs to finalize, and present.
4.2. 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
[RFC9577], the Client may send a TokenRequest as defined in
[RFC9578], [BATCHED-TOKENS], or [PRIVACYPASS-ARC]. In all these
definitions, CredentialRequest MUST be prepended by a uint16_t
representing the token type.
The same security and privacy guarantees apply as to the initial
issuance flow. The Client is responsible for coordinating between
the different entities. Specifically, if the Reverse Origin is the
Initial Attester/Issuer, the Client SHOULD account for possible
privacy leakage.
4.3. State
An Origin PrivateToken outlives the request it was obtained on, so a
Client has to decide where to keep it and when to drop it. Both
choices rely on the unlinkability goals of Section 3.3 of [RFC9576].
Meunier Expires 5 February 2027 [Page 7]
Internet-Draft Privacy Pass Reverse Flow August 2026
An Origin PrivateToken either replaces the token that was spent, or
carries something the spent token did not. In the first case, the
Origin Issuer uses the same configuration as the Issuer of the spent
token, and the Client MAY store the new token with the ones it
already holds for that Issuer. In the second case, the Origin
PrivateToken differs in issuance protocol, key, or metadata, and the
Client MUST store it separately. A Client drawing from a single pool
cannot tell which Reverse Origin accepts a given token, nor what it
discloses by presenting it.
Origin PrivateTokens are state the Origin caused the Client to keep.
A Client that lets a user clear the state held for an Origin SHOULD
clear the Origin PrivateTokens for that Origin at the same time. A
token that survives such a reset lets the Origin recognise a Client
the user believes has been reset.
4.3.1. Retry and duplicate issuance
A Client that presents a token and receives no response does not know
whether the Origin redeemed it. If it did, the token is spent and
the Client has nothing to show for it. To recover, the Client MAY
record that it sent the token before sending it, and MAY send the
same token and the same CredentialRequest again.
+---------------+ +--------+ +--------+
| Origin Issuer | | Origin | | Client |
+-------+-------+ +---+----+ +---+----+
| | |
| |<--- Request+Token+CredReq ------+
|<---- CredReq ------+ |
+----- CredResp ---->| |
| +--- Response+CredResp ---X |
| | lost |
| | |
| |<--- Request+Token+CredReq ------+
|<---- CredReq ------+ same request |
+----- CredResp ---->| |
| same response +--- Response+CredResp ---------->|
| | |
Figure 2: Retry after a lost response
This works only if the Origin Issuer treats the redeemed token as the
key to the issuance. An Origin Issuer that accepts the second
presentation MUST return the CredentialResponse it returned for the
first, and MUST NOT issue a second credential for the same token. An
Origin Issuer that does not keep this state MUST reject the second
presentation as a double spend (Section 7.1 of [RFC9576]).
Meunier Expires 5 February 2027 [Page 8]
Internet-Draft Privacy Pass Reverse Flow August 2026
A Client MUST NOT send the same token with a different
CredentialRequest. The Origin Issuer cannot tell such a request
apart from a retry, so it either issues twice for one redemption or
returns a response the Client cannot finalise.
Retrying has a cost. The same token reaching the Origin twice tells
it the two requests come from one Client, and re-sending an identical
request does not avoid this (Section 6).
4.4. Origin Issuer discovery and consistency
An Origin Issuer is an Issuer. It advertises its token types and
keys in a directory as defined in Section 4 of [RFC9578], 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. This is the
partitioning described in Section 6.2 of [RFC9576]. A reverse flow
does not detect it. It assumes an Origin Issuer that serves one
configuration to every Client, and the anonymity set of a Client is
at most the set of Clients that were served the same configuration.
Deployments that cannot make that assumption need a mechanism that
shows the configuration is the same for everyone. This is the case
when several independent Client implementations talk to the same
Origin Issuer, since none of them can vouch for what the others were
served. [CONSISTENCY-MIRROR], [KEYTRANS], and [SCITT] are examples
of such a mechanism. Choosing one is out of scope for this document.
5. Deployment modes
Similar to Section 5 of [RFC9576], Privacy Pass with a Reverse Flow
supports multiple deployment modes.
Any deployment needs a transport to carry the CredentialRequest and
CredentialResponse from Section 4 alongside the regular Client-Origin
exchange. Transport and deployment model are independent choices.
Options include MOQ Parameters ([MOQ-PRIVACYPASS]), an HTTP header
([REVERSE-FLOW-HTTP-HEADER]), or a dedicated endpoint. Each is
covered in its own document.
5.1. Origin/Issuer/Attester deployment
In this model, the Origin, Attester, and Issuer are all operated by
the same entity, as shown in Figure 3. The Reverse Flow is the same
as the Initial Flow, except for the request/response encapsulation.
The Origin is the Reverse Origin.
Meunier Expires 5 February 2027 [Page 9]
Internet-Draft Privacy Pass Reverse Flow August 2026
+-------------------------------------.
+--------+ | +----------+ +--------+ +--------+ |
| Client | | | Attester | | Issuer | | Origin | |
+---+----+ | +-----+----+ +----+---+ +---+----+ |
| `-------|-----------|---------|------'
+------------------- Request ------------------->|
|<--------------- TokenChallenge ----------------+
| | | |
|<====== Attestation =====>| | |
+--------- CredentialRequest --------->| |
|<-------- CredentialResponse ---------+ |
CredentialFinalization | | |
| |
CredentialPresentation |
+--- Request+Token+CredentialRequest(Origin) --->|
|<----- Response+CredentialResponse(Origin) -----+
| |
Figure 3: Shared Deployment Model
Similar to the original Shared Deployment Model (Section 4.1 of
[RFC9576]), 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.
5.2. 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.
Meunier Expires 5 February 2027 [Page 10]
Internet-Draft Privacy Pass Reverse Flow August 2026
+--------------------------.
+---------------+ +--------+ +--------+ | +----------+ +--------+ |
| Origin Issuer | | Origin | | Client | | | Attester | | Issuer | |
+---+-----------+ +---+----+ +---+----+ | +-----+----+ +----+---+ |
| | | `-------|-----------|-----'
| +-- TokenChallenge (Issuer) ------------------>| | |
| | | | |
| | |<== Attestation ==>| |
| | +------ CredentialRequest ----->|
| | |<----- CredentialResponse -----+
| | CredentialFinalization | |
| | | | |
| | CredentialPresentation | |
| |<-- Request+Token+CredentialRequest(Origin) --+ | |
|<-- CredentialRequest ---+ | | |
+-- CredentialResponse -->| | | |
| +--- Response+CredentialResponse(Origin) ----->| | |
| | | | |
Figure 4: Joint Attester and Issuer Deployment Model
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, implying they are not split deployments.
A particular deployment model is when the Reverse Origin is the
Attester/Issuer. This model is described in Figure 5
Meunier Expires 5 February 2027 [Page 11]
Internet-Draft Privacy Pass Reverse Flow August 2026
+--------------------------.
+---------------+ +--------+ +--------+ | +----------+ +--------+ |
| Origin Issuer | | Origin | | Client | | | Attester | | Issuer | |
+---+-----------+ +---+----+ +---+----+ | +-----+----+ +----+---+ |
| | | `-------|-----------|-----'
| +-- TokenChallenge (Issuer) ------------------>| | |
| | | | |
| | |<== Attestation ==>| |
| | +------ CredentialRequest ----->|
| | |<----- CredentialResponse -----+
| | CredentialFinalization | |
| | | | |
| | CredentialPresentation | |
| |<-- Request+Token+CredentialRequest(Origin) --+ | |
|<-- CredentialRequest ---+ | | |
+--- CredentialResponse ->| | | |
| +--- Response+CredentialResponse(Origin) ----->| | |
| | CredentialFinalization | |
| | | | |
| | CredentialPresentation | |
| | +------------ Token ----------->|
| | | | |
Figure 5: Joint Attester and Issuer Deployment Model with reverse
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.
6. Privacy Considerations
Privacy Pass [RFC9576] 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.
Meunier Expires 5 February 2027 [Page 12]
Internet-Draft Privacy Pass Reverse Flow August 2026
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.
6.1. Issuer face values
When setting up a reverse flow deployment, an Origin MAY operate
multiple Issuers, and assign 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) Origin Issuers. This bounds the possible
anonymity sets by design.
2. Clients only send 1 PrivateToken per request. This is consistent
with Section 3.2 of [RFC9577] and Section 11.6.2 of [RFC9110]
which only allows one challenge response to be provided as part
of the Authorization HTTP header.
3. Issuer metadata be publicly disclosed via an Origin endpoint, and
externally monitored.
6.2. Token for specific Clients
In Privacy Pass with a reverse flow, an Origin MAY operate multiple
Issuers, with arbitrary metadata associated with them. A malicious
Origin can use this opportunity to associate certain token values
with 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 be provided by an Issuer not controlled
by the Origin.
Meunier Expires 5 February 2027 [Page 13]
Internet-Draft Privacy Pass Reverse Flow August 2026
2. Clients reset their state regularly with the initial Issuer.
6.3. Swap endpoint and its privacy implication
With multiple Issuers, a Client can end up holding tokens for various
Issuers. Origins MAY propose a swap endpoint at which a Client can
exchange one or more Origin tokens for one or more new Origin tokens.
The Origin SHOULD ensure this endpoint receives enough traffic to not
reduce the anonymity sets.
7. Security Considerations
The security considerations of [RFC9576] apply. Each issuance and
redemption step in a reverse flow is a regular Privacy Pass exchange;
this section covers risks introduced by their composition.
7.1. 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.
7.2. Issuance amplification
A reverse flow can issue more value than it redeems (Section 2.2),
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.
7.3. Double-spend prevention
Double-spend prevention follows Section 7.1 of [RFC9576]. When the
Reverse Origin is not the Origin Issuer (Figure 5), the two MUST
share redemption state, or each token MUST be redeemable at exactly
one Reverse Origin.
A Client retrying a lost response presents the same token twice
(Section 4.3). An Origin Issuer either answers such a retry from
stored issuance state, or rejects it. It MUST NOT issue twice for
one redeemed token.
Meunier Expires 5 February 2027 [Page 14]
Internet-Draft Privacy Pass Reverse Flow August 2026
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[BATCHED-TOKENS]
Robert, R., Wood, C. A., and T. Meunier, "Batched Token
Issuance Protocol", Work in Progress, Internet-Draft,
draft-ietf-privacypass-batched-tokens-08, 4 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-batched-tokens-08>.
[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/rfc/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/rfc/rfc8174>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/rfc/rfc9576>.
[RFC9578] 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/rfc/rfc9578>.
9.2. Informative References
[CONSISTENCY-MIRROR]
Beurdouche, B., Finkel, M., Valdez, S., Wood, C. A., and
T. Pauly, "Checking Resource Consistency with HTTP
Mirrors", Work in Progress, Internet-Draft, draft-ietf-
privacypass-consistency-mirror-00, 30 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-consistency-mirror-00>.
[KEYTRANS] McMillion, B., "Key Transparency Architecture", Work in
Progress, Internet-Draft, draft-ietf-keytrans-
architecture-09, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-
keytrans-architecture-09>.
Meunier Expires 5 February 2027 [Page 15]
Internet-Draft Privacy Pass Reverse Flow August 2026
[MOQ-PRIVACYPASS]
Nandakumar, S., Jennings, C. F., and T. Meunier, "Privacy
Pass Authentication for Media over QUIC (MoQ)", Work in
Progress, Internet-Draft, draft-ietf-moq-privacy-pass-
auth-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
privacy-pass-auth-03>.
[PRIVACYPASS-ACT]
Schlesinger, S. and T. Meunier, "Privacy Pass Issuance
Protocol for Anonymous Credit Tokens", Work in Progress,
Internet-Draft, draft-schlesinger-privacypass-act-01, 13
February 2026, <https://datatracker.ietf.org/doc/html/
draft-schlesinger-privacypass-act-01>.
[PRIVACYPASS-ARC]
Yun, C., Wood, C. A., and A. F. Faz-Hernandez, "Privacy
Pass Issuance Protocol for Anonymous Rate-Limited
Credentials", Work in Progress, Internet-Draft, draft-
ietf-privacypass-arc-protocol-01, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-arc-protocol-01>.
[PRIVACYPASS-BBS]
Ladd, W., "BBS for PrivacyPass", Work in Progress,
Internet-Draft, draft-ladd-privacypass-bbs-01, 26 February
2024, <https://datatracker.ietf.org/doc/html/draft-ladd-
privacypass-bbs-01>.
[REVERSE-FLOW-HTTP-HEADER]
Meunier, T., "Privacy Pass Reverse Flow HTTP Transport",
Work in Progress, Internet-Draft, draft-meunier-
privacypass-reverse-flow-http-00, 18 June 2026,
<https://datatracker.ietf.org/doc/html/draft-meunier-
privacypass-reverse-flow-http-00>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9577] 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/rfc/rfc9577>.
Meunier Expires 5 February 2027 [Page 16]
Internet-Draft Privacy Pass Reverse Flow August 2026
[SCITT] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
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
v07
* Add State section: storage of Origin PrivateTokens, clearing, and
retry after a lost response
* State the trust assumption on Origin Issuer configuration, and
make consistency mechanisms an example rather than a requirement
* Fix incorrect section references to [RFC9576] and [RFC9578]
* Editorial pass on the Motivation, Architecture, and Privacy
Considerations sections
* Say that a reverse flow puts redemption in the place of
attestation
v06
* Add Security Considerations: redemption gates issuance, issuance
amplification, double-spend prevention
* Add Origin Issuer discovery and consistency section, following
[RFC9578] directory and referencing consistency mechanisms
v05
* Clarify why Reverse Flow is more than applying [RFC9576] twice
* Add transport requirement text to Deployment Modes
* Add anonymous credential composition motivation
* Update terminology and diagrams to use Credential vocabulary
Meunier Expires 5 February 2027 [Page 17]
Internet-Draft Privacy Pass Reverse Flow August 2026
* 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
Meunier Expires 5 February 2027 [Page 18]
Internet-Draft Privacy Pass Reverse Flow August 2026
* 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
Author's Address
Thibault Meunier
Cloudflare Inc.
Email: ot-ietf@thibault.uk
Meunier Expires 5 February 2027 [Page 19]