[Privacy-pass] Questions on client trust

[Alex Davidson <[e-mail]>]

Hi all,

Following on from the previous email. There were some initial questions
raised during the BoF that will be important to discuss before we
proceed to rework the charter. The most immediate questions are the
following:

- To what extent should client's trust the issuers when redeeming
tokens?
	- Under what conditions should they accept/redeem tokens?
	- What information does the client trust the issuer to encode in the
	tokens?
- How does an ecosystem protect itself against issuer consolidation
and/or centralization?

The first point is not currently covered by the current charter or docs.
For example, a helpful measure would be for the client to check the size
of the anonymity set that it is part of. Such considerations are
required to be made for any client looking to use an
anonymity-preserving tool. However, checking such measures appears
difficult in the ecosystem that we are looking to construct. There are
currently only recommendations in the architecture doc for redeeming
tokens to reduce the impact of an issuer being able to target a specific
client. I think providing practical mechanisms for allowing clients to
make decisions on which issuers to trust is something that we will be
able to do (such as specifying client/consumer allow-lists). But,
providing the actual measures that the client uses to make these
decisions appears (at least to me) to be beyond the scope of what can be
achieved with the current design.

On the second point of consolidation/centralization, this relates to the
open question of how issuers are monitored by the ecosystem. The
mechanism that we have for managing issuer key material in the
architecture doc introduces a degree of centralization because the
configuration registry must be centrally operated. The practical
mechanisms used by clients to determine which issuers are trusted may
also contribute to this. During Steven's presentation he mentioned some
alternatives to this solution, such as fetching key material directly
from issuers or from an intermediate proxy. However, both approaches
would still need some sort of auditing. This could perhaps be avoided by
introducing some sort of decentralization, though it's not immediately
clear to me what such a solution would look like?

Thanks,
Alex