| Internet-Draft | Privacy Pass Reverse Flow | August 2026 |
| Meunier | Expires 5 February 2027 | [Page] |
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.¶
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.¶
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/.¶
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 (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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
Issuer -> Attester -> Client -> Origin. This flow produces a PrivateToken that is used by the Origin to kickstart a 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¶
Attester/Issuer part of the Initial Flow¶
Issuer operated by the Origin¶
PrivateToken issued by the Origin¶
An entity that consumes the Origin PrivateToken. It can be the Origin, or the Initial Attester/Issuer¶
Along with sending their PrivateToken for authentication (as specified in [RFC9576]), the Client sends a CredentialRequest.¶
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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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]).¶
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
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¶
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 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.¶
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.¶
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:¶
Origins define their anonymity sets, and deploy no more than
log2(#anonymity_sets) Origin Issuers. This bounds the possible anonymity sets by design.¶
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.¶
Issuer metadata be publicly disclosed via an Origin endpoint, and externally monitored.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶
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¶
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¶