Draft: draft-ietf-privacypass-architecture

Commentary: cc this is largely inspired by your feedback ! The intent here is to explain roughly how information flows throughout the various parties in the system , and then to lean on that flow of information in the deployment model section . 
 I think we 've faithfully responded to your helpful comments and review , so I 'm going to merge this . Please do let us know if you think there 's more that should be done , though ! 
 I pushed fixes directly to main -- thanks again ! 
 It seems like this is not the case ( from Section 4.3 ): This implies something about the way in which per - origin tokens are attested that does not follow from any of the previous text . But I do n't know what . Is it the case that the client needs to communicate the origin that a per - origin token needs to be bound to ? Does this assume that the issuer in this deployment configuration is receiving this information via the attester ? Why is it that the client ca n't use a proxy ( or OHTTP ) to request a token from the issuer ? 
 The per - origin tokens are tokens that are generated based on a challenge with a non - empty field . A cross - origin token has an empty . 
 None of this is really clear from the description in the architecture . 
 does the text in , which describes the ways in which token challenges can vary , not suffice ? If not , can you help us understand what 's missing ? 
 What is missing is a description of the sort of information that is exchanged between different roles in these cases . That might be aided by including a reference to specific fields ( like ) or by talking about the requirements more generally . The problem with the text in Section 3.1 is that it says the token is bound to an origin or not , but it does n't really give enough context to understand how this might happen .  's explanation about origin is correct and obvious , but not particularly satisfying as an answer , because it 's nearly a truism ( obviously you need an origin for something to be origin - bound ) . I did n't realize this until I 'd spent some time thinking about this , but when the origin needs tokens to be bound in some way to information from the origin[^1 ] , that information needs to make it to the issuer . That the issuer needs to see that information seems to be the primary motivation for the attester / issuer split . [ ^1 ] : The identity of the origin is the obvious thing the origin might need to provide . It 's the only thing you talk about in the document , but there is a more general statement to be made : it might be necessary to bind to arbitrary information that the origin supplies , which the issuer also needs to see in order to construct a token . For instance , with a blind signature , the client could use the issuer as a signing oracle and include the origin in the data that is signed , but that might make token forgery for arbitrary origins trivial without a ZKP to accompany the signing request . The bit that makes this hard to grok is that the ZKP design is entirely valid here , so why do you need the attester / issuer split ? My best answer is that you do n't , except when it is easier to build a system that does n't rely on cryptography that is generally pretty unpleasant to work with . The split , avoids a situation where one entity simultaneously sees client identity or client - specific information ( which is sometimes necessary for the attester ) and information about the usage context ( again , sometimes necessary for the issuer ) . If it were n't for that , the issuer and attester could be the same entity . This is an important piece of the architecture , but the document never really says that . The information about per - origin tokens just is n't connected to the description of the different roles . 
 In thinking about this issue some more , I think we can probably resolve this comment by building on the trust relationships and cardinality discussion that 's in a separate PR . The text in the original comment refers to the fact that , in deployments where an there is an attester that uses an issuer that is configured for only one origin , say , A.com , then any token request for a specific origin must necessarily be for A.com . I think the primary problem here is that text is a bit confusing in that , well , if there 's an issuer that only supports one origin , then how can it work for cross - origin tokens ? I will try to simplify . 
 As I started to dig into that clarification , Martin 's original idea to start talking about things in terms of information flow really seemed like the natural conclusion , so that 's what tries to do . Please review ! 
 Thanks for all the work on this .
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert for token
redemption and issuance.  This section presents an overview of
Privacy Pass, a high-level description of the threat model and
privacy goals of the architecture, and the purpose of the the
redemption and issuance protocols, including requirements on the
relevant participants in these protocols, necessary to achieve the
intended privacy goals.
The Privacy Pass architecture consists of four logical entities -
Client, Origin, Issuer, and Attester - that work in concert for token
redemption and issuance.  This section presents an overview of
Privacy Pass, a high-level description of the threat model and
privacy goals of the architecture, and the goals and requirements of
the redemption and issuance protocols.
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-redemption and
redeem its token; see hoarding for security considerations of
cached tokens.
If the attestation process completes successfully, the client
creates a Token Request to send to the designated Issuer
(generally via the Attester).  The Attester and Issuer might be
functions on the same server, depending on the deployment model
(see deployment).  Depending on the attestation process, it is
possible for attestation to run alongside the issuance protocol,
e.g., where Clients send necessary attestation information to the
Attester along with their Token Request.  If the attestation
process fails, the Client receives an error and issuance aborts
without a token.
If the attestation process completes successfully, the client
creates a Token Request to send to the designated Issuer
(generally via the Attester, though it is not required to be sent
through the Attester).  The Attester and Issuer might be functions
on the same server, depending on the deployment model (see
deployment).  Depending on the attestation process, it is possible
for attestation to run alongside the issuance protocol, e.g.,
where Clients send necessary attestation information to the
Attester along with their Token Request.  If the attestation
process fails, the Client receives an error and issuance aborts
without a token.
The interactions and set of information shared between the Client
and Attester only, for the purposes of attesting the vailidity of
the Client.  This context includes all information associated with
attestation, such as the timestamp of the event and any Client
visible information, including information needed for the
attestation procedure to complete.
The privacy goals of Privacy Pass assume a threat model in which
Origins trust specific Issuers to produce tokens, and Issuers in turn
trust one or more Attesters to correctly run the attestation
procedure with Clients.  This arrangement ensures that tokens which
validate for a given Issuer were only issued to a Client that
successfully complete attestation with an Attester that the Issuer
trusts.  Moreover, this arrangement means that if an Origin accepts
tokens issued by an Issuer that trusts multiple Attesters then a
Client can use any of these Attesters to issue and redeem tokens for
the Origin.
The mechanisms for establishing trust between each entity in this
arrangement are deployment specific.  For example, in settings where
Attesters and Issuers communicate over TLS, Attesters and Issuers may
use mutually authenticated TLS to authenticate one another.
The interactions and set of information shared between the Client
and Origin, i.e., the information that is provided or otherwise
available to the Origin during redemption that might be used to
identify a Client and construct a token challenge.  This context
includes all information associated with redemption, such as the
timestamp of the event, Client visible information (including the
IP address), and the Origin name.
The interactions and set of information shared between the Client,
Attester, and Issuer, i.e., the information that is provided or
otherwise available to Attester and Issuer during issuance that
might be used to identify a Client.  This context includes all
information associated with issuance, such as the timestamp of the
event, any Client visible information (including the IP address),
and the Origin name (if revealed during issuance).  This does not
include the token challenge in its entirety, as that is kept
secret from the Issuer during the issuance protocol.
The interactions and set of information shared between the Client
and Attester only, for the purposes of attesting the vailidity of
the Client, that is provided or otherwise available during
attestation that might be used to identify the Client.  This
context includes all information associated with attestation, such
as the timestamp of the event and any Client visible information,
including information needed for the attestation procedure to
complete.
The privacy goals of Privacy Pass assume a threat model in which
Origins trust specific Issuers to produce tokens, and Issuers in turn
trust one or more Attesters to correctly run the attestation
procedure with Clients.  This arrangement ensures that tokens which
validate for a given Issuer were only issued to a Client that
successfully completed attestation with an Attester that the Issuer
trusts.  Moreover, this arrangement means that if an Origin accepts
tokens issued by an Issuer that trusts multiple Attesters, then a
Client can use any one of these Attesters to issue and redeem tokens
for the Origin.
The mechanisms for establishing trust between each entity in this
arrangement are deployment specific.  For example, in settings where
Clients interact with Issuers through an Attester, Attesters and
Issuers might use mutually authenticated TLS to authenticate one
another.  In settings where Clients do not communicate with Issuers
through an Attester, the Attesters might convey this trust via a
digital signature over that Issuers can verify.
Attester-Origin unlinkability.  This is similar to Origin-Client
and Issuer-Client unlinkability.  It 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.
Issuer-Client unlinkability.  This is similar to Origin-Client
unlinkability in that a Client in an issuance context is
indistinguishable from any other Client that might use the same
issuance context.  The set of Clients that share the same issuance
context is referred to as an issuance anonymity set.
Attester-Origin unlinkability.  This is similar to Origin-Client
and Issuer-Client unlinkability.  It 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 attestation anonymity set.
The remainder of this section describes the functional properties and
security requirements of the redemption and issuance protocols in
more detail.
The remainder of this section describes the functional properties and
security requirements of the redemption and issuance protocols in
more detail. flow describes how information flows between Issuer,
Origin, Client, and Attester through these protocols.
How Clients respond to token challenges can have privacy
implications.  For example, if a token challenge admits a choice of
Issuer, then the choice of Issuer can reveal information about the
Client used to partition anonymity sets; see rotation-and-consistency
for more information about these privacy considerations.
How Clients respond to token challenges can have privacy
implications.  For example, if an Origin allows the Client to choose
an Issuer, then the choice of Issuer can reveal information about the
Client used to partition anonymity sets; see rotation-and-consistency
for more information about these privacy considerations.
The Privacy Pass issuance protocol, described in ISSUANCE, is a two-
message protocol that takes as input a TokenChallenge from the
redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token
(AUTHSCHEME, Section 2.2), as shown in the figure below.
The Privacy Pass issuance protocol, described in ISSUANCE, is a two-
message protocol that takes as input a TokenChallenge from the
redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token
(AUTHSCHEME, Section 2.2), as shown in fig-overview.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer, regardless of the
hardness assumptions of the underlying cryptographic protocol(s).
The issuance protocol can reveal the Issuer public key for the
purposes of determining which private key to use in producing the
token.  This property is sometimes also referred to as blindness.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer, regardless of the
hardness assumptions of the underlying cryptographic protocol(s).
This property is sometimes also referred to as blindness.
Attestation is an important part of the issuance protocol.  In
Privacy Pass, attestation is the process by which an Attester bears
witness to, confirms, or authenticates a Client so as to verify a
property about the Client that is required for Issuance.  Clients
explicitly trust Attesters to perform attestation correctly and in a
way that does not violate their privacy.
In Privacy Pass, attestation is the process by which an Attester
bears witness to, confirms, or authenticates a Client so as to verify
properties about the Client that are required for Issuance.  Issuers
trust Attesters to perform attestation correctly.
The role of the Attester in the issuance protocol and its impact on
privacy depends on the type of attestation procedure, issuance
protocol, deployment model.  For instance, requiring a conjunction of
attestation procedures could decrease the overall anonymity set size.
As an example, the number of Clients that have solved a CAPTCHA in
the past day, that have a valid account, and that are running on a
trusted device is less than the number of Clients that have solved a
CAPTCHA in the past day.  Attesters SHOULD NOT be based on
attestation procedures that result in small anonymity sets.
Depending on the issuance protocol, the Issuer might learn
information about the Origin.  To ensure Issuer-Client unlinkability,
the Issuer should be unable to link that information to a specific
Client.  For such issuance protocols where the Attester has access to
Client-specific information, such as is the case for attestation
procedures that involve Client-specific information (such as
application-layer account information) or for deployment models where
the Attester learns Client-specific information (such as Client IP
addresses), Clients trust the Attester to not share any Client-
specific information with the Issuer.  In deployments where the
Attester does not learn Client-specific information, the Client does
not need to explicitly trust the Attester in this regard.
Issuers trust Attesters to correctly and reliably perform
attestation.  However, certain types of attestation can vary in value
over time, e.g., if the attestation procedure is compromised.  Broken
attestation procedures are considered exceptional events and require
configuration changes to address the underlying cause.  For example,
if attestation is compromised because of a zero-day exploit on
compliant devices, then the corresponding attestation procedure
should be untrusted until the exploit is patched.  Addressing changes
in attestation quality is therefore a deployment-specific task.  In
Split Attester and Issuer deployments (see deploy-split), Issuers can
choose to remove compromised Attesters from their trusted set until
the compromise is patched.
From the perspective of an Origin, tokens produced by an Issuer with
at least one compromised Attester cannot be trusted assuming the
Origin does not know which attestation procedure was used for
issuance.  This is because the Origin cannot distinguish between
tokens that were issued via compromised Attesters and tokens that
were issued via uncompromised Attesters absent some distinguishing
information in the tokens themselves or from the Issuer.  As a
result, until the attestation procedure is fixed, the Issuer cannot
be trusted by Origins.  Moreover, as a consequence, any tokens issued
by an Issuer with a compromised attester may no longer be trusted by
Origins, even if those tokens were issued to Clients interacting with
an uncompromised Attester.
The end-to-end process of redemption and issuance protocols involves
information flowing between Issuer, Origin, Client, and Attester.
That information can have implications on the privacy goals that
Privacy Pass aims to provide as outlined in privacy-and-trust.  In
this section, we describe the flow of information between each party.
How this information affects the privacy goals in particular
deployment models is further discussed in deployment.
To use Privacy Pass, Origins choose an Issuer from which they are
willing to accept tokens.  Origins then construct a token challenge
using this specified Issuer and information from the redemption
context it shares with the Client.  This token challenge is then
delivered to a Client.  The token challenge conveys information about
the Issuer and the redemption context, such as whether the Origin
desires a per-Origin or cross-Origin token.  Any entity that sees the
token challenge might learn things about the Client as known to the
Origin.  This is why input secrecy is a requirement for issuance
protocols, as it ensures that the challenge is not directly available
to the Issuer.
Clients interact with the Attester to prove that they meet some
required set of properties.  In doing so, Clients contribute
information to the attestation context, which might include sensitive
information such as application-layer identities, IP addresses, and
so on.  Clients can choose whether or not to contribute this
information based on local policy or preference.
Clients use the issuance protocol to produce a token bound to a token
challenge.  In doing so, there are several ways in which the issuance
protocol contributes information to the attestation or issuance
contexts.  For example, a token request may contribute information to
the attestation or issuance contexts as described below.
Issuance protocol.  The type of issuance protocol can contribute
information about the Issuer's capabilities to the attestation or
issuance contexts, as well as the capabilities of a given Client.
For example, if a Client is presented with multuiple issuance
protocol options, then the choice of which issuance protocol to
use can contrbute information about the Client's capabilities.
Issuer configuration.  Information about the Issuer configuration,
such as its identity or the public key used to validate tokens it
creates, can be revealed during issuance and contribute to the
attestation or issuance contexts.
Attestation information.  The issuance protocol can contribute
information to the attestation or issuance contexts based on what
attestation procedure the Issuer uses to trust a token request.
In particular, a token request that is validated by a given
Attester means that the Client which generated the token request
must be capable of the completing the designated attestation
procedure.
Origin information.  The issuance protocol can contribute
information about the Origin that challenged the Client in
challenge-flow.  In particular, a token request designated for a
specific Issuer might imply that the resulting token is for an
Origin that trusts the specified Issuer.  However, this is not
always true, as some token requests can correspond to cross-Origin
tokens, i.e., they are tokens that would be accepted at any Origin
that accepts the cross-Origin token.
Moreover, a token response may contribute information to the issuance
attestation or contexts as described below.
Origin information.  The issuance protocol can contribute
information about the Origin in how it responds to a token
request.  For example, if an Issuer learns the Origin during
issuance and is also configured to respond in some way on the
basis of that information, and the Client interacts with the
Issuer transitively through the Attester, that response can reveal
information to the Attester.
Token.  The token produced by the issuance protocol can contain
information from the issuance context.  In particular, depending
on the issuance protocol, tokens can contain public or private
metadata, and Issuers can choose that metadata on the basis of
information in the issuance context.
In general, exceptional cases in the issuance protocol, such as when
either the Attester or Issuer aborts the protocol, can contribute
information to the attestation or issuance contexts.  The extent to
which information in this context harms the Issuer-Client or
Attester-Origin unlinkability goals in privacy-and-trust depends on
deployment model; see deployment.  Clients can choose whether or not
to contribute information to these contexts based on local policy or
preference.
Clients send tokens to Origins during the redemption protocol.  Any
information that is added to the token during issuance can therefore
be sent to the Origin.  Information can either be explicitly passed
in a token, or it can be implicit in the way the Client responds to a
token challenge.  For example, if a Client fails to complete
issuance, and consequently fails to redeem a token in response to a
token challenge, this can reveal information to the Origin that it
might not otherwise have access to.  However, an Origin cannot
necessarily distinguish between a Client that fails to complete
issuance and one that ignores the token challenge altogether.
In this model, the Origin, Attester, and Issuer are all operated by
the same entity, as shown in fig-deploy-shared.
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 that correspond to token challenges
with an empty redemption context (see redemption), or be separated
over space, such as through the use of an anonymizing proxy when
connecting to the Origin.
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.  Clients
interact with the joint Attester and Issuer for attestation and
issuance.  This arrangement is shown in fig-deploy-joint-issuer.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.  The Issuer
accepts token requests that come from trusted Attesters.  Since the
Attester and Issuer are separate entities, this model requires some
mechanism by which Issuers establish trust in the Attester (as
described in privacy-and-trust).  For example, in settings where the
Attester is a Client-trusted service that directly communicates with
the Issuer, one way to establish this trust is via mutually-
authenticated TLS.  However, alernative authentication mechanisms are
possible.  This arrangement is shown below.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.  The Issuer
accepts token requests that come from trusted Attesters.  Since the
Attester and Issuer are separate entities, this model requires some
mechanism by which Issuers establish trust in the Attester (as
described in privacy-and-trust).  For example, in settings where the
Attester is a Client-trusted service that directly communicates with
the Issuer, one way to establish this trust is via mutually-
authenticated TLS.  However, alternative authentication mechanisms
are possible.  This arrangement is shown in fig-deploy-joint-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.
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.
Issuers that produce tokens for a single Origin are not suitable in
this model since an Attester can infer the Origin from a token
request, as described in issue-flow.  However, since the issuance
protocol provides input secrecy, the Attester does not learn details
about the corresponding token challenge, such as whether the token
challenge is per-Origin or cross-Origin.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.  As with the joint
Origin and Issuer model, the Issuer accepts token requests that come
from trusted Attesters, and the details of that trust establishment
depend on the issuance protocol and relationship between Attester and
Issuer; see privacy-and-trust.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.  As with the joint
Origin and Issuer model, the Issuer accepts token requests that come
from trusted Attesters, and the details of that trust establishment
depend on the issuance protocol and relationship between Attester and
Issuer; see privacy-and-trust.  This arrangement is shown in fig-
overview.
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.
As in the Joint Origin and Issuer model in deploy-joint-origin, and
as described in issue-flow, if the Issuer produces tokens for a
single Origin, then per-Origin tokens are not appropriate since the
Attester can infer the Origin from a token request.
Depending on the Origin's token challenge, Clients can request and
cache more than one token using an issuance protocol.  Cached tokens
help improve privacy by separating the time of token issuance from
the time of token redemption, and also allow Clients to reduce the
overhead of receiving new tokens via the issuance protocol.
As a consequence, Origins that send token challenges which are
compatible with cached tokens need to take precautions to ensure that
tokens are not replayed.  This is typically done via keeping track of
tokens that are redeemed for the period of time in which cached
tokens would be accepted for particular challenges.
Moreover, since tokens are not intrinsically bound to Clients, it is
possible for malicious Clients to collude and share tokens in a so-
called "hoarding attack."  As an example of this attack, many
distributed Clients could obtain cacheable tokens and them share them
with a single Client to redeem in a way that would violate an
Origin's attempt to limit tokens to any one particular Client.