Draft: draft-ietf-privacypass-architecture

Commentary: In Section 4.3 ( Join Origin and Issuer ): This appears to be a more general statement that could exist outside of where it appears . There are lots of of things that relate to the ( pairwise ) trust relationships between  , Attester , and Issuer . Furthermore , mutual authentication applies only to the extent that there is direct communication between entities . There is a need for certain pieces of information that passes between these entities to be authenticated , but it would be better to articulate what that data is than to talk about the mechanism so directly . That is , start by saying that when the issuer issues a token , it needs to be assured by the attester ( one that it trusts ) that the nonce it is binding the token was provided by a client that met whatever requirements the attester and issuer agreed would be necessary for issuance . One way to ensure that the issuer can be sure that the attester did this is to have the attester present a request to issue a token itself , over a connection where the attester authenticates itself . An alternative , that might be worse in that it uses bearer tokens , is to rely on the attester signing a claim to that effect and having some other entity ( like the client ) request issuance . 
 To me , this issue suggests we need to discuss the trust relationships very clearly and explicitly in the overview section . Maybe we even dedicate an entire section to it . The specific text in Section 4.3 could then point to that section for its authentication and trust establishment considerations . If this sounds reasonable , I 'll propose text . 
 From a bullet point in Section 3.1 : It seems like the challenge points to a single issuer and the issuer points to one or more attesters . If this is the case , then it might be worth spending a paragraph or sentence on it rather than burying it in an example . Also , at this stage , it is not clear why the  could n't point to more than one Issuer , if it were willing to do so . A forward reference to discussions about this limit here being necessary to prevent widening the cross - contextual flow of information ; though I believe that if the client were to be consistent in its choice , there is no additional information leak ( other than perhaps something inherent to the client 's choice ) . 
 Agreed . As part of , I think we can address this with a section on trust relationships and their cardinality .
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 describes the purpose of token
the redemption and issuance protocols 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
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.
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 visibile information,
including information needed for the attestation procedure to
complete.
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
Attesters and Issuers communicate over TLS, Attesters and Issuers may
use mutually authenticated TLS to authenticate one another.
Clients explicitly trust Attesters to perform attestation correctly
and in a way that does not violate their privacy.  However, Clients
assume Issuers and Origins are malicious.
Given this threat model, the privacy goals of Privacy Pass are
oriented around unlinkability based on redemption, issuance, and
attestation contexts, as described below.
Issuer identity.  Token challenges identify which Issuers are
trusted for a given issuance protocol.  Each Issuer, in turn,
determines which Attesters it is willing to accept in the issuance
protocol.  This means that if an Origin origin.example accepts
tokens issued by Issuer issuer.example, and that Issuer in turn
accepts different types of attestation from more than one trusted
Attester, then a Client may use either of these trusted Attesters
to issue and redeem tokens for origin.example.  However,
origin.example neither explicitly specifies nor learns the
Attesters or their specific attestation procedures used for token
issuance.
Issuer identity.  Token challenges identify which Issuers are
trusted for a given issuance protocol.  As described in privacy-
and-trust, the choice of Issuer determines the type of Attesters
and attestation procedures possible for a token from the specified
Issuer, but the Client does not learn exactly which Attester was
used for a given token issuance event.
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.
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, the Attester must
authenticate itself to the Issuer.  In settings where the Attester is
a Client-trusted service, one way Attesters can authenticate to
Issuers is via mutually-authenticated TLS.  However, alernative
authentication mechanisms are possible.  This arrangement is shown in
fig-deploy-joint-origin.
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, 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.  This arrangement is shown in fig-overview.
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.