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>  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>  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>  <del> Client: An entity that seeks authorization from a server. </del>  <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>  <del> 3. </del>  <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>  <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>  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>  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>  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>  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>  with unique keys without detection.  There are a number of ways in which this might be implemented: keys from multiple network vantage points.  This is done to ensure consistent keys to seemingly different clients. <del> Clients embed server keys into software. </del>  <del> Specific mechanisms for key management and discovery are out of scope for this document. </del>  <del> 4.1. </del>  Token issuance associates all issued tokens with a particular choice <del> of key.  If a server issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. </del>  <del> To prevent against this, servers MUST only use one private key for </del>  issuing tokens at any given time.  Servers MAY use one or more keys <del> for redemption to allow servers for seamless key rotation. </del>  Servers may rotate keys as a means of revoking tokens issued under <del> old or otherwise expired keys.  Alternatively, servers may include </del>  expiration information as metadata alongside the token; See metadata <del> for more discussion about metadata constraints.  Both techinques are </del>  equivalent since they cryptographically bind expiration to individual tokens. 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>  <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>  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>  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>  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>  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>  <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>  otherwise.  Adding additional bits provides an exponential increase <del> in tracking granularity similarly to introducing more servers (though </del>  with more potential targeting). <del> For this reason, the amount of metadata used by an server in creating </del>  redemption tokens must be taken into account - together with the bits <del> of information that server's may learn about clients otherwise. </del>  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>  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>  <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>  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>  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>  anything close to a uniform distribution, then this is likely to <del> uniquely identify any client amongst all other Internet users. </del>  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>  <del> In cases where clients can hold tokens for all servers at any given </del>  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>  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>  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>  <del> 8.2.1. </del>  <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>  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>  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>  this trade-off is important in deciding the effective anonymity of <del> each client in the system. </del>  <del> 8.2.1.1. </del>  <del> Another option to allow a large number of servers in the ecosystem, </del>  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>  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>  against.  An empty redemption is returned when the limit has been hit: <del> 8.3. </del>  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>  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>  <del> 8.4. </del>  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>  <del> 8.5. </del>  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>  "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>  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>  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>  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>  We present a number of security considerations that prevent malicious <del> clients from abusing the protocol. </del>  <del> 9.1. </del>  <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>  <del> 9.2. </del>  <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>  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>  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>  <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>  <del> 10.1. </del>  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>  new key. In terms of additional metadata, the only concrete applications of this may be revisited in future revisions. The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. <del> This is derived from the fact that permitting I servers lead to 2^I </del>  segregations of the total user-base U.  Moreover, if we permit M = 1, <del> then this effectively halves the anonymity set for each server, and </del>  thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in privacy. 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 <del> monitoring the access patterns of clients, it is likely to unavoidable that clients hold valid issuance data for the previous key epoch.  This also means that the server can continue to verify </del>  redemption data for a previously used key.  This makes the rotation <del> period much smoother for clients. </del>  For privacy reasons, it is recommended that key epochs are chosen <del> that limit clients to holding issuance data for a maximum of two </del>  keys.  By choosing F = L/2 then the minimum value of F is a week, since the minimum recommended value of L is 2 weeks.  Therefore, by the initial assumption, then all users should only have access to has in breaking one of the security guarantees in the Privacy Pass protocol I-D.ietf-privacypass-protocol. <del> 10.2. </del>  Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser maximum value of I should be 3. If the value of U is much bigger (e.g. 5 million) then this would <del> permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers. </del>  <del> 10.3. </del>  Using the recommendations in more-servers, it is possible to tolerate <del> larger number of servers if clients in the ecosystem ensure that they </del>  only store tokens for a small number of them.  In particular, if <del> clients limit their storage of redemption tokens to the bound implied </del>  by I, then prevents a malicious verifier from triggering redemptions <del> for all servers in the ecosystem. 11. The Privacy Pass protocol and ecosystem are both intended to be receptive to extensions that expand the current set of functionality. As specified in I-D.ietf-privacypass-protocol, all extensions to the Privacy Pass protocol SHOULD be specified as separate documents that modify the content of this document in some way.  We provide guidance on the type of modifications that are possible in the following. Any such extension should also 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. Similarly, extensions MAY also add new server running modes, if applicable, to those that are documented in running-modes. Any extension to the Privacy Pass protocol must adhere to the guidelines specified in key-mgmt for managing server public key data. 12. The following is a non-exhaustive list of applications that currently make use of the Privacy Pass protocol, or some variant of the underlying functionality. 12.1. Cloudflare uses an implementation of the Privacy Pass protocol for allowing clients that have previously interacted with their Internet challenge protection system to bypass future challenges PPSRV.  These challenges can be expensive for clients, and there have been cases where bugs in the implementations can severely degrade client accessibility. Clients must install a browser extension PPEXT that acts as the Privacy Pass client in an exchange with Cloudflare's Privacy Pass server, when an initial challenge solution is provided.  The client extension stores the issued tokens and presents a valid redemption token when it sees future Cloudflare challenges.  If the redemption token is verified by the server, the client passes through the security mechanism without completing a challenge. 12.2. The Trust Token API TrustTokenAPI has been devised as a generic API for providing Privacy Pass functionality in the browser setting.  The API is intended to be implemented directly into browsers so that server's can directly trigger the Privacy Pass workflow. 12.3. The PrivateStorage API developed by Least Authority is a solution for uploading and storing end-to-end encrypted data in the cloud.  A recent addition to the API PrivateStorage allows clients to generate Zero-knowledge Access Passes (ZKAPs) that the client can use to show that it has paid for the storage space that it is using.  The ZKAP protocol is based heavily on the Privacy Pass redemption mechanism. The client receives ZKAPs when it pays for storage space, and redeems the passes when it interacts with the PrivateStorage API. 12.4. The browser Brave uses Basic Attention Tokens (BATs) to provide the basis for an anonymity-preserving rewards scheme Brave.  The BATs are essentially Privacy Pass redemption tokens that are provided by a central Brave server when a client performs some action that triggers a reward event (such as watching an advertisement).  When the client amasses BATs, it can redeem them with the Brave central server for rewards. 12.5. Similarly to BATs, a more generic approach for providing anonymous peers to purchase resources from anonymous servers has been proposed OpenPrivacy.  The protocol is based on a variant of Privacy Pass and is intended to allow clients purchase (or pre-purchase) services such as message hosting, by using Privacy Pass redemption tokens as a form of currency.  This is also similar to how ZKAPs are used. </del>

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!

1.  <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",  <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.  <ins> Client: An entity that seeks authorization to an Origin. </ins>  <ins> Origin: An entity that challenges Clients for tokens. </ins>  <ins> Issuer: An entity that issues tokens to Clients for properties attested to by the Attester. </ins>  <ins> Attester: An entity that attests to properties of Client for the purposes of token issuance. </ins>  <ins> 3. </ins>  <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.  <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.  <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.  <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  <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: keys from multiple network vantage points.  This is done to ensure consistent keys to seemingly different clients.  <ins> Clients embed Issuer keys into software. </ins>  <ins> As above, specific mechanisms for key management and discovery are out of scope for this document. </ins>  <ins> 3.2.2.2. </ins> Token issuance associates all issued tokens with a particular choice  <ins> of key.  If an Issuer issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. </ins>  <ins> To prevent against this, Issuers MUST only use one private key for </ins> issuing tokens at any given time.  Servers MAY use one or more keys  <ins> for redemption to allow Issuers for seamless key rotation. </ins> Servers may rotate keys as a means of revoking tokens issued under  <ins> old or otherwise expired keys.  Alternatively, Issuers may include </ins> expiration information as metadata alongside the token; See metadata  <ins> for more discussion about metadata constraints.  Both techniques are </ins> equivalent since they cryptographically bind expiration to individual tokens. See parametrization for guidelines on what frequency of key rotations are permitted.  <ins> 3.2.3. </ins>  <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  <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  <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  <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.  <ins> 3.2.4. </ins>  <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  <ins> in tracking granularity similarly to introducing more Issuers (though </ins> with more potential targeting).  <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  <ins> of information that Issuer's may learn about Clients otherwise. </ins> Since this metadata may be useful for practical deployments of  <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.  <ins> 4.2. </ins>  <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  <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.  <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  <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  <ins> allowing too many Issuers at any one time. </ins>  <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  <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),  <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  <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>  <ins> 4.3.1. </ins>  <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  <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.  <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  <ins> each Client in the system. </ins>  <ins> 4.3.1.1. </ins>  <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  <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  <ins> contains the set of Issuers that redemptions have been attempted </ins> against.  An empty redemption is returned when the limit has been hit:  <ins> 4.4. </ins> If there are multiple key registries, or if a key registry colludes  <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.  <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>  <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  <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>  <ins> 4.6. </ins> Clients may see an incentive in accepting all tokens that are issued  <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.  <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  <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  <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.  <ins> 5. </ins> We present a number of security considerations that prevent malicious  <ins> Clients from abusing the protocol. </ins>  <ins> 5.1. </ins>  <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>  <ins> 5.2. </ins>  <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  <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.  <ins> 6. </ins>  <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>  <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.  <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 this may be revisited in future revisions. The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A.  <ins> This is derived from the fact that permitting I Issuers lead to 2^I </ins> segregations of the total user-base U.  Moreover, if we permit M = 1,  <ins> then this effectively halves the anonymity set for each Issuer, and </ins> thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in privacy. 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  <ins> monitoring the access patterns of Clients, it is likely to unavoidable that Clients hold valid issuance data for the previous key epoch.  This also means that the Issuer can continue to verify </ins> redemption data for a previously used key.  This makes the rotation  <ins> period much smoother for Clients. </ins> For privacy reasons, it is recommended that key epochs are chosen  <ins> that limit Clients to holding issuance data for a maximum of two </ins> keys.  By choosing F = L/2 then the minimum value of F is a week, since the minimum recommended value of L is 2 weeks.  Therefore, by the initial assumption, then all users should only have access to has in breaking one of the security guarantees in the Privacy Pass protocol I-D.ietf-privacypass-protocol.  <ins> 6.2. </ins> Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser maximum value of I should be 3. If the value of U is much bigger (e.g. 5 million) then this would  <ins> permit I = (log_2(5000000/5000)-1)/2 ~= 4 Issuers. </ins>  <ins> 6.3. </ins> Using the recommendations in more-servers, it is possible to tolerate  <ins> larger number of Issuers if Clients in the ecosystem ensure that they </ins> only store tokens for a small number of them.  In particular, if  <ins> Clients limit their storage of redemption tokens to the bound implied </ins> by I, then prevents a malicious verifier from triggering redemptions  <ins> for all Issuers in the ecosystem. </ins>


"info". Given this configuration and these inputs, the two messages exchanged <del> in this protocol are described below. </del>  3.1. <del> The Client first creates a verifiable context as follows: </del>  Here, 0x0004 is the two-octet identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite in OPRF. value "nonce" using the input challenge and Issuer key identifier as follows: <del> The Client then creates a TokenRequest structured as follows: </del>  The structure fields are defined as follows: "token_key_id" is the least significant byte of the "key_id". <del> "blinded_msg" is the Nk-octet request defined above. </del>  <del> The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below, where Nk = 48. </del>  Upon receipt of the request, the Issuer validates the following conditions: <del> The TokenRequest contains a supported token_type </del>  The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. <del> The TokenRequest.blinded_msg is of the correct size </del>  If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client. The Issuer then creates a TokenResponse structured as follows: <del> The structure fields "evaluated_msg" and "proof" are as computed above, where Ns is as defined in OPRF, Section 4. </del>  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/ 3.3. Upon receipt, the Client handles the response and, if successful, <del> processes the body as follows: </del>  If this succeeds, the Client then constructs a Token as follows:

draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME

"info". Given this configuration and these inputs, the two messages exchanged  <ins> in this protocol are described below.  This section uses notation described in OPRF, Section 4, including SerializeElement and DeserializeElement, SerializeScalar and DeserializeScalar, and DeriveKeyPair. </ins> 3.1.  <ins> The Client first creates a context as follows: </ins> Here, 0x0004 is the two-octet identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite in OPRF. value "nonce" using the input challenge and Issuer key identifier as follows:  <ins> If the Blind step fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows: </ins> The structure fields are defined as follows: "token_key_id" is the least significant byte of the "key_id".  <ins> "blinded_request" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_msg)".  Ne is as defined in OPRF, Section 4. </ins>  <ins> The value "tweaked_key" is stored locally and used later as described in finalization.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:  <ins> The TokenRequest contains a supported token_type. </ins> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer.  <ins> The TokenRequest.blinded_msg is of the correct size. </ins> If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client. The Issuer then creates a TokenResponse structured as follows:  <ins> The structure fields are defined as follows: "evaluate_response" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluated_msg)". "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as "concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))", where Ns is as defined in OPRF, Section 4. </ins> The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/ 3.3. Upon receipt, the Client handles the response and, if successful,  <ins> deserializes the body values TokenResponse.evaluate_response and TokenResponse.evaluate_proof.  If deserialization of any value fails, the Client aborts the protocol.  Otherwise, when deserialization yields "evaluated_msg" and "proof", the Client processes the response as follows: </ins> If this succeeds, the Client then constructs a Token as follows:


A Manifest Information Model for Firmware Updates in IoT Devices <del> draft-ietf-suit-information-model-10 </del>  Abstract provides the motivations for each of the manifest information elements.  4.1. The following sub-sections aim to provide information about the 4.3.7. The location where a target should find a payload MUST be <del> authenticated. </del>  Mitigates: threat-net-redirect,

Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11

A Manifest Information Model for Firmware Updates in IoT Devices  <ins> draft-ietf-suit-information-model-11 </ins> Abstract provides the motivations for each of the manifest information elements. <ins> Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution.  Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to do the "right thing".  Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place.  However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices then the possibilities for deference are limited. </ins> 4.1. The following sub-sections aim to provide information about the 4.3.7. The location where a target should find a payload MUST be  <ins> authenticated.  Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.  The security considerations of Uniform Resource Identifiers (URIs) are applicable RFC3986. </ins> Mitigates: threat-net-redirect,


sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time <del> must be guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </del>  The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not This element is OPTIONAL. <del> Implements: </del>  4. able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server. <del> Mitigated by: </del>  4.2.17. for a device.  The last valid firmware should not have an expiration time.  Mitigates: Implemented by: 4.3.18.  Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates: <del> 4.3.19. </del>  For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an Mitigates: <del> 4.3.20. </del>  Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and

Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.

sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time  <ins> must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </ins> The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not This element is OPTIONAL.  <ins> Implements: req-use-delegation, </ins> 4. able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server.  <ins> Mitigated by: req-sec-key-protection, </ins> 4.2.17. for a device.  The last valid firmware should not have an expiration time. <ins> If a device has a flawed time source (either local or remote), an old update can be deployed as new. </ins> Mitigates: Implemented by: 4.3.18. <ins> Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time.  Because it is difficult and risky to replace a Trust Anchor, keys used for signing updates SHOULD be delegates of that Trust Anchor. If key expiration is performed based on time, then a secure clock is needed.  If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds threat-key-exposure. Mitigates: 4.3.19. </ins> Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates:  <ins> 4.3.20. </ins> For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an Mitigates:  <ins> 4.3.21. </ins> Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and


3.25. The delegation chain offers enhanced authorization functionality via <del> authorization tokens.  Each token itself is protected and does not require another layer of protection.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. </del>  This element is OPTIONAL.

Clarify that delegation chains are lists of authentication tokens where each token provides credentials for the next until the final token which provides the credentials for the manifest.
Ben Kaduk wrote:

3.25. The delegation chain offers enhanced authorization functionality via  <ins> authorization tokens, such as CBOR Web Tokens RFC8392 with Proof of Possession Key Semantics RFC8747.  Each token itself is protected and does not require another layer of protection.  Each authorization token typically includes a public key or a public key fingerprint, however this is dependent on the tokens used.  Each token MAY include additional metadata, such as key usage information.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. The first token in any delegation chain MUST be autheticated by the recipient's Trust Anchor.  Each subsequent token MUST be authenticated using the previous token.  This allows a recipient to discard each antecedent token after it has authenticated the subsequent token.  The final token MUST enable authentication of the manifest.  More than one delegation chain MAY be used if more than one signature is used.  Note that no restriction is placed on the encoding order of these tokens, the order of elements is logical only. </ins> This element is OPTIONAL.


negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has <del> provided similar functionality since the introduction of RTMFP RFC7016 in 2008. </del>  4. quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. <del> Mode 1 MUST only be used when user consent has been provided.  The </del>  details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to

(nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." : It seems like the references for STUN and TURN should be normative.

negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has  <ins> provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support RFC7016 in 2008. </ins> 4. quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server.  <ins> Mode 1 MUST NOT be used unless user consent has been provided.  The </ins> details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to


By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or <del> relay server).  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </del>  It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web

There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this. Noted.

By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or  <ins> relay server) when such connections are possible.  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </ins> It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web


(e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. <del> #2 is a less significant but valid concern.  While the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb-transports are fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges.  Although they typically contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime.  As such, they can be a fairly significant fingerprinting surface.  In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private local IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device.  This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation.  It should be noted that local addresses are just one potential mechanism for this correlation and this is an area for further study. </del>  #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and

Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.

(e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN.  <ins> #2 is a less significant but nonetheless valid concern.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb- transports is fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime.  As such, they can be a fairly significant fingerprinting surface.  In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device. This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation.  It should be noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. </ins> #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and


the client can be learned.  In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple <del> interfaces (a "split-tunnel" VPN), WebRTC will discover not only </del>  the public address for the VPN, but also the ISP public address over which the VPN is running. If an enterprise TURN server is present, the preferred route MUST be through this TURN server.  Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface <del> MUST be discovered and provided to the application.  This ensures that direct connections can still be established in this mode. </del>  Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP 6.1. <del> When trying to follow typical IP routing, the simplest approach is to bind() the sockets used for peer-to-peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </del>  6.2. When binding to a wildcard address, some extra work is needed to <del> determine a suitable host candidate, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing). Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </del>  First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI RFC3986.  If table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the <del> equivalent to determine the appropriate host candidate. </del>  7.

S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.

the client can be learned.  In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple  <ins> interfaces (a "split-tunnel" VPN), WebRTC can discover not only </ins> the public address for the VPN, but also the ISP public address over which the VPN is running. If an enterprise TURN server is present, the preferred route MUST be through this TURN server.  Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface  <ins> MUST be discovered and provided to the application as host candidates.  This ensures that direct connections can still be established in this mode. </ins> Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP 6.1.  <ins> When trying to follow typical IP routing, as required by Modes 2 and 3, the simplest approach is to bind() the sockets used for peer-to- peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </ins> 6.2. When binding to a wildcard address, some extra work is needed to  <ins> determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </ins> First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI RFC3986.  If table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the  <ins> equivalent to determine the appropriate local address. </ins> 7.


and Traversal Using Relays around NAT (TURN) RFC5766, and then checks the connectivity of each local-address-remote-address pair in order to select the best one.  The addresses that are collected usually <del> consist of an endpoint's private physical/virtual addresses and its public Internet addresses. </del>  <del> These addresses are exposed upwards to the web application, so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </del>  The information revealed falls into three categories: used in this document, it is always in reference to an RFC1919 proxy server. <del> Of these three concerns, #1 is the most significant, because for some users, the purpose of using a VPN is for anonymity.  However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. #2 is a less significant but nonetheless valid concern.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb- transports is fairly benign due to their intentionally short </del>  lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. <del> #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </del>  Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits. <del> As a result, we want to avoid blunt solutions that disable WebRTC or make it significantly harder to use.  This document takes a more nuanced approach, with the following goals: </del>  Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same <del> routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </del>  application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by 8. <del> This document is entirely devoted to security considerations. </del>  9.

This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.

and Traversal Using Relays around NAT (TURN) RFC5766, and then checks the connectivity of each local-address-remote-address pair in order to select the best one.  The addresses that are collected usually  <ins> consist of an endpoint's private physical or virtual addresses and its public Internet addresses. </ins>  <ins> These addresses are provided to the web application so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </ins> The information revealed falls into three categories: used in this document, it is always in reference to an RFC1919 proxy server.  <ins> Of these three concerns, the first is the most significant, because for some users, the purpose of using a VPN is for anonymity. However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. The second concern is less significant but valid nonetheless.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf- rtcweb-transports is fairly benign due to their intentionally short </ins> lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits noted that private addresses are just one potential mechanism for this correlation and this is an area for further study.  <ins> The third concern is the least common, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </ins> Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits.  <ins> As a result, blunt solutions that disable WebRTC or make it significantly harder to use are undesirable.  This document takes a more nuanced approach, with the following goals: </ins> Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same  <ins> routing treatment).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </ins> application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by 8.  <ins> This document describes several potential privacy and security concerns associated with WebRTC peer-to-peer connections, and provides mechanisms and recommendations for WebRTC implementations to address these concerns. </ins> 9.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  3.

Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP  <ins> 14 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.