Change:
See parametrization for guidelines on what frequency of key rotations are permitted. <del> 4.2. Since a server is only permitted to have a single active issuing key, this implies that only a single ciphersuite is allowed per issuance period.  If a server wishes to change their ciphersuite, they MUST do so during a key rotation. </del> <ins> 3.2.3. </ins> <del> 5. We provide an overview of some of the possible frameworks for configuring the way that servers run in the Privacy Pass ecosystem. In short, servers may be configured to provide symmetric issuance and redemption with clients.  While some servers may be configured as proxies that accept Privacy Pass data and send it to another server that actually processes issuance or redemption data.  Finally, we also consider instances of the protocol that may permit public verification. The intention with providing each of these running modes is to cover the different applications that utilize variants of the Privacy Pass protocol.  We RECOMMEND that any Privacy Pass server implementation adheres to one of these frameworks. 5.1. The simplest way of considering the Privacy Pass protocol is in a setting where the same server plays the role of server and verifier, we call this "Single-Verifier" (SV). Let S be the server, and C be the client.  When S wants to issue tokens to C, they invoke the issuance protocol where C generates their own inputs, and S uses their secret key skS.  In this setting, C can only perform token redemption with S.  When a token redemption is required, C and S invoke the redemption phase of the protocol, where C uses an issued token from a previous exchange, and S uses skS to validate the redemption. 5.2. In this setting, each client C obtains issued tokens from a derver S via the issuance phase of the protocol.  The difference is that C can prove that they hold a valid authorization with any verifier V.  We still only consider S to hold their own secret key.  We name this mode "Delegated-Verifier" (DV). When C interacts with V, V can ask C to provide proof of authorization to the separate server S.  The first stage of the redemption phase of the protocol is invoked between C and V, which sees C send an unused redemption token to V.  This message is then used in a redemption exchange between V and S, where V plays the role of the Client.  Then S sends the result of the redemption verification to V, and V uses this result to determine whether C has a valid token. 5.3. This setting is inspired by recently proposed APIs such as TrustTokenAPI.  It is similar to the DV configuration, except that the verifiers V no longer interact with the server S.  Only C interacts with S, and this is done asynchronously to the authorization request from V.  Hence "Asynchronous-Verifier" (AV). When V invokes a redemption for C, C then invokes a redemption exchange with S in a separate session.  If verification is carried out successfully by S, S instead returns a Signed Redemption Record (SRR) that contains the following information: The "signature" field carries a signature evaluated over the contents of "result" using a long-term signing key for the server S, of which the corresponding public key is well-known to C and V.  This would need to be published alongside other public key data for S.  Then C can prove that they hold a valid authorization from S to V by sending the SRR to V.  The SRR can be verified by V by verifying the signature, using the well-known public key for S. Such records can be cached to display again in the future.  The server can also add an expiry date to the record to determine when the client must refresh the record. 5.4. We consider the case where client redemptions can be verified publicly using the server public key.  This allows for defining extensions of Privacy Pass that use public-key cryptography to allow public verification. In this case, the client C obtains a redemption token from S.  The redemption token is publicly verifiable in the sense that any entity that knows the public key for S can verify the token.  This running mode is known as "Public-Verifier" (PV). 5.5. Each of the configurations above can be generalized to settings where a bounded number of servers are allowed, and verifiers can invoke authorization verification for any of the available servers. As we will discuss later in privacy, configuring a large number of servers can lead to privacy concerns for the clients in the ecosystem.  Therefore, we are careful to ensure that the number of servers is kept strictly bounded.  The actual servers can be replaced with different servers as long as the total never exceeds this bound. Moreover, server replacements also have an effect on client anonymity that is similar to when a key rotation occurs. See privacy for more details about maintaining privacy with multiple servers. 6. Certain instantiations of Privacy Pass may permit public or private metadata to be cryptographically bound to a token.  As an example, one trivial way to include public metadata is to assign a unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits.  See parametrization for discussion about metadata limits. </del> <ins> Certain instantiations of the issuance protocol may permit public or private metadata to be cryptographically bound to a token.  As an example, one trivial way to include public metadata is to assign a unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits. See parametrization for discussion about metadata limits. </ins> Public metadata is that which clients can observe as part of the token issuance flow.  Public metadata can either be transparent or opaque.  For example, transparent public metadata is a value that the <del> client either generates itself, or the server provides during the </del> <ins> client either generates itself, or the Issuer provides during the </ins> issuance flow and the client can check for correctness.  Opaque public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a <del> "fraud detection signal", computed on behalf of the server, during </del> <ins> "fraud detection signal", computed on behalf of the Issuer, during </ins> token issuance.  In normal circumstances, clients cannot determine if this value is correct or otherwise a tracking vector. Private metadata is that which clients cannot observe as part of the <del> token issuance flow.  In I-D.ietf-privacypass-protocol, it is possible to include private metadata to redemption tokens.  The core protocol instantiation that is described does not include additional metadata.  However, future instantiations may use this functionality to provide redemption verifiers with additional information about the user.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21. </del> <ins> token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21. </ins> Metadata may also be arbitrarily long or bounded in length.  The amount of permitted metadata may be determined by application or by the underlying cryptographic protocol. <del> 6.1. </del> <ins> 3.2.4. </ins> <del> Note that any metadata bits of information can be used to further segment the size of the user's anonymity set.  Any server 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" </del> <ins> The Privacy Pass protocol and ecosystem are both intended to be receptive to extensions that expand the current set of functionalities through new issuance protocols.  Each issuance protocol SHOULD come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on changes to the parametrization in parametrization.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. 4. The goal of the Privacy Pass ecosystem is to construct an environment that can easily measure and maximize the relative anonymity of any Client that is part of it.  An inherent feature of being part of this ecosystem is that any Client can only remain private relative to the entire space of users using the protocol.  Moreover, by owning tokens for a given set of keys, the Client's anonymity set shrinks to the total number of clients controlling tokens for the same keys. In the following, we consider the possible ways that Issuers can leverage their position to try and reduce the anonymity sets that Clients belong to (or, user segregation).  For each case, we provide mitigations that the Privacy Pass ecosystem must implement to prevent these actions. 4.1. Any metadata bits of information can be used to further segment the size of the Client's anonymity set.  Any Issuer that wanted to track a single Client could add a single metadata bit to Client tokens. For the tracked Client it would set the bit to "1", and "0" </ins> otherwise.  Adding additional bits provides an exponential increase <del> in tracking granularity similarly to introducing more servers (though </del> <ins> in tracking granularity similarly to introducing more Issuers (though </ins> with more potential targeting). <del> For this reason, the amount of metadata used by an server in creating </del> <ins> For this reason, the amount of metadata used by an Issuer in creating </ins> redemption tokens must be taken into account - together with the bits <del> of information that server's may learn about clients otherwise. </del> <ins> of information that Issuer's may learn about Clients otherwise. </ins> Since this metadata may be useful for practical deployments of <del> Privacy Pass, servers must balance this against the reduction in client privacy.  In general, servers should permit no more than 32 </del> <ins> Privacy Pass, Issuers must balance this against the reduction in Client privacy.  In general, Issuers should permit no more than 32 </ins> bits of metadata, as this can uniquely identify each possible user. We discuss this more in parametrization. <del> 7. It is important, based on the architecture above, that any client can determine whether it would like to interact with a given server in the ecosystem.  Note that this decision must be taken before a client issues a valid redemption to the server, since redemptions reveal the anonymity set that the client belongs to. This judgement can be based on a multitude of factors, associated with the way that a server presents itself in the ecosystem.  A non- exhaustive list of server characteristics that a client MAY want to check are the following. Which key registry a server posts their key updates to. How frequent key updates are issued, and which ciphersuite they use. The reason given to initiate the redemption. To aid client trust decisions, a server can publish a "Privacy Pass policy" that documents the procedures that the server uses to ensure that client privacy is respected.  If a server does not publish such a document then the client may choose to use its own judgement, or to reject the server altogether. It should be noted that the client trust decision can be made apriori by specifying an allow-list of all servers that it accepts tokens from.  This means that these checks do not have to be performed online. 8. In the Privacy Pass protocol I-D.ietf-privacypass-protocol, redemption tokens intentionally encode very little information beyond which key was used to sign them.  The protocol intentionally uses components that provide cryptographic guarantees of this fact. However, even with these guarantees, the way that the ecosystem is constructed can be used to identify clients based on this limited information. The goal of the Privacy Pass ecosystem is to construct an environment that can easily measure (and maximize) the relative anonymity of any client that is part of it.  An inherent feature of being part of this ecosystem is that any client can only remain private relative to the entire space of users using the protocol.  Moreover, by owning tokens for a given set of keys, the client's anonymity set shrinks to the total number of clients controlling tokens for the same keys. </del> <ins> 4.2. </ins> <del> In the following, we consider the possible ways that servers and servers can leverage their position to try and reduce the anonymity sets that clients belong to (or, user segregation).  For each case, we provide mitigations that the Privacy Pass ecosystem must implement to prevent these actions. 8.1. Techniques to introduce client "segregation" can be used to reduce client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the server.  When a server rotates their key, any client that invokes the issuance protocol in this key cycle will be part of a group of possible clients owning valid tokens for this key.  To mechanize this attack strategy, a server could introduce a key rotation policy that forces clients into small key </del> <ins> Techniques to introduce Client "segregation" can be used to reduce Client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the Issuer.  When an Issuer rotates their key, any Client that invokes the issuance protocol in this key cycle will be part of a group of possible clients owning valid tokens for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key </ins> cycles.  Thus, reducing the size of the anonymity set for these <del> clients. We RECOMMEND that servers should only invoke key rotation for fairly large periods of time such as between 1 and 12 weeks.  Key rotations represent a trade-off between client privacy and continued server security.  Therefore, it is still important that key rotations occur on a fairly regular cycle to reduce the harmfulness of a server key compromise. With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key, and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. 8.2. Similarly to the server rotation dynamic that is raised above, if there are a large number of servers then segregation can occur.  In the FV, AV and PV running modes (running-modes), a verifier OV can trigger redemptions for any of the available servers.  Each redemption token that a client holds essentially corresponds to a bit of information about the client that OV can learn.  Therefore, there is an exponential loss in anonymity relative to the number of servers </del> <ins> Clients. Issuers SHOULD invoke key rotation for a period of time between 1 and 12 weeks.  Key rotations represent a trade-off between Client privacy and continued Issuer security.  Therefore, it is still important that key rotations occur on a regular cycle to reduce the harmfulness of an Issuer key compromise. With a large number of Clients, a minimum of one week gives a large enough window for Clients to participate in the issuance protocol and thus enjoy the anonymity guarantees of being part of a larger group. A maximum of 12 weeks limits the damage caused by a key compromise. If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients. If possible, it should invoke any revocation procedures that may apply for the old key. 4.3. Similarly to the Issuer rotation dynamic that is raised above, if there are a large number of Issuers and Origins accept all of them segregation can occur.  For example, if Clients obtain tokens from many Issuers, and Origins later challenge a Client for a token from each Issuer, Origins can learn information about the Client.  Each per-Issuer token that a Client holds essentially corresponds to a bit of information about the Client that Origin learn.  Therefore, there is an exponential loss in anonymity relative to the number of Issuers </ins> that there are. <del> For example, if there are 32 servers, then OV learns 32 bits of information about the client.  If the distribution of server trust is </del> <ins> For example, if there are 32 Issuers, then Origins learns 32 bits of information about the Client.  If the distribution of Issuer trust is </ins> anything close to a uniform distribution, then this is likely to <del> uniquely identify any client amongst all other Internet users. </del> <ins> uniquely identify any Client amongst all other Internet users. </ins> Assuming a uniform distribution is clearly the worst-case scenario, and unlikely to be accurate, but it provides a stark warning against <del> allowing too many servers at any one time. </del> <ins> allowing too many Issuers at any one time. </ins> <del> In cases where clients can hold tokens for all servers at any given </del> <ins> In cases where clients can hold tokens for all Issuers at any given </ins> time, a strict bound SHOULD be applied to the active number of <del> servers in the ecosystem.  We propose that allowing no more than 4 servers at any one time is highly preferable (leading to a maximum of </del> <ins> Issuers in the ecosystem.  We propose that allowing no more than 4 Issuers at any one time is highly preferable (leading to a maximum of </ins> 64 possible user segregations).  However, as highlighted in parametrization, having a very large user base (> 5 million users), <del> could potentially allow for larger values. server replacements should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active servers. </del> <ins> could potentially allow for larger values.  Issuer replacements should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active Issuers. </ins> In addition, we RECOMMEND that trusted registries indicate at all <del> times which servers are deemed to be active.  If a client is asked to invoke any Privacy Pass exchange for an server that is not declared active, then the client SHOULD refuse to retrieve the server configuration during the protocol. </del> <ins> times which Issuers are deemed to be active.  If a Client is asked to invoke any Privacy Pass exchange for an Issuer that is not declared active, then the client SHOULD refuse to retrieve the Issuer public key during the protocol. </ins> <del> 8.2.1. </del> <ins> 4.3.1. </ins> <del> The bounds on the numbers of servers that we proposed above are very restrictive.  This is due to the fact that we considered a situation where a client could be issued (and forced to redeem) tokens for any issuing key. </del> <ins> The bounds on the numbers of Issuers that this document proposes above are very restrictive.  This is due to the fact that this document considers a situation where a Client could be issued (and forced to redeem) tokens for any Issuer. </ins> An alternative system is to ensure a robust strategy for ensuring <del> that clients only possess redemption tokens for a similarly small number of servers at any one time.  This prevents a malicious verifier from being able to invoke redemptions for many servers since the client would only be holding redemption tokens for a small set of servers.  When a client is issued tokens from a new server and already has tokens from the maximum number of servers, it simply </del> <ins> that Clients only possess redemption tokens for a similarly small number of Issuers at any one time.  This prevents a malicious verifier from being able to invoke redemptions for many Issuers since the Client would only be holding redemption tokens for a small set of Issuers.  When a Client is issued tokens from a new Issuer and already has tokens from the maximum number of Issuers, it simply </ins> deletes the oldest set of redemption tokens in storage and then stores the newly acquired tokens. <del> For example, if clients ensure that they only hold redemption tokens for 4 servers, then this increases the potential size of the anonymity sets that the client belongs to.  However, this doesn't protect clients completely as it would if only 4 servers were permitted across the whole system.  For example, these 4 servers could be different for each client.  Therefore, the selection of servers they possess tokens for is still revealing.  Understanding </del> <ins> For example, if Clients ensure that they only hold redemption tokens for 4 Issuers, then this increases the potential size of the anonymity sets that the Client belongs to.  However, this doesn't protect Clients completely as it would if only 4 Issuers were permitted across the whole system.  For example, these 4 Issuers could be different for each Client.  Therefore, the selection of Issuers they possess tokens for is still revealing.  Understanding </ins> this trade-off is important in deciding the effective anonymity of <del> each client in the system. </del> <ins> each Client in the system. </ins> <del> 8.2.1.1. </del> <ins> 4.3.1.1. </ins> <del> Another option to allow a large number of servers in the ecosystem, </del> <ins> Another option to allow a large number of Issuers in the ecosystem, </ins> while preventing the joining of a number of different tokens is for <del> the client to maintain sharded "redemption contexts".  This would allow the client to redeem the tokens it wishes to use in a particular context, while still allowing the client to maintain a large variety of tokens from many servers.  Within a redemption context, the client limits the number of different servers used to a small number to maintain the privacy properties the client requires. </del> <ins> the Client to maintain sharded "redemption contexts".  This would allow the Client to redeem the tokens it wishes to use in a particular context, while still allowing the Client to maintain a large variety of tokens from many Issuers.  Within a redemption context, the Client limits the number of different Issuers used to a small number to maintain the privacy properties the Client requires. </ins> As long as each redemption context maintains a strong privacy boundary with each other, the verifier will only be able to learn a number of bits of information up to the limits within that "redemption context". To support this strategy, the client keeps track of a "context" which <del> contains the set of servers that redemptions have been attempted </del> <ins> contains the set of Issuers that redemptions have been attempted </ins> against.  An empty redemption is returned when the limit has been hit: <del> 8.3. </del> <ins> 4.4. </ins> If there are multiple key registries, or if a key registry colludes <del> with an server, then it is possible to provide a split-view of an server's key material to different clients.  This would involve </del> <ins> with an Issuer, then it is possible to provide a split-view of an Issuer's key material to different Clients.  This would involve </ins> posting different key material in different locations, or actively modifying the key material at a given location. <del> Key registries should operate independently of server's in the ecosystem, and within the guidelines stated in key-mgmt.  Any client should follow the recommendations in client-server for determining whether an server and its key material should be trusted. </del> <ins> Key registries should operate independently of Issuers in the ecosystem, and within the guidelines stated in issuer-role.  Any Client should follow the recommendations in privacy for determining whether an Issuer and its key material should be trusted. </ins> <del> 8.4. </del> <ins> 4.5. </ins> Privacy losses may be encountered if too many redemptions are allowed in a short burst.  For instance, in the Internet setting, this may <del> allow delegated or asynchronous 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 servers for tackling the problem of having large number of servers. In AV, cached SRRs and their associated server public keys have a similar tracking potential to first party cookies in the browser setting.  These considerations will be covered in a separate document, detailing Privacy Pass protocol integration into the wider web architecture I-D.ietf-privacypass-http-api. </del> <ins> allow Origins to learn more information from the metadata that the Client may hold (such as first-party cookies for other origins). Mitigations for this issue are similar to those proposed in servers for tackling the problem of having large number of Issuers. </ins> <del> 8.5. </del> <ins> 4.6. </ins> Clients may see an incentive in accepting all tokens that are issued <del> by a server, even if the tokens fail later verification checks.  This is because tokens effectively represent a form of currency that they can later redeem for some sort of benefit.  The verification checks that are put in place are there to ensure that the client does not sacrifice their anonymity.  However, a client may judge the </del> <ins> by an Issuer, even if the tokens fail later verification checks. This is because tokens effectively represent a form of currency that they can later redeem for some sort of benefit.  The verification checks that are put in place are there to ensure that the Client does not sacrifice their anonymity.  However, a Client may judge the </ins> "monetary" benefit of owning tokens to be greater than their own privacy. <del> Firstly, a client behaving in this way would not be compliant with </del> <ins> Firstly, a Client behaving in this way would not be compliant with </ins> the protocol, as laid out in I-D.ietf-privacypass-protocol. Secondly, acting in this way only affects the privacy of the <del> immediate client.  There is an exception if a large number of clients colluded to accept bad data, then any client that didn't accept would </del> <ins> immediate Client.  There is an exception if a large number of Clients colluded to accept bad data, then any Client that didn't accept would </ins> be part of a smaller anonymity set.  However, such a situation would <del> be identical to the situation where the total number of clients in </del> <ins> be identical to the situation where the total number of Clients in </ins> the ecosystem is small.  Therefore, the reduction in the size of the anonymity set would be equivalent; see servers for more details. <del> 9. </del> <ins> 5. </ins> We present a number of security considerations that prevent malicious <del> clients from abusing the protocol. </del> <ins> Clients from abusing the protocol. </ins> <del> 9.1. </del> <ins> 5.1. </ins> <del> All issuing server should implement a robust storage-query mechanism for checking that tokens sent by clients have not been spent before. Such tokens only need to be checked for each server individually. But all servers must perform global double-spend checks to avoid clients from exploiting the possibility of spending tokens more than once against distributed token checking systems.  For the same reason, the global data storage must have quick update times.  While an update is occurring it may be possible for a malicious client to spend a token more than once. </del> <ins> When applicable for non-interactive tokens, all Origins SHOULD implement a robust storage-query mechanism for checking that tokens sent by clients have not been spent before.  Such tokens only need to be checked for each Origin individually.  But all Origins must perform global double-spend checks to avoid clients from exploiting the possibility of spending tokens more than once against distributed token checking systems.  For the same reason, the global data storage must have quick update times.  While an update is occurring it may be possible for a malicious client to spend a token more than once. </ins> <del> 9.2. </del> <ins> 5.2. </ins> <del> When a client holds tokens for an server, it is possible for any verifier to invoke that client to redeem tokens for that server. </del> <ins> When a Client holds tokens for an Issuer, it is possible for any verifier to invoke that client to redeem tokens for that Issuer. </ins> This can lead to an attack where a malicious verifier can force a <del> client to spend all of their tokens for a given server.  To prevent this from happening, methods should be put into place to prevent many tokens from being redeemed at once. For example, it may be possible to cache a redemption for the entity that is invoking a token redemption.  If the verifier requests more tokens then the client simply returns the cached token that it returned previously.  This could also be handled by simply not redeeming any tokens for verification if a redemption had already </del> <ins> Client to spend all of their tokens from a given Issuer.  To prevent this from happening, tokens can be scoped to single Origins such that they can only be redeemed within for a single Origin. If tokens are cross-Origin, Clients should use alternate methods to prevent many tokens from being redeemed at once.  For example, if the Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already </ins> occurred in a given time window. <del> In AV, the client instead caches the SRR that it received in the asynchronous redemption exchange with the server.  If the same verifier attempts another redemption request, then the client simply returns the cached SRR.  The SRRs can be revoked by the server, if need be, by providing an expiry date or by signaling that records from a particular window need to be refreshed. 9.3. [[OPEN ISSUE: explain potential and mitigations for server centralization]] 10. We provide a summary of the parameters that we use in the Privacy Pass protocol ecosystem.  These parameters are informed by both privacy and security considerations that are highlighted in privacy and security, respectively.  These parameters are intended as a single reference point for those implementing the protocol. </del> <ins> 6. </ins> <del> Firstly, let U be the total number of users, I be the total number of servers.  We let M be the total number of metadata bits that are allowed to be added by any given server.  Assuming that each user accept tokens from a uniform sampling of all the possible servers, 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> This section provides a summary of the parameters that used in the Privacy Pass protocol ecosystem.  These parameters are informed by both privacy and security considerations that are highlighted in privacy and security, respectively.  These parameters are intended as a single reference point for those implementing the protocol. Firstly, let U be the total number of Clients (or users), I be the total number of 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 Clients 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> <del> 10.1. </del> <ins> 6.1. </ins> We make the following assumptions in these parameter choices. Inferring the identity of a user in a 5000-strong anonymity set is difficult. <del> After 2 weeks, all clients in a system will have rotated to the </del> <ins> After 2 weeks, all Clients in a system will have rotated to the </ins> new key. In terms of additional metadata, the only concrete applications of

Discussion:
This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients, Mediators, Issuers, and Origins. First draft, so there may be things we want to rephrase or reflow. Rendered view of this PR .
Whitespace errors?
NAME fixed!
Merging this per the discussion during the interim meeting today.
A few comments; thanks for the quick turnaround!