Change:
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

Discussion:
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 ()