Draft: draft-ietf-privacypass-architecture

Commentary: In a successful issuance exchange , the attester provides the issuer with information about the client . The text in Section 3.2.1 points out that the way in which information about the client is combined could reduce anonymity set size in ways that affect privacy . Given that we have a chain of custody , I imagine that the privacy property here is about what the issuer learns about a client . More information means more information that might then propagate from the issue onward to the origin . This means that the attester needs to limit what it passes along to only that which is relevant . The client needs to trust the attester to do this . ... or does it ? The text in Section 3.2.1 implies strongly that this anonymity set size is important , but the constraints on the client - issuer interaction , especially consistency rules , very much limits what the issuer can pass along to the origin . So maybe the system depends less on trusting the attester and more on the combination of the cryptographic properties of the token and the consistency system that mitigates against misuse . None of this appears in the privacy considerations . Should it ? 
 On this point : " Clients do not explicitly trust Issuers . " ( Section 3.2.2 ) This would invalidate much of the discussion of anonymity sets in attestations . This is quite confusing . The client does n't need to trust the issuer , because the issuer is unable to pass information on to others . However , the client can not trust the issuer with information , so it has to trust the attester not to pass stuff along AND it has to use an anonymizing proxy to interact with the issuer so that nothing leaks . This is quite contradictory overall . 
 There are issuance protocols wherein the issuer learns information about the origin by design , like the . In this variant , if the attester were to pass information about the client on to the issuer , then the issuer would be able to reconstruct the ( client , origin ) pair , breaking the unlinkability goals . I agree that in the case where the issuer learns nothing about the origin in the protocol then reliance on the attester is lessened , but we need to make sure we accommodate future issuance protocols here . I 'll think about ways in which we can try to make this more clear . This might go into the privacy considerations , as suggested .
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.
Each attestation procedure also has an impact on the overall system
privacy.  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, 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 admit attestation types that result in small
anonymity sets.
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.