Draft: draft-ietf-privacypass-architecture

Commentary: Looks good with the reframe . 
 Should be " for each Origin " ? The previous paragraph says " For example , these 4 Issuers could be different for each Client . " But does n't really explain how that might be exploited in an attack on Client privacy . I think that there is an unstated assumption here : the Client has interactions with multiple  and uses a single store of tokens from a limited set of Issuers . This is not at all clear . Much of the text of the document concentrates on the challenge - based flow , where an  asks the  to fetch a token from the Issuer . In that context , this text makes little sense . It 's easy to skip over : That ordering is important . If you allow there to be a shared store of tokens and  can ask " do you have a token from Issuer X ? " , then this creates shared state that can be queried . That is a far more dangerous baseline . For that , there needs to be a global cap on the number of Issuers , or there is some information being released . On the other hand , I 'm not sure that we need the ability to check whether tokens are present . I think that it is sufficient for the Origin to request a token . There is value in having a token cache , but caches can operate without necessarily leaking that they are in use . That does n't totally eliminate time as a factor , but it might help . In any case , the document could do a better job of laying out the various expected interaction models up front . This cached mode is very poorly explained and something of a surprise . 
 These are great points . There seem to be two issues here : privacy implications of " configuration flexibility " ( how many Issuers are allowed ) , and how the number of Issuers should be handled . models . We really need to add these to the document . Minimally , I think it makes sense to walk through the end - to - end challenge to redemption flow with and without a token cache . We could also cover error cases , e.g. , where the  fails to produce a token and does n't present anything to the Origin . Failure to produce a token could be due to compatibility reasons , e.g. , the challenge tokentype , origininfo , or issuer_name values are invalid , or because of attestation or issuance failures . 
 There is an attack on some of the deployment models that is n't well acknowledged in or . In this attack , there are bits of  ( where is n't necessarily ordinal ) or different keys . In this model , if the Issuer is able to identify users , they can identify users for special treatment at the Origin . Those users get assigned a unique value for  ( or use a key that is unique to them ) , so that they can be reidentified at the Origin . The remaining identifier is assigned to all other users . I was initially only a little concerned about this style of attack . This only applies to those deployment models where the Issuer is exposed to information about Clients . And the proposed 6 metadata values only permit 5 users being linked this way . That seemed fine . If there is no way in which a value used for targeting can not be reused at a high rate . ... There is an interactive flow ( see the issuance request ) , so I believe that those values could be reused for tracking on a relatively short time scale . The Issuer and Origin can coordinate their efforts so that when one of the targeted values is used , it is redeemed nearly immediately , then released back for reuse . The way this works is that on each round the Issuer picks issuance requests and allocates one of the special metadata values to those users . The issuer can now reidentify the user that it issued these tokens to . The Issuer provides the Origin with an endpoint that says " I just got token with   , what user did you allocate it to ? " for which querying has the side effect of releasing metadata X for reuse . This provides the Issuer a way to provide the Origin with the identity - as known to the Issuer - of those users . This overall process can operate continuously with a flow of Issuer - Client - Origin - Issuer . Consequently , the number of users that can be linked with this approach is very high as the time where each targeting value is outstanding is low ( this amounts to a single round trip to the user ) . Stalls would occur if clients fail to complete their part in this , but that should be rare . You might get something like users per second linked , depending on the token issuance rate . Issuers with millions of users will find it takes a while to get through them all , but with 6 values , that 's 2 million a day or thereabouts if you assume a modest 250ms RTT . I 'm not sure how to defend against this . Including limited metadata is a direct goal , but this attack operates entirely within the envelope that allowing  creates . As this is a direct goal , consistency ca n't help . If  were removed and diverse keys could not be used for metadata -- that is , keys are strictly sequenced and the consistency mechanism ensured that the Issuer could n't switch back and forth , perhaps by marking key cutovers with a firm time of effect -- then maybe this is more tractable . There would be a brief period at each key changeover where maybe some number of users might be targeted by exploiting clock skew , but that 's all . Losing metadata seems pretty bad though . 
 All of the currently specified versions of the issuance protocol do n't include any  , so they fall into the case you mention where consistency can be an effective tool to prevent targeting . It seems to me that the main issue here is how to allow future versions that include metadata to be used safely . For example , maybe metadata - including token types must not be used with interactive token issuance . 
 This problem exists in any design that allows for multiple keys without strict controls on the use of those keys , in addition to those designs that allow  . As for interactive vs. the cached design ( see ) only changes the RTT between client and server . If the issuance model involves a Client requesting tokens on demand ( see ) , then the use of caching could lengthen the delay , but only to the extent that the  or Issuer ca n't somehow avoid using the cache . But the Issuer can , with . Cache invalidation allows the Issuer to force the client into what is effectively an interactive protocol . In other settings where the client has a strict schedule that it operates on , it might not be possible to drive this as fast . The client might expect a minimum - sized set of tokens to be provided each time , with no way to have those tokens invalidated or the supply exhausted more quickly than the schedule dictates . In that case , the RTT might be as long as a day or a week and the throughput for tracking tanks . 
 I think we need to keep private state tokens out of this discussion . To my knowledge , it 's currently misaligned with Privacy Pass on an architectural level and at a protocol level . It 's just causing confusion . ( Flagging to to emphasize that we really need to get these things aligned to avoid this confusion going forward ! ) The general issue here is that privacy decreases as allowed metadata values increase , where metadata can be in the form of multiple keys or arbitrary things bound to tokens during the issuance protocol . As with other issues , privacy here depends in part on your consistency story . My takeaway from this issue is that the architecture document does an inadequate job describing the privacy properties of this thing . I think we could benefit from putting privacy right at the top -- not buried in subsections about deployment models or metadata -- and discussing consistency as a necessary condition for meaningful privacy . thoughts ? 
 Agreed with  that we should n't be analyzing this in the context of Private State Tokens , which needs more work to be aligned as far as I know . We may need to make clearer the guardrails though , and explain the privacy properties of various deployment models , and where things break down . Use of privacy pass does n't require any API like what is in Private State Tokens , since it works as just a normal HTTP auth method , so I think we should focus on that normal pattern where the origin challenges for tokens and the client presents tokens it has cached , or has to get a new one . 
 I think that would certainly help . I do n't quite see a disconnect between this and the Private State Token API work , but maybe that 's exactly the point . Understanding the expected interaction model between Client and Issuer is going to be very important to this . I see the draft as very strongly leaning toward the interactive model , but as noted elsewhere , that 's not necessarily going to produce good outcomes . 
 Let 's just keep Private State Tokens out of the equation for now . I do n't really understand why you say that the client and issuer interaction is important , or why you zero in on interactivity as the issuance model , specifically . Regardless , I think all of this stems from our inability to precisely describe the privacy properties of the system , and the requirements needed to achieve those properties . 
 does n't really acknowledge this . And is a bit of a warning flag : A forward reference to might help . 
 Looking good , just some minor comments
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert as for
token issuance and redemption.  This section describes the purpose of
token issuance and redemption and the requirements on the relevant
participants.
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert for token
issuance and redemption.  This section describes the purpose of token
issuance and redemption and the requirements on the relevant
participants.
If the Client already has a token available that satisfies the
token challenge, it can skip to step 6 and redeem its token.
Otherwise, it invokes the issuance protocol to request a token
from the designated Issuer.
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step 6 and redeem its
token.  Otherwise, it invokes the issuance protocol to request a
token from the designated Issuer.
The privacy goals of Privacy Pass are oriented around unlinkability
based on these contexts.  In particular, Privacy Pass aims to achieve
Origin-Client unlinkability.  This means that given two redemption
contexts, the Origin cannot determine if both redemption contexts
correspond to the same Client or two different Clients.  Informally,
this means that a Client in a redemption context is indistinguishable
from any other Client that might use the same redemption context.
The set of Clients that share the same redemption (or issuance)
context is referred to as an anonymity set.  Privacy Pass also aims
to achieve Issuer-Client unlinkability, which is similar to Origin-
Client unlinkability in that a Client in an issuer context is
indistingusihable from any other Client that might use the same
issuer context.  Depending on the deployment model, Privacy Pass
might also aim to achieve Attester-Origin unlinkability.  Similar to
Origin-Client and Issuer-Client unlinkability, this means that given
two attestation contexts, the Attester cannot determine if both
contexts correspond to the same Origin or two different Origins.  The
set of Clients that share the same attestation context is referred to
as an anonymity set.
At a high level, these properties ensure that no single party amongst
the Attester, Issuer, or Origin can link client identifying
information to client activity, e.g., the origin being accessed.
The manner in which Origin-Client, Issuer-Client, and Attester-Origin
unlinkability are achieved depends on the deployment model, type of
attestation, and issuance protocol details.  For example, as
discussed in deployment, failure to use a privacy-enhancing proxy
system such as Tor Dingledine2004 when interacting with Attesters,
Isuers, or Origins allows the set of possible Clients to be
partitioned by the Client's IP address, and can therefore lead to
unlinkability violations.  Similarly, malicious Origins may attempt
to link two redemption contexts together by using Client-specific
Issuer public keys.  See deployment and privacy for more information.
Clients obtain the Issuer public key directly from the Origin using
the process described in AUTHSCHEME.  Clients can apply some form of
consistency check to determine if this public key is consistent and
correct for the specified Issuer.  See CONSISTENCY for example
mechanisms.  Depending on the deployment, the Attester might assist
the Client in applying these consistency checks across clients.  See
rotation-and-consistency for more information.  Failure to apply a
consistency check can allow Client-specific keys to impact the Client
anonymity set.  See rotation-and-consistency for more details.
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, such as through the use of an IP-hiding proxy
service like Tor Dingledine2004.  In general, Clients SHOULD minimize
or remove identifying information where possible when invoking the
issuance protocol.
Clients obtain the Issuer public key directly from the Origin using
the process described in AUTHSCHEME.  Clients can apply some form of
consistency check to determine if this public key is consistent and
correct for the specified Issuer.  See CONSISTENCY for example
mechanisms.  Depending on the deployment, the Attester might assist
the Client in applying these consistency checks across clients.
Failure to apply a consistency check can allow Client-specific keys
to violate unlinkability.  See rotation-and-consistency for more
information.
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, such as 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.
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.
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.
Every bit of metadata can be used to partition the Client anonymity
set; see metadata-privacy for more inforation.
A Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
browsing history.  Depending on the deployment model, separating
these contexts can take different forms.  The Origin, Attester, and
Issuer portrayed in fig-overview can be instantiated and deployed in
a number of ways.
The Origin, Attester, and Issuer portrayed in fig-overview can be
instantiated and deployed in a number of ways.  The deployment model
directly influences the manner in which attestation, issuance, and
redemption contexts are separated to achieve Origin-Client, Issuer-
Client, and Attester-Origin unlinkability.
The discussion below assumes non-collusion between entities that have
access to the attestation context and entities that have access to
the redemption context, as collusion between such entities would
enable linking of these contexts.  Generally, this means that
entities operated by separate parties do not collude.  Mechanisms for
enforcing non-collusion are out of scope for this architecture.
The discussion below assumes non-collusion between entities that have
access to the attestation, issuance, and redemption contexts, as
collusion between such entities would enable linking of these
contexts and may lead to unlinkability violations.  Generally, this
means that entities operated by separate parties do not collude.
Mechanisms for enforcing non-collusion are out of scope for this
architecture.
This model represents the initial deployment of Privacy Pass, as
described in PPSRV.  In this model, the Attester, Issuer, and Origin
share the attestation and redemption contexts.  As a result,
attestation mechanisms that can uniquely identify a Client, e.g.,
requiring that Clients authenticate with some type of application-
layer account, are not appropriate, as they could be used to learn or
reconstruct a Client's browsing history.
Attestation and redemption context unlinkability requires that these
events be separated over time, such as through the use of tokens with
an empty redemption context, or be separated over space, such as
through the use of an anonymizing proxy when connecting to the
Origin.
This model represents the initial deployment of Privacy Pass, as
described in PPSRV.  In this model, the Attester, Issuer, and Origin
share the attestation, issuance, and redemption contexts.  As a
result, attestation mechanisms that can uniquely identify a Client,
e.g., requiring that Clients authenticate with some type of
application-layer account, are not appropriate, as they could lead to
unlinkability violations.
Origin-Client, Issuer-Client, and Attester-Origin unlinkability
requires that issuance and redemption events be separated over time,
such as through the use of tokens with an empty redemption context,
or be separated over space, such as through the use of an anonymizing
proxy when connecting to the Origin.
This model is useful if an Origin wants to offload attestation and
issuance to a trusted entity.  In this model, the Attester and Issuer
share an attestation context for the Client, which can be separate
from the Origin's redemption context.
For certain types of issuance protocols, this model separates
attestation and redemption contexts.  However, issuance protocols
that require the Issuer to learn information about the Origin, such
as that which is described in RATE-LIMITED, are not appropriate since
they could link attestation and redemption contexts through the
Origin name.
This model is useful if an Origin wants to offload attestation and
issuance to a trusted entity.  In this model, the Attester and Issuer
share an attestation and issuance context for the Client, which is
separate from the Origin's redemption context.
For certain types of issuance protocols, this model achieves Origin-
Client, Issuer-Client, and Attester-Origin unlinkability.  However,
issuance protocols that require the Issuer to learn information about
the Origin, such as that which is described in RATE-LIMITED, are not
appropriate since they could lead to Attester-Origin unlinkability
violations through the Origin name.
In this model, attestation and redemption contexts are separate.  As
a result, any type of attestation is suitable in this model.
Moreover, any type of token challenge is suitable assuming there is
more than one Origin involved, since no single party will have access
to the identifying Client information and unique Origin information.
If there is only a single Origin, then per-Origin tokens are not
appropriate in this model, since the Attester can learn the
redemption context.  However, the Attester does not learn whether a
token is per-Origin or cross-Origin.
In this model, attestation contexts are separate from issuer and
redemption contexts.  As a result, any type of attestation is
suitable in this model.  Moreover, any type of token challenge is
suitable assuming there is more than one Origin involved, since no
single party will have access to the identifying Client information
and unique Origin information.  If there is only a single Origin,
then per-Origin tokens are not appropriate in this model, since the
Attester can learn the redemption context.  However, the Attester
does not learn whether a token is per-Origin or cross-Origin.
This is the most general deployment model, and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see RATE-LIMITED for one such type of issuance protocol.
In this model, the Attester, Issuer, and Origin have a separate view
of the Client: the Attester sees potentially sensitive Client
identifying information, such as account identifiers or IP addresses,
the Issuer sees only the information necessary for issuance, and the
Origin sees token challenges, corresponding tokens, and Client source
information, such as their IP address.  As a result, attestation and
redemption contexts are separate, and therefore any type of token
challenge is suitable in this model as long as there is more than a
single Origin.  As in the Joint Origin and Issuer model in deploy-
joint-origin, if there is only a single Origin, then per-Origin
tokens are not appropriate.
A Client uses Privacy Pass to separate attestation context and
redemption context.  This separation means that the attestation
context (or redemption context) for a Client does not uniquely
identify the redemption context (or attestation) context.  In other
words, for a given attestation context, there exists a sufficiently
large anonymity set of Clients that share the same redemption
context, and vice versa.
Maintaining these anonymity sets is a fundamental requirement for
Privacy Pass deployments.  In practice, there are a number of ways in
which these anonymity sets can be partitioned.  For example, as
discussed in deployment, failure to use a privacy-enhancing proxy
system such as Tor when interacting with Attesters, Isuers, or
Origins allows the anonymity set to be partitioned by the Client's IP
address.  Similarly, malicious Origins may attempt to partition the
anonymity set for a given redemption context by using Client-specific
Issuer public keys.
The following sections discuss issues that can influence Client
anonymity set.  For each issue, we discuss mitigations or safeguards
to protect against the underlying problem.
This is the most general deployment model, and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see RATE-LIMITED for one such type of issuance protocol.
In this model, the Attester, Issuer, and Origin have a separate view
of the Client: the Attester sees potentially sensitive Client
identifying information, such as account identifiers or IP addresses,
the Issuer sees only the information necessary for issuance, and the
Origin sees token challenges, corresponding tokens, and Client source
information, such as their IP address.  As a result, attestation,
issuance, and redemption contexts are separate, and therefore any
type of token challenge is suitable in this model as long as there is
more than a single Origin.  As in the Joint Origin and Issuer model
in deploy-joint-origin, if there is only a single Origin, then per-
Origin tokens are not appropriate.
In practice, there are a number of ways in which the size of
anonymity sets may be reduced or partitioned, though they all center
around the concept of consistency.  In particular, by definition, all
Clients in an anonymity set share a consistent view of information
needed to run the issuance and redemption protocols.  An example type
of information needed to run these protocols is the Issuer public
key.  When two Clients have inconsistent information, these Clients
effectively have different redemption contexts and therefore belong
in different anonymity sets.
The following sections discuss issues that can influence anonymity
set size.  For each issue, we discuss mitigations or safeguards to
protect against the underlying problem.
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 Issuers 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, bounding the metadata permitted ensures that it
cannot uniquely identify individual Clients.
Issuer configuration updates, e.g., due to key rotation, are an
important part of hedging against long-term private 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.
Configuration changes can also be used to segment Client anonymity
sets.  In particular, when an Issuer updates their configuration and
the corresponding key pair, any Client that invokes the issuance
protocol with this configuration becomes be part of a set of Clients
which also ran the issuance protocol using the same configuration.
To mechanize this attack strategy, an Issuer could introduce a
configuration rotation policy that forces Clients into small
anonymity sets.
In general, key rotations represent a trade-off between Client
privacy and Issuer security.  Therefore, it is important that key
rotations occur on a regular cycle to reduce the harm of an Issuer
key compromise.  As a result, Clients SHOULD employ some form of
consistency mechanism to ensure that they receive the same
configuration information and are not being actively partitioned into
smaller anonymity sets.  See CONSISTENCY for possible consistency
mechanisms.
Similarly to the Issuer rotation dynamic discussed above, if there
are a large number of Issuers, and Origins accept all of them,
segregation can occur.  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 learns.  Therefore, there is
an exponential loss in anonymity relative to the number of Issuers.
For example, if there are 32 Issuers, then Origins learn 32 bits of
information about the Client if a valid token is presented for each
Issuer.  As a contrasting example, if Clients ensure that they only
hold tokens issued from 4 Issuers, 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 Issuers were
permitted across the whole system.  For example, these 4 Issuers
could be different for each Client.  Therefore, the selection of
Issuers for which a Client possesses tokens is still revealing.  This
trade-off is important in deciding the effective anonymity of each
Client in the system.
Clients SHOULD bound the number of Issuers they are willing to
request tokens from at any given time.  The exact bound depends on
the deployment model and number of Clients, i.e., having a very large
Client base 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.
Alternatively, when applicable, trusted registries can indicate which
Issuers are deemed to be active.  If a Client is asked to invoke the
issuance protocol for an Issuer that is not declared active, then the
client can refuse to run the protocol and obtain a token.
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 partitions".  Within each
partition, the Client would place an upper bound on the number of
allowed Issuers.  As long as each redemption partition maintains a
strong privacy boundary with the others, the number of bits of
information the Origin can learn is bounded by the number of
redemption partitions.
Side-channel attacks, such as those based on timing correlation,
could be used to link attestation and redemption contexts together.
In particular, for interactive tokens that are bound to a Client-
specific redemption context, the anonymity set of Clients during the
issuance protocol consists of those Clients that started issuance
between the time of the Origin's challenge and the corresponding
token redemption.  Depending on the number of Clients using a
particular Issuer during that time window, the set can be small.
Appliations should take such side channels into consideration before
choosing a particular deployment model and type of token challenge
and redemption context.
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 Issuers 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, limiting the amount of metadata permitted helps limit the
extent to which metadata can uniquely identify individual Clients.
Clients SHOULD bound the number of possible metadata values in
practice.  Most token types do not admit any metadata, so this bound
is implicitly enforced.  Moreover, Privacy Pass deployments SHOULD
NOT use metadata unless its value has been assessed and weighed
against the corresponding reduction in Client privacy.
Anonymity sets can be partitioned by information used for the
issuance protocol, including: metadata, Issuer configuration (keys),
and Issuer selection.
Any issuance metadata bits of information can be used to partition
the Client anonymity set.  For example, 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).
The number of active Issuer configurations also contributes to
anonymity set partitioning.  In particular, when an Issuer updates
their configuration and the corresponding key pair, any Client that
invokes the issuance protocol with this configuration becomes be part
of a set of Clients which also ran the issuance protocol using the
same configuration.  Issuer configuration updates, e.g., due to key
rotation, are an important part of hedging against long-term private
key compromise.  In general, key rotations represent a trade-off
between Client privacy and Issuer security.  Therefore, it is
important that key rotations occur on a regular cycle to reduce the
harm of an Issuer key compromise.
Lastly, if Clients are willing to issue and redeem tokens from a
large number of Issuers for a specific Origin, and that Origin
accepts tokens from all Issuers, segregation can occur.  In
particular, if a Client obtains tokens from many Issuers and an
Origin later challenges that Client for a token from each Issuer, the
Origin 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 learns.  Therefore, there is an
exponential loss in anonymity relative to the number of Issuers.
The fundamental problem here is that the number of possible issuance
configurations, including the keys in use and the Issuer identities
themselves, can partition the Client anonymity set.  To mitigate this
problem, Clients SHOULD bound the number of active issuance
configurations per Origin as well as across Origins.  Moreover,
Clients SHOULD employ some form of consistency mechanism to ensure
that they receive the same configuration information and are not
being actively partitioned into smaller anonymity sets.  See
CONSISTENCY for possible consistency mechanisms.
Side-channel attacks, such as those based on timing correlation,
could be used to reduce anonymity set size.  In particular, for
interactive tokens that are bound to a Client-specific redemption
context, the anonymity set of Clients during the issuance protocol
consists of those Clients that started issuance between the time of
the Origin's challenge and the corresponding token redemption.
Depending on the number of Clients using a particular Issuer during
that time window, the set can be small.  Appliations should take such
side channels into consideration before choosing a particular
deployment model and type of token challenge and redemption context.