Draft: draft-ietf-privacypass-architecture

Commentary: This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients , Mediators , Issuers , and  . First draft , so there may be things we want to rephrase or reflow . Rendered view of this PR . 
 Whitespace errors ? 
 fixed ! 
 Merging this per the discussion during the interim meeting today . 
 A few comments ; thanks for the quick turnaround !
The Privacy Pass protocol provides an anonymity-preserving mechanism
for authorization of clients with servers.  The protocol is detailed
in I-D.ietf-privacypass-protocol and is intended for use in the
application-layer.
The way that the ecosystem around the protocol is set up can have
significant impacts on the stated privacy and security guarantees of
the protocol.  For instance, the number of servers issuing Privacy
Pass tokens, along with the number of registered clients, determines
the anonymity set of each individual client.  Moreover, this can be
influenced by other factors, such as: the key rotation policy used by
each server; and, the number of supported ciphersuites.  There are
also client behavior patterns that can reduce the effective security
of the server.
In this document, we will provide a structural framework for building
the ecosystem around the Privacy Pass protocol.  The core of the
document also includes policies for the following considerations.
How server key material should be managed and accessed.
Compatible server issuance and redemption running modes and
associated expectations.
How clients should evaluate server trust relationships.
Security and privacy properties of the protocol.
A concrete assessment and parametrization of the privacy budget
associated with different settings of the above policies.
The incorporation of potential extensions into the wider
ecosystem.
Finally, we will discuss existing applications that make use of the
Privacy Pass protocol, and highlight how these may fit with the
proposed framework.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Server: An entity that issues anonymous tokens to clients.  In
symmetric verification cases, the server must also verify tokens.
Also referred to as the server.
Client: An entity that seeks authorization from a server.
We assume that all protocol messages are encoded into raw byte format
before being sent.  We use the TLS presentation language RFC8446 to
describe the structure of the data that is communicated and stored.
The Privacy Pass ecosystem refers to the global framework in which
multiple instances of the Privacy Pass protocol operate.  This refers
to all servers that support the protocol, or any extension of it,
along with all of the clients that may interact with these servers.
The ecosystem itself, and the way it is constructed, is critical for
evaluating the privacy of each individual client.  We assume that a
client's privacy refers to fraction of users that it represents in
the anonymity set that it belongs to.  We discuss this more in
privacy.
In the above diagram, the arrows indicate the open channels between a
client and a server.  An open channel indicates that a client accepts
Privacy Pass tokens from this server.
If no channel exists, this means that the client chooses not to
accept tokens from (or redeem tokens with) that particular server.
We discuss the roles of servers and clients further in ecosystem-
servers and ecosystem-clients, respectively.
Generally, servers in the Privacy Pass ecosystem are entities whose
primary function is to undertake the role of the "server" in I-
D.ietf-privacypass-protocol.  To facilitate this, the server MUST
hold a Privacy Pass protocol keypair at any given time.  The server
public key MUST be made available to all clients in such a way that
key rotations and other updates are publicly visible.  The server MAY
also require additional state for ensuring this.  We provide a wider
discussion in key-mgmt.
Note that, in the core protocol instantiation from I-D.ietf-
privacypass-protocol, the redemption phase is a symmetric protocol.
This means that the server is the same server that ultimately
processes token redemptions from clients.  However, plausible
extensions to the protocol specification may allow public
verification of tokens by entities which do not hold the secret
Privacy Pass keying material.  We highlight possible client and
server configurations in running-modes.
The server must be uniquely identifiable by all clients with a
consistent identifier.
Clients in the Privacy Pass ecosystem are entities whose primary
function is to undertake the role of the "Client" in I-D.ietf-
privacypass-protocol.  Clients are assumed to only store data related
to the tokens that it has been issued by the server.  This storage is
used for constructing redemption requests.
Clients MAY choose not to accept tokens from servers that they do not
trust.  See client-server for a wider discussion.
Privacy properties of this protocol do not take into account other
possibly identifying information available in an implementation, such
as a client's IP address.  Servers which monitor IP addresses may use
this to track client redemption patterns over time.  Clients cannot
check whether servers monitor such identifying information.  Thus,
clients SHOULD minimize or remove identifying information where
possible, e.g., by using anonymity-preserving tools such as Tor to
interact with servers.
The key material and protocol configuration that a server uses to
issue tokens corresponds to a number of different pieces of
information.
The ciphersuite that the server is using.
The public keys that are active for the server.
Privacy Pass is a protocol for authorization based on anonymous-
credential authentication mechanisms.  Typical approaches for
authorizing clients, such as through the use of long-term 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., whether or not the client is an authorized user or
has completed some prior challenge, clients present unlinkable proofs
that attest to this information.
The most basic Privacy Pass protocol provides a set of cross-origin
authorization tokens that protect the client's anonymity during
interactions with a server.  This allows clients to communicate an
attestation of a previously authenticated server action, without
having to reauthenticate manually.  The tokens retain anonymity in
the sense that the act of revealing them cannot be linked back to the
session where they were initially issued.
At a high level, Privacy Pass is composed of two protocols: issuance
and redemption.
The issuance protocol runs between a Client and two network functions
in the Privacy Pass architecture: Attestation and Issuance.  These
two network functions can be implemented by the same protocol
participant, but can also be implemented separately.  The Issuer is
responsible for issuing tokens in response to requests from Clients.
The Attester is responsible for attesting properties about the Client
for which tokens are issued.  The Issuer needs to be trusted by the
server that later redeems the token.  Attestation can be performed by
the Issuer or by an Attester that is trusted by the Issuer.  Clients
might prefer to select different Attesters, separate from the Issuer,
to be able to use preferred authentication methods or improve privacy
by not directly communicating with an Issuer.  Depending on the
attestation, Attesters can store state about a Client, such as the
number of overall tokens issued thus far.  As an example of an
Issuance protocol, in the original Privacy Pass protocol PPSRV,
tokens were only issued to Clients that solved CAPTCHAs.  In this
context, the Attester attested that some client solved a CAPTCHA and
the resulting token produced by the Issuer was proof of this fact.
The redemption protocol runs between Client and Origin (server).  It
allows Origins to challenge Clients to present one or more tokens for
authorization.  Depending on the type of token, e.g., whether or not
it is cross-origin or per-origin, and whether or not it can be
cached, the Client either presents a previously obtained token or
invokes the issuance protocol to acquire one for authorization.
The issuance and redemption protocols operate in concert as shown in
the figure below.
This document describes requirements for both issuance and redemption
protocols.  This document also describes ecosystem considerations
that impact the stated privacy and security guarantees of the
protocol.
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.
Client: An entity that seeks authorization to an Origin.
Origin: An entity that challenges Clients for tokens.
Issuer: An entity that issues tokens to Clients for properties
attested to by the Attester.
Attester: An entity that attests to properties of Client for the
purposes of token issuance.
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert as shown
in introduction for token issuance and redemption.  This section
describes the purpose of token issuance and redemption and the
requirements therein on the relevant participants.
Issuance protocol.  The token identifies the type of issuance
protocol required for producing the token.  Different issuance
protocols have different security properties, e.g., some issuance
protocols may produce tokens that are publicly verifiable, whereas
others may not have this property.
Issuer identity.  Tokens identify which issuers are trusted for a
given issuance protocol.
Interactive or non-interactive.  Tokens can either be interactive
or not.  An interactive token is one which requires a freshly
issued token based on the challenge, whereas a non-interactive
token can be issued proactively and cached for future use.
Per-domain or cross-domain.  Tokens can be constrained to the
Origin for which the challenge originated, or can be used across
Origins.
Depending on the use case, Origins may need to maintain state to
track redeemed tokens.  For example, Origins that accept non-
interactive, cross-origin tokens SHOULD track which tokens have been
redeemed already, since these tokens can be issued and then spent
multiple times in response to any such challenge.  See double-spend
for discussion.
Origins that admit cross-origin tokens bear some risk of allowing
tokens issued for one Origin to be spent in an interaction with
another Origin.  If tokens protected with resources are unique to a
single Origin, then said Origin MUST NOT admit cross-origin tokens
for authorization.
The issuance protocol embodies the core of Privacy Pass.  It takes as
input a challenge from the redemption protocol and produces a token,
as shown in the figure below.
Each issuance protocol may be different, e.g., in the number and
types of participants, underlying cryptographic constructions used
when issuing tokens, and even privacy properties.
Clients initiate the Token issuance protocol using the challenge, a
randomly generated nonce, and public key for the Issuer.  The Token
issuance protocol itself can be any interactive protocol between
Client, Issuer, or other parties that produces a valid authenticator
over the Client's input, subject to the following security
requirements.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce.  The issuance protocol can reveal the Issuer
public key for the purposes of determining which private key to
use in producing the issuance protocol.  A result of this property
is that the redemption flow is unlinkable from the issuance flow.
One-more forgery security.  The issuance protocol MUST NOT allow
malicious Clients to forge tokens without interacting with the
Issuer directly.
Concurrent security.  The issuance protocol MUST be safe to run
concurrently with arbitrarily many Clients.
Each Issuance protocol MUST come with a detailed analysis of the
privacy impacts of the protocol, why these impacts are justified, and
guidelines on changes to the parametrization in parametrization.
The mechanism by which clients obtain the Issuer public key is not
specified.  Clients may be configured with this key or they may
discover it via some other form.  See CONSISTENCY.
Depending on the use case, issuance may require some form of Client
anonymization service similar to an IP-hiding proxy so that Issuers
cannot learn information about Clients.  This can be provided by an
explicit participant in the issuance protocol, or it can be provided
via external means, e.g., through the use of an IP-hiding proxy
service like Tor. In general, Clients SHOULD minimize or remove
identifying information where possible when invoking the issuance
protocol.
Issuers MUST NOT issue tokens for Clients through untrusted
Attesters.  This is important because the Attester's role is to vouch
for trust in privacy-sensitive Client information, such as account
identifiers or IP address information, to the Issuer.  Tokens
produced by an Issuer that admits issuance for any type of
attestation cannot be relied on for any specific property.  See
attester-role for more details.
Capable of solving a CAPTCHA.  Clients that solve CAPTCHA
challenges can attest to this capability for the purposes of being
ruled out as a bot or otherwise automated Client.
Client state.  Clients can be associated with state and the
attester can attest to this state.  Examples of state include the
number of issuance protocol invocations, the client's geographic
region, and whether the client has a valid application-layer
account.
Trusted device.  Some Clients run on trusted hardware that are
capable of producing device-level attestation statements.
Each of these attestation types have different security properties.
For example, attesting to having a valid account is different from
attesting to be running on trusted hardware.  In general, Attesters
should accept a limited form of attestation formats.
Each attestation format also has an impact on the overall system
privacy.  For example, the number of users in possession of a single
class of trusted device might be lesser than the number of users that
can solve CAPTCHAs.  Similarly, requiring a conjunction of
attestation types could decrease the overall anonymity set size.  For
example, the number of Clients that have solved a CAPTCHA in the past
day, have a valid account, and are running on a trusted device is
lesser than the number of Clients that have solved a CAPTCHA in the
past day.  Attesters should not admit attestation types that result
in small anonymity sets.
Issuers MUST be uniquely identifiable by all Clients with a
consistent identifier.  In a web context, this identifier might be
the Issuer host name.  As discussed later in privacy, ecosystems that
admit a large number of Issuers can lead to privacy concerns for the
Clients in the ecosystem.  Therefore, in practice, the number of
Issuers should be bounded.  The actual Issuers can be replaced with
different Issuers as long as the total never exceeds these bounds.
Moreover, Issuer replacements also have an effect on client anonymity
that is similar to when a key rotation occurs.  See privacy for more
details about maintaining privacy with multiple Issuers.
To facilitate issuance, the Issuer MUST hold an Issuance key pair at
any given time.  The Issuer public key MUST be made available to all
Clients in such a way that key rotations and other updates are
publicly visible.  The key material and protocol configuration that
an Issuer uses to produce tokens corresponds to a number of different
pieces of information.
The public keys that are active for the Issuer.
Clients embed server keys into software.
Specific mechanisms for key management and discovery are out of scope
for this document.
Token issuance associates all issued tokens with a particular choice
of key.  If a server issues tokens with many keys, then this may harm
the anonymity of the Client.  For example, they would be able to map
the Client's access patterns by inspecting which key each token they
possess has been issued under.
To prevent against this, servers MUST only use one private key for
issuing tokens at any given time.  Servers MAY use one or more keys
for redemption to allow servers for seamless key rotation.
Servers may rotate keys as a means of revoking tokens issued under
old or otherwise expired keys.  Alternatively, servers may include
expiration information as metadata alongside the token; See metadata
for more discussion about metadata constraints.  Both techinques are
equivalent since they cryptographically bind expiration to individual
tokens.
Clients embed Issuer keys into software.
As above, specific mechanisms for key management and discovery are
out of scope for this document.
Token issuance associates all issued tokens with a particular choice
of key.  If an Issuer issues tokens with many keys, then this may
harm the anonymity of the Client.  For example, they would be able to
map the Client's access patterns by inspecting which key each token
they possess has been issued under.
To prevent against this, Issuers MUST only use one private key for
issuing tokens at any given time.  Servers MAY use one or more keys
for redemption to allow Issuers for seamless key rotation.
Servers may rotate keys as a means of revoking tokens issued under
old or otherwise expired keys.  Alternatively, Issuers may include
expiration information as metadata alongside the token; See metadata
for more discussion about metadata constraints.  Both techniques are
equivalent since they cryptographically bind expiration to individual
tokens.
Since a server is only permitted to have a single active issuing key,
this implies that only a single ciphersuite is allowed per issuance
period.  If a server wishes to change their ciphersuite, they MUST do
so during a key rotation.
We provide an overview of some of the possible frameworks for
configuring the way that servers run in the Privacy Pass ecosystem.
In short, servers may be configured to provide symmetric issuance and
redemption with clients.  While some servers may be configured as
proxies that accept Privacy Pass data and send it to another server
that actually processes issuance or redemption data.  Finally, we
also consider instances of the protocol that may permit public
verification.
The intention with providing each of these running modes is to cover
the different applications that utilize variants of the Privacy Pass
protocol.  We RECOMMEND that any Privacy Pass server implementation
adheres to one of these frameworks.
The simplest way of considering the Privacy Pass protocol is in a
setting where the same server plays the role of server and verifier,
we call this "Single-Verifier" (SV).
Let S be the server, and C be the client.  When S wants to issue
tokens to C, they invoke the issuance protocol where C generates
their own inputs, and S uses their secret key skS.  In this setting,
C can only perform token redemption with S.  When a token redemption
is required, C and S invoke the redemption phase of the protocol,
where C uses an issued token from a previous exchange, and S uses skS
to validate the redemption.
In this setting, each client C obtains issued tokens from a derver S
via the issuance phase of the protocol.  The difference is that C can
prove that they hold a valid authorization with any verifier V.  We
still only consider S to hold their own secret key.  We name this
mode "Delegated-Verifier" (DV).
When C interacts with V, V can ask C to provide proof of
authorization to the separate server S.  The first stage of the
redemption phase of the protocol is invoked between C and V, which
sees C send an unused redemption token to V.  This message is then
used in a redemption exchange between V and S, where V plays the role
of the Client.  Then S sends the result of the redemption
verification to V, and V uses this result to determine whether C has
a valid token.
This setting is inspired by recently proposed APIs such as
TrustTokenAPI.  It is similar to the DV configuration, except that
the verifiers V no longer interact with the server S.  Only C
interacts with S, and this is done asynchronously to the
authorization request from V.  Hence "Asynchronous-Verifier" (AV).
The "signature" field carries a signature evaluated over the contents
of "result" using a long-term signing key for the server S, of which
the corresponding public key is well-known to C and V.  This would
need to be published alongside other public key data for S.  Then C
can prove that they hold a valid authorization from S to V by sending
the SRR to V.  The SRR can be verified by V by verifying the
signature, using the well-known public key for S.
Such records can be cached to display again in the future.  The
server can also add an expiry date to the record to determine when
the client must refresh the record.
We consider the case where client redemptions can be verified
publicly using the server public key.  This allows for defining
extensions of Privacy Pass that use public-key cryptography to allow
public verification.
In this case, the client C obtains a redemption token from S.  The
redemption token is publicly verifiable in the sense that any entity
that knows the public key for S can verify the token.  This running
mode is known as "Public-Verifier" (PV).
Each of the configurations above can be generalized to settings where
a bounded number of servers are allowed, and verifiers can invoke
authorization verification for any of the available servers.
As we will discuss later in privacy, configuring a large number of
servers can lead to privacy concerns for the clients in the
ecosystem.  Therefore, we are careful to ensure that the number of
servers is kept strictly bounded.  The actual servers can be replaced
with different servers as long as the total never exceeds this bound.
Moreover, server replacements also have an effect on client anonymity
that is similar to when a key rotation occurs.
See privacy for more details about maintaining privacy with multiple
servers.
Certain instantiations of Privacy Pass may permit public or private
metadata to be cryptographically bound to a token.  As an example,
one trivial way to include public metadata is to assign a unique
issuer public key for each value of metadata, such that N keys yields
log2(N) bits of metadata.  The total amount of metadata bits included
in a token is the sum of public and private metadata bits.  See
parametrization for discussion about metadata limits.
Public metadata is that which clients can observe as part of the
token issuance flow.  Public metadata can either be transparent or
opaque.  For example, transparent public metadata is a value that the
client either generates itself, or the server provides during the
issuance flow and the client can check for correctness.  Opaque
public metadata is metadata the client can see but cannot check for
correctness.  As an example, the opaque public metadata might be a
"fraud detection signal", computed on behalf of the server, during
token issuance.  In normal circumstances, clients cannot determine if
this value is correct or otherwise a tracking vector.
Private metadata is that which clients cannot observe as part of the
token issuance flow.  In I-D.ietf-privacypass-protocol, it is
possible to include private metadata to redemption tokens.  The core
protocol instantiation that is described does not include additional
metadata.  However, future instantiations may use this functionality
to provide redemption verifiers with additional information about the
user.  Such instantiations may be built on the Private Metadata Bit
construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF
from Huang et al.  HIJK21.
Note that any metadata bits of information can be used to further
segment the size of the user's anonymity set.  Any server that wanted
to track a single user could add a single metadata bit to user
tokens.  For the tracked user it would set the bit to "1", and "0"
otherwise.  Adding additional bits provides an exponential increase
in tracking granularity similarly to introducing more servers (though
with more potential targeting).
For this reason, the amount of metadata used by an server in creating
redemption tokens must be taken into account - together with the bits
of information that server's may learn about clients otherwise.
Since this metadata may be useful for practical deployments of
Privacy Pass, servers must balance this against the reduction in
client privacy.  In general, servers should permit no more than 32
bits of metadata, as this can uniquely identify each possible user.
We discuss this more in parametrization.
It is important, based on the architecture above, that any client can
determine whether it would like to interact with a given server in
the ecosystem.  Note that this decision must be taken before a client
issues a valid redemption to the server, since redemptions reveal the
anonymity set that the client belongs to.
This judgement can be based on a multitude of factors, associated
with the way that a server presents itself in the ecosystem.  A non-
exhaustive list of server characteristics that a client MAY want to
check are the following.
Which key registry a server posts their key updates to.
How frequent key updates are issued, and which ciphersuite they
use.
The reason given to initiate the redemption.
To aid client trust decisions, a server can publish a "Privacy Pass
policy" that documents the procedures that the server uses to ensure
that client privacy is respected.  If a server does not publish such
a document then the client may choose to use its own judgement, or to
reject the server altogether.
It should be noted that the client trust decision can be made apriori
by specifying an allow-list of all servers that it accepts tokens
from.  This means that these checks do not have to be performed
online.
In the Privacy Pass protocol I-D.ietf-privacypass-protocol,
redemption tokens intentionally encode very little information beyond
which key was used to sign them.  The protocol intentionally uses
components that provide cryptographic guarantees of this fact.
However, even with these guarantees, the way that the ecosystem is
constructed can be used to identify clients based on this limited
information.
The goal of the Privacy Pass ecosystem is to construct an environment
that can easily measure (and maximize) the relative anonymity of any
client that is part of it.  An inherent feature of being part of this
ecosystem is that any client can only remain private relative to the
entire space of users using the protocol.  Moreover, by owning tokens
for a given set of keys, the client's anonymity set shrinks to the
total number of clients controlling tokens for the same keys.
In the following, we consider the possible ways that servers and
servers can leverage their position to try and reduce the anonymity
sets that clients belong to (or, user segregation).  For each case,
we provide mitigations that the Privacy Pass ecosystem must implement
to prevent these actions.
Techniques to introduce client "segregation" can be used to reduce
client anonymity.  Such techniques are closely linked to the type of
key schedule that is used by the server.  When a server rotates their
key, any client that invokes the issuance protocol in this key cycle
will be part of a group of possible clients owning valid tokens for
this key.  To mechanize this attack strategy, a server could
introduce a key rotation policy that forces clients into small key
cycles.  Thus, reducing the size of the anonymity set for these
clients.
We RECOMMEND that servers should only invoke key rotation for fairly
large periods of time such as between 1 and 12 weeks.  Key rotations
represent a trade-off between client privacy and continued server
security.  Therefore, it is still important that key rotations occur
on a fairly regular cycle to reduce the harmfulness of a server key
compromise.
With an active user-base, a week gives a fairly large window for
clients to participate in the Privacy Pass protocol and thus enjoy
the anonymity guarantees of being part of a larger group.  The low
ceiling of 12 weeks prevents a key compromise from being too
destructive.  If a server realizes that a key compromise has occurred
then the server should sample a new key, and upload the public key to
the key registry; invoking any revocation procedures that may apply
for the old key.
Similarly to the server rotation dynamic that is raised above, if
there are a large number of servers then segregation can occur.  In
the FV, AV and PV running modes (running-modes), a verifier OV can
trigger redemptions for any of the available servers.  Each
redemption token that a client holds essentially corresponds to a bit
of information about the client that OV can learn.  Therefore, there
is an exponential loss in anonymity relative to the number of servers
that there are.
For example, if there are 32 servers, then OV learns 32 bits of
information about the client.  If the distribution of server trust is
anything close to a uniform distribution, then this is likely to
uniquely identify any client amongst all other Internet users.
Assuming a uniform distribution is clearly the worst-case scenario,
and unlikely to be accurate, but it provides a stark warning against
allowing too many servers at any one time.
In cases where clients can hold tokens for all servers at any given
time, a strict bound SHOULD be applied to the active number of
servers in the ecosystem.  We propose that allowing no more than 4
servers at any one time is highly preferable (leading to a maximum of
64 possible user segregations).  However, as highlighted in
parametrization, having a very large user base (> 5 million users),
could potentially allow for larger values. server replacements should
only occur with the same frequency as config rotations as they can
lead to similar losses in anonymity if clients still hold redemption
tokens for previously active servers.
In addition, we RECOMMEND that trusted registries indicate at all
times which servers are deemed to be active.  If a client is asked to
invoke any Privacy Pass exchange for an server that is not declared
active, then the client SHOULD refuse to retrieve the server
configuration during the protocol.
The bounds on the numbers of servers that we proposed above are very
restrictive.  This is due to the fact that we considered a situation
where a client could be issued (and forced to redeem) tokens for any
issuing key.
An alternative system is to ensure a robust strategy for ensuring
that clients only possess redemption tokens for a similarly small
number of servers at any one time.  This prevents a malicious
verifier from being able to invoke redemptions for many servers since
the client would only be holding redemption tokens for a small set of
servers.  When a client is issued tokens from a new server and
already has tokens from the maximum number of servers, it simply
deletes the oldest set of redemption tokens in storage and then
stores the newly acquired tokens.
For example, if clients ensure that they only hold redemption tokens
for 4 servers, then this increases the potential size of the
anonymity sets that the client belongs to.  However, this doesn't
protect clients completely as it would if only 4 servers were
permitted across the whole system.  For example, these 4 servers
could be different for each client.  Therefore, the selection of
servers they possess tokens for is still revealing.  Understanding
this trade-off is important in deciding the effective anonymity of
each client in the system.
Another option to allow a large number of servers in the ecosystem,
while preventing the joining of a number of different tokens is for
the client to maintain sharded "redemption contexts".  This would
allow the client to redeem the tokens it wishes to use in a
particular context, while still allowing the client to maintain a
large variety of tokens from many servers.  Within a redemption
context, the client limits the number of different servers used to a
small number to maintain the privacy properties the client requires.
As long as each redemption context maintains a strong privacy
boundary with each other, the verifier will only be able to learn a
number of bits of information up to the limits within that
"redemption context".
If there are multiple key registries, or if a key registry colludes
with an server, then it is possible to provide a split-view of an
server's key material to different clients.  This would involve
posting different key material in different locations, or actively
modifying the key material at a given location.
Key registries should operate independently of server's in the
ecosystem, and within the guidelines stated in key-mgmt.  Any client
should follow the recommendations in client-server for determining
whether an server and its key material should be trusted.
Privacy losses may be encountered if too many redemptions are allowed
in a short burst.  For instance, in the Internet setting, this may
allow delegated or asynchronous verifiers to learn more information
from the metadata that the client may hold (such as first-party
cookies for other domains).  Mitigations for this issue are similar
to those proposed in servers for tackling the problem of having large
number of servers.
In AV, cached SRRs and their associated server public keys have a
similar tracking potential to first party cookies in the browser
setting.  These considerations will be covered in a separate
document, detailing Privacy Pass protocol integration into the wider
web architecture I-D.ietf-privacypass-http-api.
Clients may see an incentive in accepting all tokens that are issued
by a server, even if the tokens fail later verification checks.  This
is because tokens effectively represent a form of currency that they
can later redeem for some sort of benefit.  The verification checks
that are put in place are there to ensure that the client does not
sacrifice their anonymity.  However, a client may judge the
"monetary" benefit of owning tokens to be greater than their own
privacy.
All issuing server should implement a robust storage-query mechanism
for checking that tokens sent by clients have not been spent before.
Such tokens only need to be checked for each server individually.
But all servers must perform global double-spend checks to avoid
clients from exploiting the possibility of spending tokens more than
once against distributed token checking systems.  For the same
reason, the global data storage must have quick update times.  While
an update is occurring it may be possible for a malicious client to
spend a token more than once.
When a client holds tokens for an server, it is possible for any
verifier to invoke that client to redeem tokens for that server.
This can lead to an attack where a malicious verifier can force a
client to spend all of their tokens for a given server.  To prevent
this from happening, methods should be put into place to prevent many
tokens from being redeemed at once.
For example, it may be possible to cache a redemption for the entity
that is invoking a token redemption.  If the verifier requests more
tokens then the client simply returns the cached token that it
returned previously.  This could also be handled by simply not
redeeming any tokens for verification if a redemption had already
occurred in a given time window.
In AV, the client instead caches the SRR that it received in the
asynchronous redemption exchange with the server.  If the same
verifier attempts another redemption request, then the client simply
returns the cached SRR.  The SRRs can be revoked by the server, if
need be, by providing an expiry date or by signaling that records
from a particular window need to be refreshed.
We provide a summary of the parameters that we use in the Privacy
Pass protocol ecosystem.  These parameters are informed by both
privacy and security considerations that are highlighted in privacy
and security, respectively.  These parameters are intended as a
single reference point for those implementing the protocol.
Firstly, let U be the total number of users, I be the total number of
servers.  We let M be the total number of metadata bits that are
allowed to be added by any given server.  Assuming that each user
accept tokens from a uniform sampling of all the possible servers, as
a worst-case analysis, this segregates users into a total of 2^I
buckets.  As such, we see an exponential reduction in the size of the
anonymity set for any given user.  This allows us to specify the
privacy constraints of the protocol below, relative to the setting of
A.
Certain instantiations of the issuance protocol may permit public or
private metadata to be cryptographically bound to a token.  As an
example, one trivial way to include public metadata is to assign a
unique issuer public key for each value of metadata, such that N keys
yields log2(N) bits of metadata.  The total amount of metadata bits
included in a token is the sum of public and private metadata bits.
See parametrization for discussion about metadata limits.
Public metadata is that which clients can observe as part of the
token issuance flow.  Public metadata can either be transparent or
opaque.  For example, transparent public metadata is a value that the
client either generates itself, or the Issuer provides during the
issuance flow and the client can check for correctness.  Opaque
public metadata is metadata the client can see but cannot check for
correctness.  As an example, the opaque public metadata might be a
"fraud detection signal", computed on behalf of the Issuer, during
token issuance.  In normal circumstances, clients cannot determine if
this value is correct or otherwise a tracking vector.
Private metadata is that which clients cannot observe as part of the
token issuance flow.  Such instantiations may be built on the Private
Metadata Bit construction from Kreuter et al.  KLOR20 or the
attribute-based VOPRF from Huang et al.  HIJK21.
The Privacy Pass protocol and ecosystem are both intended to be
receptive to extensions that expand the current set of
functionalities through new issuance protocols.  Each issuance
protocol SHOULD come with a detailed analysis of the privacy impacts
of the extension, why these impacts are justified, and guidelines on
changes to the parametrization in parametrization.  Any extension to
the Privacy Pass protocol MUST adhere to the guidelines specified in
issuer-role for managing Issuer public key data.
The goal of the Privacy Pass ecosystem is to construct an environment
that can easily measure and maximize the relative anonymity of any
Client that is part of it.  An inherent feature of being part of this
ecosystem is that any Client can only remain private relative to the
entire space of users using the protocol.  Moreover, by owning tokens
for a given set of keys, the Client's anonymity set shrinks to the
total number of clients controlling tokens for the same keys.
In the following, we consider the possible ways that Issuers can
leverage their position to try and reduce the anonymity sets that
Clients belong to (or, user segregation).  For each case, we provide
mitigations that the Privacy Pass ecosystem must implement to prevent
these actions.
Any metadata bits of information can be used to further segment the
size of the Client's anonymity set.  Any Issuer that wanted to track
a single Client could add a single metadata bit to Client tokens.
For the tracked Client it would set the bit to "1", and "0"
otherwise.  Adding additional bits provides an exponential increase
in tracking granularity similarly to introducing more Issuers (though
with more potential targeting).
For this reason, the amount of metadata used by an Issuer in creating
redemption tokens must be taken into account - together with the bits
of information that Issuer's may learn about Clients otherwise.
Since this metadata may be useful for practical deployments of
Privacy Pass, Issuers must balance this against the reduction in
Client privacy.  In general, Issuers should permit no more than 32
bits of metadata, as this can uniquely identify each possible user.
We discuss this more in parametrization.
Techniques to introduce Client "segregation" can be used to reduce
Client anonymity.  Such techniques are closely linked to the type of
key schedule that is used by the Issuer.  When an Issuer rotates
their key, any Client that invokes the issuance protocol in this key
cycle will be part of a group of possible clients owning valid tokens
for this key.  To mechanize this attack strategy, an Issuer could
introduce a key rotation policy that forces Clients into small key
cycles.  Thus, reducing the size of the anonymity set for these
Clients.
Issuers SHOULD invoke key rotation for a period of time between 1 and
12 weeks.  Key rotations represent a trade-off between Client privacy
and continued Issuer security.  Therefore, it is still important that
key rotations occur on a regular cycle to reduce the harmfulness of
an Issuer key compromise.
With a large number of Clients, a minimum of one week gives a large
enough window for Clients to participate in the issuance protocol and
thus enjoy the anonymity guarantees of being part of a larger group.
A maximum of 12 weeks limits the damage caused by a key compromise.
If an Issuer realizes that a key compromise has occurred then the
Issuer should generate a new key and make it available to Clients.
If possible, it should invoke any revocation procedures that may
apply for the old key.
Similarly to the Issuer rotation dynamic that is raised above, if
there are a large number of Issuers and Origins accept all of them
segregation can occur.  For example, if Clients obtain tokens from
many Issuers, and Origins later challenge a Client for a token from
each Issuer, Origins can learn information about the Client.  Each
per-Issuer token that a Client holds essentially corresponds to a bit
of information about the Client that Origin learn.  Therefore, there
is an exponential loss in anonymity relative to the number of Issuers
that there are.
For example, if there are 32 Issuers, then Origins learns 32 bits of
information about the Client.  If the distribution of Issuer trust is
anything close to a uniform distribution, then this is likely to
uniquely identify any Client amongst all other Internet users.
Assuming a uniform distribution is clearly the worst-case scenario,
and unlikely to be accurate, but it provides a stark warning against
allowing too many Issuers at any one time.
In cases where clients can hold tokens for all Issuers at any given
time, a strict bound SHOULD be applied to the active number of
Issuers in the ecosystem.  We propose that allowing no more than 4
Issuers at any one time is highly preferable (leading to a maximum of
64 possible user segregations).  However, as highlighted in
parametrization, having a very large user base (> 5 million users),
could potentially allow for larger values.  Issuer replacements
should only occur with the same frequency as config rotations as they
can lead to similar losses in anonymity if clients still hold
redemption tokens for previously active Issuers.
In addition, we RECOMMEND that trusted registries indicate at all
times which Issuers are deemed to be active.  If a Client is asked to
invoke any Privacy Pass exchange for an Issuer that is not declared
active, then the client SHOULD refuse to retrieve the Issuer public
key during the protocol.
The bounds on the numbers of Issuers that this document proposes
above are very restrictive.  This is due to the fact that this
document considers a situation where a Client could be issued (and
forced to redeem) tokens for any Issuer.
An alternative system is to ensure a robust strategy for ensuring
that Clients only possess redemption tokens for a similarly small
number of Issuers at any one time.  This prevents a malicious
verifier from being able to invoke redemptions for many Issuers since
the Client would only be holding redemption tokens for a small set of
Issuers.  When a Client is issued tokens from a new Issuer and
already has tokens from the maximum number of Issuers, it simply
deletes the oldest set of redemption tokens in storage and then
stores the newly acquired tokens.
Another option to allow a large number of Issuers in the ecosystem,
while preventing the joining of a number of different tokens is for
the Client to maintain sharded "redemption contexts".  This would
allow the Client to redeem the tokens it wishes to use in a
particular context, while still allowing the Client to maintain a
large variety of tokens from many Issuers.  Within a redemption
context, the Client limits the number of different Issuers used to a
small number to maintain the privacy properties the Client requires.
As long as each redemption context maintains a strong privacy
boundary with each other, the verifier will only be able to learn a
number of bits of information up to the limits within that
"redemption context".
Key registries should operate independently of Issuers in the
ecosystem, and within the guidelines stated in issuer-role.  Any
Client should follow the recommendations in privacy for determining
whether an Issuer and its key material should be trusted.
Privacy losses may be encountered if too many redemptions are allowed
in a short burst.  For instance, in the Internet setting, this may
allow Origins to learn more information from the metadata that the
Client may hold (such as first-party cookies for other origins).
Mitigations for this issue are similar to those proposed in servers
for tackling the problem of having large number of Issuers.
Clients may see an incentive in accepting all tokens that are issued
by an Issuer, even if the tokens fail later verification checks.
This is because tokens effectively represent a form of currency that
they can later redeem for some sort of benefit.  The verification
checks that are put in place are there to ensure that the Client does
not sacrifice their anonymity.  However, a Client may judge the
"monetary" benefit of owning tokens to be greater than their own
privacy.
When applicable for non-interactive tokens, all Origins SHOULD
implement a robust storage-query mechanism for checking that tokens
sent by clients have not been spent before.  Such tokens only need to
be checked for each Origin individually.  But all Origins must
perform global double-spend checks to avoid clients from exploiting
the possibility of spending tokens more than once against distributed
token checking systems.  For the same reason, the global data storage
must have quick update times.  While an update is occurring it may be
possible for a malicious client to spend a token more than once.
When a Client holds tokens for an Issuer, it is possible for any
verifier to invoke that client to redeem tokens for that Issuer.
This can lead to an attack where a malicious verifier can force a
Client to spend all of their tokens from a given Issuer.  To prevent
this from happening, tokens can be scoped to single Origins such that
they can only be redeemed within for a single Origin.
If tokens are cross-Origin, Clients should use alternate methods to
prevent many tokens from being redeemed at once.  For example, if the
Origin requests an excess of tokens, the Client could choose to not
present any tokens for verification if a redemption had already
occurred in a given time window.
This section provides a summary of the parameters that used in the
Privacy Pass protocol ecosystem.  These parameters are informed by
both privacy and security considerations that are highlighted in
privacy and security, respectively.  These parameters are intended as
a single reference point for those implementing the protocol.
Firstly, let U be the total number of Clients (or users), I be the
total number of Issuers.  We let M be the total number of metadata
bits that are allowed to be added by any given Issuer.  Assuming that
each user accept tokens from a uniform sampling of all the possible
Issuers, as a worst-case analysis, this segregates Clients into a
total of 2^I buckets.  As such, we see an exponential reduction in
the size of the anonymity set for any given user.  This allows us to
specify the privacy constraints of the protocol below, relative to
the setting of A.
The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A.
This is derived from the fact that permitting I servers lead to 2^I
segregations of the total user-base U.  Moreover, if we permit M = 1,
then this effectively halves the anonymity set for each server, and
thus we incur a factor of 2I in the exponent.  By reducing I, we
limit the possibility of performing the attacks mentioned in privacy.
We must also account for each user holding issued data for more then
one possible active keys.  While this may also be a vector for
monitoring the access patterns of clients, it is likely to
unavoidable that clients hold valid issuance data for the previous
key epoch.  This also means that the server can continue to verify
redemption data for a previously used key.  This makes the rotation
period much smoother for clients.
The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A.
This is derived from the fact that permitting I Issuers lead to 2^I
segregations of the total user-base U.  Moreover, if we permit M = 1,
then this effectively halves the anonymity set for each Issuer, and
thus we incur a factor of 2I in the exponent.  By reducing I, we
limit the possibility of performing the attacks mentioned in privacy.
We must also account for each user holding issued data for more then
one possible active keys.  While this may also be a vector for
monitoring the access patterns of Clients, it is likely to
unavoidable that Clients hold valid issuance data for the previous
key epoch.  This also means that the Issuer can continue to verify
redemption data for a previously used key.  This makes the rotation
period much smoother for Clients.
If the value of U is much bigger (e.g. 5 million) then this would
permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers.
Using the recommendations in more-servers, it is possible to tolerate
larger number of servers if clients in the ecosystem ensure that they
only store tokens for a small number of them.  In particular, if
clients limit their storage of redemption tokens to the bound implied
by I, then prevents a malicious verifier from triggering redemptions
for all servers in the ecosystem.
The Privacy Pass protocol and ecosystem are both intended to be
receptive to extensions that expand the current set of functionality.
As specified in I-D.ietf-privacypass-protocol, all extensions to the
Privacy Pass protocol SHOULD be specified as separate documents that
modify the content of this document in some way.  We provide guidance
on the type of modifications that are possible in the following.
Any such extension should also come with a detailed analysis of the
privacy impacts of the extension, why these impacts are justified,
and guidelines on changes to the parametrization in parametrization.
Similarly, extensions MAY also add new server running modes, if
applicable, to those that are documented in running-modes.
Any extension to the Privacy Pass protocol must adhere to the
guidelines specified in key-mgmt for managing server public key data.
The following is a non-exhaustive list of applications that currently
make use of the Privacy Pass protocol, or some variant of the
underlying functionality.
Cloudflare uses an implementation of the Privacy Pass protocol for
allowing clients that have previously interacted with their Internet
challenge protection system to bypass future challenges PPSRV.  These
challenges can be expensive for clients, and there have been cases
where bugs in the implementations can severely degrade client
accessibility.
Clients must install a browser extension PPEXT that acts as the
Privacy Pass client in an exchange with Cloudflare's Privacy Pass
server, when an initial challenge solution is provided.  The client
extension stores the issued tokens and presents a valid redemption
token when it sees future Cloudflare challenges.  If the redemption
token is verified by the server, the client passes through the
security mechanism without completing a challenge.
The Trust Token API TrustTokenAPI has been devised as a generic API
for providing Privacy Pass functionality in the browser setting.  The
API is intended to be implemented directly into browsers so that
server's can directly trigger the Privacy Pass workflow.
The PrivateStorage API developed by Least Authority is a solution for
uploading and storing end-to-end encrypted data in the cloud.  A
recent addition to the API PrivateStorage allows clients to generate
Zero-knowledge Access Passes (ZKAPs) that the client can use to show
that it has paid for the storage space that it is using.  The ZKAP
protocol is based heavily on the Privacy Pass redemption mechanism.
The client receives ZKAPs when it pays for storage space, and redeems
the passes when it interacts with the PrivateStorage API.
The browser Brave uses Basic Attention Tokens (BATs) to provide the
basis for an anonymity-preserving rewards scheme Brave.  The BATs are
essentially Privacy Pass redemption tokens that are provided by a
central Brave server when a client performs some action that triggers
a reward event (such as watching an advertisement).  When the client
amasses BATs, it can redeem them with the Brave central server for
rewards.
If the value of U is much bigger (e.g. 5 million) then this would
permit I = (log_2(5000000/5000)-1)/2 ~= 4 Issuers.