Change:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()

Discussion:
1. The Privacy Pass protocol as described in draft-davidson-pp-protocol <del> can be integrated with a number of different settings, from server to server communication to browsing the internet. </del> <ins> 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. <del> The following terms are used throughout this document. Server: A service that provides the server-side functionality required by the protocol documented here (typically denoted S). Client: An entity that seeks authorization from a server that supports interactions in the Privacy Pass protocol (typically denoted C). Key: The secret key used by the Server for authorizing client data. Commitment: Alternative name for Server's public key corresponding to the secret key that they hold. </del> <ins> We use the same definition of Server and Client that is used in draft-davidson-pp-protocol and draft-davidson-pp-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

wrapping: Describes the wrapping of messages within HTTP requests/ responses. <del> server-config: Describes how HTTP clients retrieve server </del> <ins> server-config: Describes how HTTP Clients retrieve server </ins> configurations and key commitments. issuance: Describes how issuance requests are performed via a HTTP

2. <del> Messages from HTTP-based clients to HTTP-based servers are performed </del> <ins> Messages from HTTP-based Clients to HTTP-based Servers are performed </ins> as GET and POST requests.  The messages are sent via the "Sec- Privacy-Pass" header.

Note that the requests may contain addition Headers, request data and URL parameters that are not specified here, these extra fields should <del> be ignored, though may be used by the server to determine whether to </del> <ins> be ignored, though may be used by the Server to determine whether to </ins> fulfill the requested issuance/redemption. 3. <del> A client SHOULD fetch the server configuration and current key </del> <ins> A Client SHOULD fetch the Server configuration and current public key </ins> commitments prior to performing issuance and redemption.  This configuration is accessible via a "CONFIG_ENDPOINT", either provided <del> by the server or by a global registry that provides consistency and </del> <ins> by the Server or by a global registry that provides consistency and </ins> anonymization guarantees. 3.1. <del> To ensure that a server isn't providing different views of their key material/commitments to different users, servers are expected to write their commitments to a verifiable data structure. </del> <ins> To ensure that a Server isn't providing different views of their public key material to different users, Servers are expected to write their commitments to a verifiable data structure. </ins> Using a verifiable log-backed map (verifiable-data-structures), the <del> server can publish their commitments to the log in a way that clients can detect when the server is attempting to provide a split-view of their key commitments to different clients. </del> <ins> Server can publish their commitments to the log in a way that Clients can detect when the Server is attempting to provide a split-view of their key commitments to different Clients. </ins> The key to the map is the "server_origin", with the value being: The addition to the log is made via a signed message to the log operator, which verifies the authenticity against a public key <del> associated with that server origin (either via the Web PKI or a out- of-band key). </del> <ins> associated with that Server origin (either via the Web PKI or a out- of-band key).  The signature should be computed under a long-term signing key that is associated with the Server identity. </ins> <del> The server SHOULD then store an inclusion proof of the current key </del> <ins> The Server SHOULD then store an inclusion proof of the current key </ins> commitment so that it can present it when delivering the key <del> commitment directly to the client or when the key commitment is being </del> <ins> commitment directly to the Client or when the key commitment is being </ins> delivered by a delegated party (other registries/preloaded configuration lists/etc). <del> The client can then perform a request for the key commitment against either the global registry or the server as described key-commitment. </del> <ins> The Client can then perform a request for the key commitment against either the global registry or the Server as described in key- commitment.  Note that the signature should be verified by the Client to ensure that the key material is owned by the Server.  This requires that the Client know the public verification key that is associated with the Server. </ins> <del> To avoid user segregation as a result of server configuration/ </del> <ins> To avoid user segregation as a result of Server configuration/ </ins> commitment rotation, the log operator SHOULD enforce limits on how many active commitments exist and how quickly the commitments are being rotated.  Clients SHOULD reject configurations/commitments that

3.2. <del> Inputs: - "server_origin": The origin to retrieve a server </del> <ins> Inputs: - "server_origin": The origin to retrieve a Server </ins> configuration for. No outputs. <del> The client makes an anonymous GET request to </del> <ins> The Client makes an anonymous GET request to </ins> "CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type "fetch-config" and a body of: <del> The server looks up the configuration associated with the origin </del> <ins> The Server looks up the configuration associated with the origin </ins> "server_origin" and responds with a message of type "config" and a body of: <del> The client then stores the associated configuration state under </del> <ins> The Client then stores the associated configuration state under </ins> the corresponding "server_origin". (TODO: This might be mergable with key commitment retrieval if

4. <del> The client SHOULD retrieve server key commitments prior to both an </del> <ins> The Client SHOULD retrieve Server key commitments prior to both an </ins> issuance and redemption to verify the consistency of the keys and to monitor for key rotation between issuance and redemption events.

No outputs. <del> The client fetches the configuration state "server_id", </del> <ins> The Client fetches the configuration state "server_id", </ins> "ciphersuite", "commitment_id" associated with "server_origin". <del> The client makes an anonymous GET request to </del> <ins> The Client makes an anonymous GET request to </ins> "CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type "fetch-commitment" and a body of: <del> The server looks up the current configuration, and constructs a </del> <ins> The Server looks up the current configuration, and constructs a </ins> list of commitments to return, noting whether a key commitment is valid for issuance or redemption or both. <del> The server then responds with a message of type "commitment" and a </del> <ins> The Server then responds with a message of type "commitment" and a </ins> body of: <del> The client then verifies the signature for each key commitment and stores the list of commitments to the current scope.  The client </del> <ins> The Client then verifies the signature for each key commitment and stores the list of commitments to the current scope.  The Client </ins> SHOULD NOT cache the commitments beyond the current scope, as new commitments should be fetched for each independent issuance and <del> redemption request.  The client SHOULD verify the </del> <ins> redemption request.  The Client SHOULD verify the </ins> "inclusion_proofs" to confirm that the key commitment has been <del> submitted to a trusted registry. </del> <ins> submitted to a trusted registry.  Once the Client receives the "ciphersuite" for the Server, it should implement all Privacy Pass API functions (as detailed in draft-davidson-pp-protocol) using this ciphersuite. </ins> 5.

Outputs: - "tokens": A list of tokens that have been signed via the Privacy Pass protocol. <del> When a client wants to request tokens from a server, it should </del> <ins> When a Client wants to request tokens from a server, it should </ins> first fetch a key commitment from the issuer via the process described in key-commitment and keep the result as "commitment". <del> The client should then call the "CLIENT_ISSUE_GEN" interface requesting "count" tokens storing the resulting "c_data", "i_data", "g_data". </del> <ins> The Client should then call the "Generate" function requesting "count" tokens storing the resulting "input" data. </ins> <del> The client then makes a POST request to <"server_origin">/.well- </del> <ins> The Client then makes a POST request to <"server_origin">/.well- </ins> known/privacy-pass with a message of type "request-issuance" and a body of: <del> The server, upon receipt of the "request" should call the "SERVER_ISSUE" interface with the value of "i_data" with a result of "server_issue_resp". </del> <ins> The server, upon receipt of the "request" should call the "Issue" function with the "public_key", "secret_key" and the value of "msg" with a result of "resp". </ins> <del> The server should then respond to the POST request with a message </del> <ins> The Server should then respond to the POST request with a message </ins> of type "issue" and a body of: <del> The client should then should call the "CLIENT_ISSUE_FINISH" interface with the resulting "ciphersuite", ```evals","proof", and stored"g_data"to extract a list of"tokens``. </del> <ins> The Client should then should call the "Process" function with the "public_key", stored "inputs" and resulting "resp", to extract a list of "redemption_tokens". </ins> <del> The client should store the "public_key" associated with these tokens and the elements of "tokens" under storage partitioned by the "server_origin", accessible only via the Privacy Pass API. </del> <ins> The Client should store the "public_key" associated with these tokens and the elements of "redemption_tokens" under storage partitioned by the "server_origin", accessible only via the Privacy Pass API. </ins> 6. There are two forms of Privacy Pass redemption that could function under the HTTP API.  Either passing along a token directly to the target endpoint, which would perform its own redemption token- <del> redemption, or the client redeeming the token and passing the result </del> <ins> redemption, or the Client redeeming the token and passing the result </ins> 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.  - </del> <ins> Inputs: - "server_id": The Server ID to redeem a token against.  - </ins> "ciphersuite": The ciphersuite for this token.  - "public_key": The <del> public key associated with this token.  - "token": A Privacy Pass token.  - "additional_data": Additional data to bind to this token </del> <ins> public key associated with this token.  - "redemption_token": A Privacy Pass token.  - "info": Additional data to bind to this token </ins> redemption. Outputs: - "result": The result of the redemption from the server. <del> The client should call the "CLIENT_REDEEM" interface with "server_id", "ciphersuite", "public_key", "token" and auxiliary data of "additional_data" storing the resulting "data" and "tag". </del> <ins> The Client should call the "Redeem" function with "redemption_token" and additional data of "info" storing the resulting "data" and "tag". </ins> <del> The client makes a POST request to <"server_origin">/.well-known/ </del> <ins> The Client makes a POST request to <"server_origin">/.well-known/ </ins> privacy-pass with a message of type "token-redemption" and a body of: <del> The server, upon receipt of "request" should call the "SERVER_REDEEM" interface with the "data", "tag", "aux" storing the resulting "resp". </del> <ins> The server, upon receipt of "request" should call the "Verify" interface with "public_key", "secret_key" and the received "data", "tag", "info" storing the resulting "resp". </ins> <del> The server should then respond to the POST request with a message </del> <ins> The Server should then respond to the POST request with a message </ins> of type "redemption-result" and a signed body of: <del> The client upon receipt of this message should verify the </del> <ins> The Client upon receipt of this message should verify the </ins> "signature" using the "verification_key" from the configuration and return the "result". 6.2. <del> Inputs: - "server_origin": The server origin to redeem a token for. </del> <ins> Inputs: - "server_origin": The Server origin to redeem a token for. </ins> - "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 </del> <ins> When a Client wants to redeem tokens for a server, it should first </ins> fetch a key commitment from the issuer via the process described in key-commitment and keep the result as "commitment". <del> The client should then look up the storage partition associated with "server_origin" and fetch a "token" and "public_key". </del> <ins> The Client should then look up the storage partition associated with "server_origin" and fetch a "redemption_token" and "public_key". </ins> <del> The client should verify that the "public_key" is in the current </del> <ins> The Client should verify that the "public_key" is in the current </ins> "commitment".  If not, it should discard the token and fail the redemption attempt. <del> As part of the request to "target", the client will include the </del> <ins> As part of the request to "target", the Client will include the </ins> token as part of the request in the "Sec-Privacy-Pass" header along with whatever other parameters are being passed as part of the request to "target".  The header will contain a message of

6.3. <del> Inputs: - "server_origin": The server origin to redeem a token for. </del> <ins> Inputs: - "server_origin": The Server origin to redeem a token for. </ins> - "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 </del> <ins> When a Client wants to redeem tokens for a server, it should first </ins> fetch a key commitment from the issuer via the process described in key-commitment and keep the result as "commitment". <del> The client should then look up the storage partition associated with "server_origin" and fetch a "token" and "public_key". </del> <ins> The Client should then look up the storage partition associated with "server_origin" and fetch a "redemption_token" and "public_key". </ins> <del> The client should verify that the "public_key" is in the current </del> <ins> The Client should verify that the "public_key" is in the current </ins> "commitment".  If not, it should discard the token and fail the redemption attempt. <del> The client constructs a bytestring "aux" made up of the "target", </del> <ins> The Client constructs a bytestring "info" made up of the "target", </ins> the current "timestamp", and "additional_data": <del> The client then performs a token redemption as described in token- </del> <ins> The Client then performs a token redemption as described in token- </ins> redemption.  Storing the resulting "redemption-result" message. <del> As part of the request to "target", the client will include the </del> <ins> As part of the request to "target", the Client will include the </ins> redemption result as part of the request in the "Sec-Privacy-Pass" header along with whatever other parameters are being passed as part of the request to "target".  The header will contain a message of type "signed-redemption-result" with a body of: At this point, the "target" can verify the integrity of <del> "signed_redemption.aux" based on the values of "target", "timestamp", and "additional_data" and verify the signature of the redemption result by querying the current configuration of the Privacy Pass server.  The inclusion of "target" and "timestamp" proves that the server attested to the validity of the token in relation to this particular request. </del> <ins> "signed_redemption.info" based on the values of "target", "timestamp", and "additional_data" and verify the signature of the redemption result by querying the current configuration of the Privacy Pass server.  The inclusion of "target" and "timestamp" proves that the Server attested to the validity of the token in relation to this particular request. </ins> 7.