Original text:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are <del> privately verifiable, and another that produces tokens that are publicly verifiable. </del>  1. This document describes the issuance protocol for Privacy Pass built on HTTP.  It specifies two variants: one that is privately verifiable <del> based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </del>  This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks. verifying tokens. Unless otherwise specified, this document encodes protocol messages <del> in TLS notation from TLS13, Section 3. </del>  3. Issuers MUST provide two parameters for configuration: <del> Issuer Request URI: a token request URL for generating access </del>  tokens.  For example, an Issuer URL might be https://issuer.example.net/example-token-request.  This parameter uses resource media type "text/plain". <del> Issuer Public Key values: an Issuer Public Key for an issuance </del>  protocol. The Issuer parameters can be obtained from an Issuer via a directory 5.4. <del> To verify a token, a verifier creates a VOPRF context, evaluates the token contents, and compares the result against the token authenticator value, as follows: </del>  5.5. 6.4. To verify a token, a verifier checks that Token.authenticator is a <del> valid signature over the remainder of the token input as described below.  The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask generation function (MGF), and a 48-byte salt length (sLen). </del>  6.5.

Reviewer comments:
Hexadecimal constants are used as strings without specifying the length or byte order. For example, "0x0001" might be interpreted in a couple of ways. Usually the correct interpretation is clear in context, but I'm not sure it always is.
[ ] Overall: The document is inconsistent about capitalization after colon (":"). [ ] Abstract: I'm not sure the distinction between public/private verifiability is common knowledge. It might be helpful to say plainly who is doing the verifying. E.g.: "one [variant] providing tokens whose validity can be verified by the issuer only; and another for which token validity can be verified by any party with the issuer public key." [ ] 2 Terminology: "We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire" This doesn't need to be mentioned, in my opinion. [ ] 5.1 Client-To-Issuer Request: The psedocode for computing "client_context" hard-codes a particular OPRF suite (0x0004). Is this the only suite that is permitted/recommended by the document? I don't think this is clear until the token types are defined in Section 8.1. [ ] 5.3 Finalization: Constants hardcoded instructs don't a semi-colon after the constant. (See "Token" in this section, for example.) Is this intentional? It looks a bit odd, and I'm wondering if this is "syntactically" correct. [ ] 5.4 Token Verification: I think it's worth pointing out here that creating the server context requires the Issuer Private Key, which is why VOPRF is not publicly verifiable. [ ] 7 Security Considerations: "All security considerations described in the VOPRF document also apply in the Privacy Pass use-case." What about security considerations for BLINDRSA? It might be a bit cleaner to write something like this: "Each protocol described here inherits the security considerations of its base document: For Section 5, this is [VOPRF]; ... " [ ] Acknowledgements: Sofi is acknowledged, but is also a co-author.
I think I caught all of these. Addressed in . Yes, this is much better! Addressed in . This is addressed by . We explain the constant in the sentence immediately following the pseudocode, so I don't think further clarification is needed. The semi-colon was missing, but we updated this to match what's done in RFC8446. Addressed in . Addressed in . Good catch. This has already been fixed on the editor's branch to say "All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case."

Revised text:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are  <ins> privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. </ins> 1. This document describes the issuance protocol for Privacy Pass built on HTTP.  It specifies two variants: one that is privately verifiable  <ins> using the issuance private key based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable using the issuance public key based on the blind RSA signature scheme BLINDRSA. </ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks. verifying tokens. Unless otherwise specified, this document encodes protocol messages  <ins> in TLS notation from TLS13, Section 3.  Moreover, all constants are in network byte order. </ins> 3. Issuers MUST provide two parameters for configuration:  <ins> Issuer Request URI: A token request URL for generating access </ins> tokens.  For example, an Issuer URL might be https://issuer.example.net/example-token-request.  This parameter uses resource media type "text/plain".  <ins> Issuer Public Key values: An Issuer Public Key for an issuance </ins> protocol. The Issuer parameters can be obtained from an Issuer via a directory 5.4.  <ins> To verify a token, a verifier creates a VOPRF context using the Issuer Private Key, evaluates the token contents, and compares the result against the token authenticator value, as follows: </ins> 5.5. 6.4. To verify a token, a verifier checks that Token.authenticator is a  <ins> valid signature over the remainder of the token input using the Issuer Public Key. The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask generation function (MGF), and a 48-byte salt length (sLen). </ins> 6.5.