Change:
1. <del> The Privacy Pass protocol provides an anonymity-preserving mechanism for authorization of clients with servers.  The protocol is detailed in I-D.ietf-privacypass-protocol and is intended for use in the application-layer. The way that the ecosystem around the protocol is set up can have significant impacts on the stated privacy and security guarantees of the protocol.  For instance, the number of servers issuing Privacy Pass tokens, along with the number of registered clients, determines the anonymity set of each individual client.  Moreover, this can be influenced by other factors, such as: the key rotation policy used by each server; and, the number of supported ciphersuites.  There are also client behavior patterns that can reduce the effective security of the server. In this document, we will provide a structural framework for building the ecosystem around the Privacy Pass protocol.  The core of the document also includes policies for the following considerations. How server key material should be managed and accessed. Compatible server issuance and redemption running modes and associated expectations. How clients should evaluate server trust relationships. Security and privacy properties of the protocol. A concrete assessment and parametrization of the privacy budget associated with different settings of the above policies. The incorporation of potential extensions into the wider ecosystem. Finally, we will discuss existing applications that make use of the Privacy Pass protocol, and highlight how these may fit with the proposed framework. </del> <ins> Privacy Pass is a protocol for authorization based on anonymous- credential authentication mechanisms.  Typical approaches for authorizing clients, such as through the use of long-term cookies, are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state carrying information to servers, e.g., whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin authorization tokens that protect the client's anonymity during interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action, without having to reauthenticate manually.  The tokens retain anonymity in the sense that the act of revealing them cannot be linked back to the session where they were initially issued. At a high level, Privacy Pass is composed of two protocols: issuance and redemption. The issuance protocol runs between a Client and two network functions in the Privacy Pass architecture: Attestation and Issuance.  These two network functions can be implemented by the same protocol participant, but can also be implemented separately.  The Issuer is responsible for issuing tokens in response to requests from Clients. The Attester is responsible for attesting properties about the Client for which tokens are issued.  The Issuer needs to be trusted by the server that later redeems the token.  Attestation can be performed by the Issuer or by an Attester that is trusted by the Issuer.  Clients might prefer to select different Attesters, separate from the Issuer, to be able to use preferred authentication methods or improve privacy by not directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an Issuance protocol, in the original Privacy Pass protocol PPSRV, tokens were only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact. The redemption protocol runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for authorization.  Depending on the type of token, e.g., whether or not it is cross-origin or per-origin, and whether or not it can be cached, the Client either presents a previously obtained token or invokes the issuance protocol to acquire one for authorization. The issuance and redemption protocols operate in concert as shown in the figure below. This document describes requirements for both issuance and redemption protocols.  This document also describes ecosystem considerations that impact the stated privacy and security guarantees of the protocol. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> The following terms are used throughout this document. <del> Server: An entity that issues anonymous tokens to clients.  In symmetric verification cases, the server must also verify tokens. Also referred to as the server. </del> <ins> Client: An entity that seeks authorization to an Origin. </ins> <del> Client: An entity that seeks authorization from a server. </del> <ins> Origin: An entity that challenges Clients for tokens. </ins> <del> We assume that all protocol messages are encoded into raw byte format before being sent.  We use the TLS presentation language RFC8446 to describe the structure of the data that is communicated and stored. </del> <ins> Issuer: An entity that issues tokens to Clients for properties attested to by the Attester. </ins> <del> 3. </del> <ins> Attester: An entity that attests to properties of Client for the purposes of token issuance. </ins> <del> The Privacy Pass ecosystem refers to the global framework in which multiple instances of the Privacy Pass protocol operate.  This refers to all servers that support the protocol, or any extension of it, along with all of the clients that may interact with these servers. The ecosystem itself, and the way it is constructed, is critical for evaluating the privacy of each individual client.  We assume that a client's privacy refers to fraction of users that it represents in the anonymity set that it belongs to.  We discuss this more in privacy. In the above diagram, the arrows indicate the open channels between a client and a server.  An open channel indicates that a client accepts Privacy Pass tokens from this server. </del> <ins> 3. </ins> <del> If no channel exists, this means that the client chooses not to accept tokens from (or redeem tokens with) that particular server. We discuss the roles of servers and clients further in ecosystem- servers and ecosystem-clients, respectively. </del> <ins> The Privacy Pass architecture consists of four logical entities - Client, Origin, Issuer, and Attester - that work in concert as shown in introduction for token issuance and redemption.  This section describes the purpose of token issuance and redemption and the requirements therein on the relevant participants. </ins> 3.1. <del> Generally, servers in the Privacy Pass ecosystem are entities whose primary function is to undertake the role of the "server" in I- D.ietf-privacypass-protocol.  To facilitate this, the server MUST hold a Privacy Pass protocol keypair at any given time.  The server public key MUST be made available to all clients in such a way that key rotations and other updates are publicly visible.  The server MAY also require additional state for ensuring this.  We provide a wider discussion in key-mgmt. Note that, in the core protocol instantiation from I-D.ietf- privacypass-protocol, the redemption phase is a symmetric protocol. This means that the server is the same server that ultimately processes token redemptions from clients.  However, plausible extensions to the protocol specification may allow public verification of tokens by entities which do not hold the secret Privacy Pass keying material.  We highlight possible client and server configurations in running-modes. The server must be uniquely identifiable by all clients with a consistent identifier. </del> <ins> The redemption protocol is a simple challenge-response based authorization protocol between Client and Origin.  Origins prompt Clients with a token challenge and, if possible, Clients present a valid token for the challenge in response.  The challenge controls the type of token that the Origin will accept for the given resource. As described in [http-auth-doc], there are a number of ways in which the token may vary, including: Issuance protocol.  The token identifies the type of issuance protocol required for producing the token.  Different issuance protocols have different security properties, e.g., some issuance protocols may produce tokens that are publicly verifiable, whereas others may not have this property. Issuer identity.  Tokens identify which issuers are trusted for a given issuance protocol. Interactive or non-interactive.  Tokens can either be interactive or not.  An interactive token is one which requires a freshly issued token based on the challenge, whereas a non-interactive token can be issued proactively and cached for future use. Per-domain or cross-domain.  Tokens can be constrained to the Origin for which the challenge originated, or can be used across Origins. Depending on the use case, Origins may need to maintain state to track redeemed tokens.  For example, Origins that accept non- interactive, cross-origin tokens SHOULD track which tokens have been redeemed already, since these tokens can be issued and then spent multiple times in response to any such challenge.  See double-spend for discussion. Origins that admit cross-origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with another Origin.  If tokens protected with resources are unique to a single Origin, then said Origin MUST NOT admit cross-origin tokens for authorization. </ins> 3.2. <del> Clients in the Privacy Pass ecosystem are entities whose primary function is to undertake the role of the "Client" in I-D.ietf- privacypass-protocol.  Clients are assumed to only store data related to the tokens that it has been issued by the server.  This storage is used for constructing redemption requests. Clients MAY choose not to accept tokens from servers that they do not trust.  See client-server for a wider discussion. </del> <ins> The issuance protocol embodies the core of Privacy Pass.  It takes as input a challenge from the redemption protocol and produces a token, as shown in the figure below. Each issuance protocol may be different, e.g., in the number and types of participants, underlying cryptographic constructions used when issuing tokens, and even privacy properties. Clients initiate the Token issuance protocol using the challenge, a randomly generated nonce, and public key for the Issuer.  The Token issuance protocol itself can be any interactive protocol between Client, Issuer, or other parties that produces a valid authenticator over the Client's input, subject to the following security requirements. Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the challenge and nonce.  The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the issuance protocol.  A result of this property is that the redemption flow is unlinkable from the issuance flow. One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients to forge tokens without interacting with the Issuer directly. Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients. Each Issuance protocol MUST come with a detailed analysis of the privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization. The mechanism by which clients obtain the Issuer public key is not specified.  Clients may be configured with this key or they may discover it via some other form.  See CONSISTENCY. Depending on the use case, issuance may require some form of Client anonymization service similar to an IP-hiding proxy so that Issuers cannot learn information about Clients.  This can be provided by an explicit participant in the issuance protocol, or it can be provided via external means, e.g., through the use of an IP-hiding proxy service like Tor. In general, Clients SHOULD minimize or remove identifying information where possible when invoking the issuance protocol. Issuers MUST NOT issue tokens for Clients through untrusted Attesters.  This is important because the Attester's role is to vouch for trust in privacy-sensitive Client information, such as account identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See attester-role for more details. </ins> 3.2.1. <del> Privacy properties of this protocol do not take into account other possibly identifying information available in an implementation, such as a client's IP address.  Servers which monitor IP addresses may use this to track client redemption patterns over time.  Clients cannot check whether servers monitor such identifying information.  Thus, clients SHOULD minimize or remove identifying information where possible, e.g., by using anonymity-preserving tools such as Tor to interact with servers. 4. The key material and protocol configuration that a server uses to issue tokens corresponds to a number of different pieces of information. The ciphersuite that the server is using. The public keys that are active for the server. The way that the server publishes and maintains this information </del> <ins> Attestation is an important part of the issuance protocol. Attestation is the process by which an Attester bears witness to, confirms, or authenticates a Client so as to verify a property about the Client that is required for Issuance.  Examples of attestation properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA challenges can attest to this capability for the purposes of being ruled out as a bot or otherwise automated Client. Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the number of issuance protocol invocations, the client's geographic region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements. Each of these attestation types have different security properties. For example, attesting to having a valid account is different from attesting to be running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats. Each attestation format also has an impact on the overall system privacy.  For example, the number of users in possession of a single class of trusted device might be lesser than the number of users that can solve CAPTCHAs.  Similarly, requiring a conjunction of attestation types could decrease the overall anonymity set size.  For example, the number of Clients that have solved a CAPTCHA in the past day, have a valid account, and are running on a trusted device is lesser than the number of Clients that have solved a CAPTCHA in the past day.  Attesters should not admit attestation types that result in small anonymity sets. 3.2.2. Issuers MUST be uniquely identifiable by all Clients with a consistent identifier.  In a web context, this identifier might be the Issuer host name.  As discussed later in privacy, ecosystems that admit a large number of Issuers can lead to privacy concerns for the Clients in the ecosystem.  Therefore, in practice, the number of Issuers should be bounded.  The actual Issuers can be replaced with different Issuers as long as the total never exceeds these bounds. Moreover, Issuer 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 Issuers. 3.2.2.1. To facilitate issuance, the Issuer MUST hold an Issuance key pair at any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that an Issuer uses to produce tokens corresponds to a number of different pieces of information. The issuance protocol in use; and The public keys that are active for the Issuer. The way that the Issuer publishes and maintains this information </ins> impacts the effective privacy of the clients; see privacy for more details.  The fundamental requirement for key management and <del> discovery is that servers must be unable to target specific clients </del> <ins> discovery is that Issuers must be unable to target specific clients </ins> with unique keys without detection.  There are a number of ways in which this might be implemented:

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!