Original text:
1. <del> The Privacy Pass protocol as described in draft-davidson-pp-protocol can be integrated with a number of different settings, from server to server communication to browsing the internet. </del>  In this document, we will provide an API to use for integrating Privacy Pass with an HTTP framework.  Providing the format of HTTP 1.1. We use the same definition of server and client that is used in <del> draft-davidson-pp-protocol and draft-davidson-pp-architecture. </del>  We assume that all protocol messages are encoded into raw byte format before being sent.  We use the TLS presentation language RFC8446 to many active commitments exist and how quickly the commitments are being rotated.  Clients SHOULD reject configurations/commitments that violate their requirements for avoiding user segregation.  These <del> considerations are discussed as part of draft-davidson-pp- </del>  architecture. 3.2. "inclusion_proofs" to confirm that the key commitment has been submitted to a trusted registry.  Once the client receives the "ciphersuite" for the server, it should implement all Privacy Pass <del> API functions (as detailed in draft-davidson-pp-protocol) using this ciphersuite. </del>  5. redemption, or the client redeeming the token and passing the result along to the target endpoint.  These two methods are described below.  6.1. <del> Inputs: - "server_id": The server ID to redeem a token against.  - "ciphersuite": The ciphersuite for this token.  - "public_key": The public key associated with this token.  - "redemption_token": A Privacy Pass token.  - "info": Additional data to bind to this token redemption. </del>  Outputs: - "result": The result of the redemption from the server.  The client should call the "Redeem" function with "redemption_token" and additional data of "info" storing the resulting "data" and "tag". 6.2. <del> Inputs: - "server_origin": The server origin to redeem a token for. - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </del>  When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described 6.3. <del> Inputs: - "server_origin": The server origin to redeem a token for. - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </del>  When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described 7. <del> Security considerations for Privacy Pass are discussed in draft- davidson-pp-architecture. </del>  8. <del> 8.1. </del>  This specification registers a new well-known URI. this trade-off is important in deciding the effective anonymity of each client in the system.  8.3. If there are multiple key registries, or if a key registry colludes

Reviewer comments:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.

Revised text:
1.  <ins> The Privacy Pass protocol as described in draft-ietf-privacypass- protocol can be integrated with a number of different settings, from server to server communication to browsing the internet. </ins> In this document, we will provide an API to use for integrating Privacy Pass with an HTTP framework.  Providing the format of HTTP 1.1. We use the same definition of server and client that is used in  <ins> draft-ietf-privacypass-protocol and draft-ietf-privacypass- architecture. </ins> We assume that all protocol messages are encoded into raw byte format before being sent.  We use the TLS presentation language RFC8446 to many active commitments exist and how quickly the commitments are being rotated.  Clients SHOULD reject configurations/commitments that violate their requirements for avoiding user segregation.  These  <ins> considerations are discussed as part of draft-ietf-privacypass- </ins> architecture. 3.2. "inclusion_proofs" to confirm that the key commitment has been submitted to a trusted registry.  Once the client receives the "ciphersuite" for the server, it should implement all Privacy Pass  <ins> API functions (as detailed in draft-ietf-privacypass-protocol) using this ciphersuite. </ins> 5. redemption, or the client redeeming the token and passing the result along to the target endpoint.  These two methods are described below. <ins> In the HTTP ecosystem, redemption contexts should generally be keyed by the same privacy boundary used for cookies and other local storage.  Generally this is the top-level origin.  Any redemption context should be built following the principles outlined in draft- ietf-privacypass-architecture and later in privacy. </ins> 6.1.  <ins> Inputs: - "context": The request context to use.  - "server_id": The server ID to redeem a token against.  - "ciphersuite": The ciphersuite for this token.  - "public_key": The public key associated with this token.  - "redemption_token": A Privacy Pass token.  - "info": Additional data to bind to this token redemption. </ins> Outputs: - "result": The result of the redemption from the server. <ins> The client should check whether the "server_id" is present in the "context".  If it isn't and the size of the "context" is beneath the client's limit, it should be added. </ins> The client should call the "Redeem" function with "redemption_token" and additional data of "info" storing the resulting "data" and "tag". 6.2.  <ins> Inputs: - "context": The request context to use.  - "server_origin": The server origin to redeem a token for.  - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </ins> When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described 6.3.  <ins> Inputs: - "context": The request context to use.  - "server_origin": The server origin to redeem a token for.  - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </ins> When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described 7.  <ins> Security considerations for Privacy Pass are discussed in draft-ietf- privacypass-architecture. </ins> 8.  <ins> General privacy considerations for Privacy Pass are discussed in draft-ietf-privacypass-architecture. In order to implement this API with redemption contexts, a client needs to maintain strong privacy boundaries between different redemption contexts to avoid privacy leakage from redemptions across them.  Notably in the web/HTTP world, cross-site tracking and fingerprinting will need to be considered and mitigated in order to maintain these privacy boundaries. 9. 9.1. </ins> This specification registers a new well-known URI. this trade-off is important in deciding the effective anonymity of each client in the system. <ins> 8.2.1.1. Another option to allow a large number of servers in the ecosystem, while preventing the joining of a number of different tokens is for 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. 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 contains the set of servers that redemptions have been attempted against.  An empty redemption is returned when the limit has been hit: </ins> 8.3. If there are multiple key registries, or if a key registry colludes