Change:
The public keys that are active for the server. <del> For reasons that we address later in privacy, the way that the server publishes and maintains this information impacts the effective privacy of the clients.  In this section, we describe the main policies that need to be satisfied for a key management system in a Privacy Pass ecosystem. </del> <ins> The way that the server publishes and maintains this information impacts the effective privacy of the clients; see privacy for more details.  The fundamental requirement for key management and discovery is that servers must be unable to target specific clients with unique keys without detection.  There are a number of ways in which this might be implemented: </ins> <del> Note that we only specify a set of guidelines and recommendations for operating a public key registry in this document.  Actual specification of such a registry and how it operates will be covered elsewhere. </del> <ins> Servers use a verifiable, tamper-free registry from which clients discover keys.  Similar to related mechanisms and protocols such as Certificate Transparency RFC6962, this may require external auditors or additional client behavior to ensure the registry state is consistent for all clients. </ins> <del> 4.1. </del> <ins> Clients use an anonymity-preserving tool such as Tor to discover keys from multiple network vantage points.  This is done to ensure consistent keys to seemingly different clients. </ins> <del> Server's must provide their public keys to clients along with details about the cryptographic ciphersuite that they are using.  In privacy, we address the importance of providing clients with sources of truth for learning the server's key configuration. In particular, server key material MUST be publicly available in a tamper-proof data structure, which we refer to as a key registry.  A registry must be globally consistent.  Clients using the same registry should coordinate in some way to ensure they have a consistent view of said registry.  This can be done via gossiping or some other mechanism.  The exact mechanism for this coordination will be described elsewhere.  It is assumed there will be at least one such mechanism. It is RECOMMENDED that each key registry is an append-only data structure, such as a Merkle Tree.  The key registry should be operated independently of any server that publishes key material to the registry.  This ensures that any client can make better judgements on whether to trust the registry and, transitively, each server. While there may be multiple key registries for a given ecosystem, a server MUST only publish its key material to a single registry.  This ensures that the server is keeping a consistent view of its key material. </del> <ins> Clients embed server keys into software. </ins> <del> 4.2. </del> <ins> Specific mechanisms for key management and discovery are out of scope for this document. 4.1. </ins> Token issuance associates all issued tokens with a particular choice of key.  If a server issues tokens with many keys, then this may harm

Discussion:
Replace suggested registry with list of other options. The rationale is that a registry may be sufficient but not necessary. There are other options that might work. I suggest we work with NAME on a draft describing these techniques in more detail. cc NAME
There's currently no text around token expiration. Minimally, we could say that tokens expire when issuer (and verifier) keys rotate. Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens? For example, one might imagine using PMB-like constructions to encode an expiration "epoch" into the metadata bits. The single metadata bit variant would allow two epochs that way. NAME NAME what do you think?
I'm not sure what baking the expiry into the tokens gives that can't be managed by rotating the issuer/verifier keys (or using public metadata (which is effectively the key used to sign))? That way issuers that care about more fine grained token expiration use the key rotation for that and issuers that only care about coarse token expiration use it for other metadata, allowing the protocol to treat both in the same way?
Yeah, I think the only two options are (a) rotate keys or (b) include the expiry information as public metadata (and need not be tied to the key used to sign). I'm not advocating for one or the other. Sure, that's reasonable. We should probably have text on this point. (That's partly why I filed this issue.)
We should also make sure to note that the validity window does narrow the anonymity set.
This LGTM. Agreed that working on a document that tackles these questions specifically would be worthwhile.