Change:
redemption tokens in storage and then stores the newly acquired tokens. <ins> 6.1.3. In draft-davidson-pp-protocol, it is permissible to add public and private metadata bits to redemption tokens.  While the core protocol instantiation that is described does not include additional metadata, future instantiations may use this functionality to provide redemption verifiers with additional information about the user. Note that any arbitrary bits of information can be used to further segment the size of the user's anonymity set.  Any issuer that wanted to track a single user could add a single metadata bit to user tokens.  For the tracked user it would set the bit to "1", and "0" otherwise.  Adding additional bits provides an exponential increase in tracking granularity similarly to introducing more issuers (though with more potential targeting). For this reason, the amount of metadata used by an issuer in creating redemption tokens must be taken into account together with the bits of information that issuer's may learn about clients from the means listed above.  We discuss this more in parametrization. </ins> 6.2. <del> While redemption tokens themselves encode no information about the client redeeming them, problems may occur if too many redemptions are allowed in a short burst.  For instance, in the Internet setting, this may allow non-terminating verifiers to learn more information from the metadata that the client may hold (such as first-party cookies for other domains).  Mitigations for this issue are similar to those proposed in issuers for tackling the problem of having large number of issuers. </del> <ins> Privacy losses may be encountered if too many redemptions are allowed in a short burst.  For instance, in the Internet setting, this may allow non-terminating verifiers to learn more information from the metadata that the client may hold (such as first-party cookies for other domains).  Mitigations for this issue are similar to those proposed in issuers for tackling the problem of having large number of issuers. </ins> In SIAV, cached SRRs and their associated issuer public keys have a similar tracking potential to first party cookies in the browser

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.