Change:
single reference point for those implementing the protocol. Firstly, let U be the total number of users, I be the total number of <del> issuers.  Assuming that each user accept tokens from a uniform sampling of all the possible issuers, as a worst-case analysis, this segregates users into a total of 2^I buckets.  As such, we see an exponential reduction in the size of the anonymity set for any given user.  This allows us to specify the privacy constraints of the protocol below, relative to the setting of A. </del> <ins> issuers.  We let M be the total number of metadata bits that are allowed to be added by any given issuer.  Assuming that each user accept tokens from a uniform sampling of all the possible issuers, as a worst-case analysis, this segregates users into a total of 2^I buckets.  As such, we see an exponential reduction in the size of the anonymity set for any given user.  This allows us to specify the privacy constraints of the protocol below, relative to the setting of A. </ins> 8.1. We make the following assumptions in these parameter choices. Inferring the identity of a user in a 5000-strong anonymity set is <del> difficult </del> <ins> difficult. </ins> After 2 weeks, all clients in a system will have rotated to the <del> new key </del> <ins> new key. In terms of additional metadata, the only concrete applications of Privacy Pass that use additional metadata require just a single bit. Therefore, we set the ceiling of permitted metadata to 1 bit for now, this may be revisited in future revisions. </ins> <del> The maximum choice of I is based on the equation 1/2 * U/2^I = A. This is because I issuers lead to 2^I segregations of the total user- base U.  By reducing I we limit the possibility of performing the attacks mentioned in segregation. </del> <ins> The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. This is derived from the fact that permitting I issuers lead to 2^I segregations of the total user-base U.  Moreover, if we permit M = 1, then this effectively halves the anonymity set for each issuer, and thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in segregation. </ins> We must also account for each user holding issued data for more then one possible active keys.  While this may also be a vector for

Discussion:
Add allowances in protocol doc for redemption metadata Provide privacy analysis of including metadata to architecture doc Update privacy parametrizations cc NAME NAME NAME (I don't know everyone's github usernames, so feel free to add others who will be interested in reviewing).
LGTM
The main protocol document assumes that VOPRF is the main instantiation of PrivacyPass. It also has support for ciphersuites that augment this particular instantiation. It's not clear how we'd "extend" this protocol to support other features, such as public verifiability or the k-bits of metadata. These seem to be separate "modes" or "configurations" of PrivacyPass. (I don't think it makes sense to try and cast the metadata bit variant as a different ciphersuite for the main instantiation.) I propose we add some text describing different configurations. A configuration is an instantiation of the PrivacyPass API with certain properties. A configuration may (should?) also be extensible where applicable, e.g., in the ServerUpdate message or IssuanceRequest/Response messages. Interoperability across configurations would be unsupported, as they have would like have fundamentally different properties. Some initial configurations that come to mind are: PrivacyPass with no metadata bits (VOPRF construction) PrivacyPass with k metadata bits (Google's design) PrivacyPass with public verifiability (blind signatures?) cc NAME
Added some more information about supporting additional metadata in . As discussed elsewhere, I think the way to go here is for extensions to just specify new ciphersuites with associated privacy/security guarantees.
A number of applications expect the Servers to be able to add a small amount of metadata to the Privacy Pass protocol. We should add a discussion on how metadata should be added to tokens, and then describe the subsequent impact that this would have on the client's expected privacy budget. Generally speaking, adding a bit of metadata to tokens is likely to have a very similar impact to introducing an extra Issuer, and so this is something that will have to be covered in the general parametrization guidelines in the architecture document. Specific mechanisms for adding metadata to tokens are yet to be proposed, but may appear as alternative instantiations in the protocol document, or be specified separately as individual extensions.
LGTM. We’ll need to work through the extensibility support for the metadata bit variant next.