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

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