[Privacy-pass] privacypass virtual BoF follow-up

[Alex Davidson <[e-mail]>]

Hi all,

Firstly, thanks to all of you that participated in the virtual BoF last
week. I thought the discussion was really valuable and will provide
us a great base to rework the charter, and then hopefully work towards
forming a WG. Thanks also to all those that registered interest in
supporting the process of writing, editing and reviewing etc.

Following on from the meeting, I have been over the minutes [1] and the
conversations that occurred in the corresponding jabber session [2]. I just
wanted to highlight below some of the key questions/pieces of feedback
that were raised during the meeting to enable further discussion on
these points.

# General questions & feedback on problem & use-cases:

- It was mentioned a few times that there is *some* similarity with the
problem that is being solved by the RATS working working group [3].
Though, the privacypass WG would specifically target the
application-layer and with a focus on preserving client unlinkability.

- The notion of token transferability is not really covered in the
current charter/documentation, but it is currently inherent with in
the protocol design that we have. We should at least add a discussion
on how this fits into the problem space, and potentially whether we
also need additional protection mechanisms.

- Double-spend protection is currently a listed requirement in the
architecture document, but there may be applications that would prefer
that this is relaxed.

- More discussion in the documents on what constitutes valid metadata
for each issued token. Also note differences between public/private
metadata from the client perspective.

- More thought and discussion needs to be put into the possibility of
issuer consolidation/centralization, and how it should be avoided.

# General feedback on draft charter:

- We need a more concrete description of the problem statement
	- Who are the intended issuers & redeemers?
	- Which parties make up an ecosystem?
	- What do the parties expect from each other?
	- Better terminology, replace "trust attestation" with something
	more accurate.

- Establish the context that we are scoping for throughout the charter
(e.g. application-layer, web-context).

- State explicit requirements of tokens with definitions, for example:
	- Unlinkability with respect to notion of anonymity set.
	- Unforgeability of tokens.
	- Client mechanism for verifying that Issuer is using a committed
	key.

- Potentially add some initial questions that should be answered before
we discuss the core deliverables of the WG, including:
	- Token transferability discussion.
	- What additional data is sent during token issuance and client
	redemptions?
	- How clients/consumers determine which issuers they trust, and
	under conditions they redeem tokens.
	- Auditing mechanisms for potentially malicious issuer behavior.
	- What is the potential for centralization, and strategies/WG
	commitment for mitigating against this.

- Is there a different way to structure the core deliverables beyond the
three documents that we currently have?

I think the points above are things that we can cover by reworking the
charter and as discussion points in the documentation. If there is
anything that has been missed (or any additional points that have not
been surfaced so far), please feel free to raise it.

Finally, there were questions (raised by Martin Thomson and others)
relating to investigating further how the client & intermediate
consumers decide that they trust certain issuers. For example, looking
into to the decision-making process under which clients hand over tokens
(for example, can client's check the size of their anonymity set?). It
also relates to the question of what information the clients trust to be
encoded in the information channel. These questions are important to
answer in their own right before we proceed with chartering, so I will
start a separate thread to start discussion on these points.

Thanks,
Alex

[1]: https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass <https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass>
[2]: https://www.ietf.org/jabber/logs/privacypass/2020-03-26.html <https://www.ietf.org/jabber/logs/privacypass/2020-03-26.html> 
[3]: https://datatracker.ietf.org/wg/rats/about/ <https://datatracker.ietf.org/wg/rats/about/>