Change:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME

Discussion:
sense that they cannot be linked back to the previous session where they were issued. <del> The Internet performance company Cloudflare has already implemented server-side support for an initial version of the Privacy Pass protocol PPSRV, and a client-side implementations is also available PPEXT.  More recently, a number of applications have been built upon the protocol, or upon slight variants of it; see: TRUST, OpenPrivacy, PrivateStorage.  The protocol can be instantiated using a cryptographic primitive known as a verifiable oblivious pseudorandom function (VOPRF) for implementing the authorization mechanism.  Such VOPRF protocols can be implemented over prime-order groups, and constructions are currently being drafted in separate standardization processes I-D.irtf-cfrg-voprf. </del> The Privacy Pass protocol is split into three stages.  The first stage, initialisation, produces the global server configuration that is broadcast to (and stored by) all clients.  The second stage, the

The "ServerConfig" struct describes and maintains the underlying configuration that is used by the server. <del> The "SecretKey" and "PublicKey" types are just wrappers around byte </del> <ins> The "PrivateKey" and "PublicKey" types are just wrappers around byte </ins> arrays. 3.1.3.

3.1.6. <del> The "ClientIssuanceMessage" struct corresponds to the message that </del> <ins> The "ClientIssuanceRequest" struct corresponds to the message that </ins> the client sends to the server during the issuance phase of the protocol (issuance-phase).

client. The value of "n" is determined by the length of the <del> "ClientIssuanceElement" vector in the "ClientIssuanceMessage" struct. The internal data types are described below: </del> <ins> "ClientIssuanceElement" vector in the "ClientIssuanceRequest" struct. The internal data types are described below. </ins> 3.1.8.

3.1.9. <del> The "RedemptionMessage" struct consists of the data that is sent by </del> <ins> The "RedemptionRequest" struct consists of the data that is sent by </ins> the client during the redemption phase of the protocol (redemption- phase). 3.1.10. The "ServerRedemptionResponse" struct corresponds to a boolean value <del> that indicates whether the "ClientRedemptionMessage" sent by the </del> <ins> that indicates whether the "ClientRedemptionRequest" sent by the </ins> client is valid.  It can also contain any associated data. 3.2.

Inputs: <del> "s_cfg": A "ServerConfig" struct. </del> <ins> "srv_cfg": A "ServerConfig" struct. </ins> <del> "issuance_message": A "ClientIssuanceMessage" struct. </del> <ins> "issuance_request": A "ClientIssuanceRequest" struct. </ins> Outputs:

Outputs: <del> "message": A "ClientRedemptionMessage" struct. </del> <ins> "message": A "ClientRedemptionRequest" struct. </ins> 3.2.7.

Inputs: <del> "s_cfg": A "ServerConfig" struct. </del> <ins> "srv_cfg": A "ServerConfig" struct. </ins> <del> "message": A "ClientRedemptionMessage" struct. </del> <ins> "message": A "ClientRedemptionRequest" struct. </ins> Outputs: