jiebi/TextFlow huggingface dataset:
Original text:
for experimentation with protocols being developed.  Designated experts review, approve, and revoke provisional registrations.  This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle

Reviewer comments:
To allow experimentation and private types, define a portion of the token type registry to be reserved for private use.

Revised text:
for experimentation with protocols being developed.  Designated experts review, approve, and revoke provisional registrations. <ins> Values 0xFF00-0xFFFF are reserved for private use, to enable proprietary uses and limited experimentation. </ins> This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle
Original text:
should be deployed to ensure the privacy of clients and the security of all participating entities.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL

Revised text:
should be deployed to ensure the privacy of clients and the security of all participating entities. <ins> The privacypass working group is working on HTTP-Authentication as an instantiation of a redemption protocol and ISSUANCE as an instantiation of the issuance protocol. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
clients. Applications SHOULD constrain tokens to a single origin unless the <del> use case can accommodate such replay attacks. </del>  All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness.

Reviewer comments:
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.

Revised text:
clients. Applications SHOULD constrain tokens to a single origin unless the  <ins> use case can accommodate such replay attacks.  Replays are also possible if the client redeems a token sent as part of 0-RTT data. If successful token redemption produces side effects, origins SHOULD implement an anti-replay mechanism to mitigate the harm of such replays.  See RFC8446, Section 8 and RFC9001, Section 9.2 for details about anti-replay mechanisms, as well as RFC8470, Section 3 for discussion about safety considerations for 0-RTT HTTP data. </ins> All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness.
Original text:
by the token_type and corresponding issuance protocol. The authenticator value in the Token structure is computed over the <del> token_type, nonce, context, and token_key_id fields. </del>  When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-

Reviewer comments:
Suspect the prose is not aligned with the structure, it says but there is no field in .
Yup, that should say . The name changed.

Revised text:
by the token_type and corresponding issuance protocol. The authenticator value in the Token structure is computed over the  <ins> token_type, nonce, challenge_digest, and token_key_id fields. </ins> When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-
Original text:
challenges with some non-zero probability.  Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non- zero probability.  Moreover, origins SHOULD include random token <del> types in token challenges with some non-zero probability. </del>  4.

Reviewer comments:
The spec recommends some greasing in Section 3 In section 5.2, several token types are reserved as greased values. Is the expectation really that origins pick "random" token types, or with non-zero global probability across clients, randomly pick from the set of reserved token types?
This should probably read from the list of reserved GREASE values, rather than random token types (the latter can cause interop issues).
Yeah, that sounds good,

Revised text:
challenges with some non-zero probability.  Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non- zero probability.  Moreover, origins SHOULD include random token  <ins> types, from the Reserved list of "greased" types (defined in token- types), with some non-zero probability. </ins> 4.
Original text:
Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin <del> names containing the origin. </del>  The TokenChallenge message has the following structure: the length, in network byte order.  If empty, any non-origin- specific token can be redeemed.  If the string contains multiple origin names, they are delimited with commas "," without any <del> whitespace. </del>  When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

Reviewer comments:
Spec says: and and also The sender requirements are implicit. I'm guessing that the sender also MUST include it's own origin name in the non-empty case. Should the spec just state that?

Revised text:
Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin  <ins> names containing the origin itself. </ins> The TokenChallenge message has the following structure: the length, in network byte order.  If empty, any non-origin- specific token can be redeemed.  If the string contains multiple origin names, they are delimited with commas "," without any  <ins> whitespace.  If this field is not empty, the Origin MUST include its own name as one of the names in the list. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:
Original text:
support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the <del> authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid.  For example, clients can choose to reject challenges that list origin </del>  names for which current connection is not authoritative (according to the TLS certificate).

Reviewer comments:
For example, What happens if validation fails here, is the challenge simply ignored or should the client do something more drastic?

Revised text:
support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the  <ins> authentication challenge is included in the list of origin names; if validation fails, the client MUST NOT process or respond to the challenge.  Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to ignore challenges that list origin </ins> names for which current connection is not authoritative (according to the TLS certificate).
Original text:
1. Privacy Pass tokens are unlinkable authenticators that can be used to <del> anonymously authorize a client (see ARCHITECTURE).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </del>  Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.

Reviewer comments:
From editor copy today: I found this intro to be a bit clunky. I didn't read the ARCHITECTURE reference yet but don't think that should be a prerequisite to comprehension of the first para. How about something like

Revised text:
1. Privacy Pass tokens are unlinkable authenticators that can be used to  <ins> anonymously authorize a client (see ARCHITECTURE).  Tokens are generated by token issuers, on the basis of authentication, attestation, or some previous action such as solving a CAPTCHA.  A client possessing such a token is able to prove that it was able to get a token issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow. </ins> Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.
Original text:
Public Key: The public key used by the Issuer for issuing and verifying tokens. <del> We assume that all protocol messages are encoded into raw byte format before being sent across the wire. </del>  3.

Reviewer comments:
This is probably just a nitpick but I don't understand what you're assuming here. If the messages are encoded as raw byte format, isn't that really what the document is all about? Maybe what you want to be saying is more like whats in the ?

Revised text:
Public Key: The public key used by the Issuer for issuing and verifying tokens.  <ins> Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. </ins> 3.
Original text:
protocol. The Issuer parameters can be obtained from an Issuer via a directory <del> object, which is a JSON object whose values are other JSON objects and URLs for the parameters. </del>  Each "token-keys" JSON object contains the following fields and corresponding raw values. which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. <del> Altogether, the Issuer's JSON directory could look like: </del>  Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-

Reviewer comments:
The configuration section lists several requirements that depend on JSON, but a JSON specification is not given. I'm guessing you probably want URL
Issuers MUST provide a configuration , so what spec should they be referring to in order to ensure that this URI is well formed? I started wondering about how percent-encoding might apply, and that got me on to thinking whether you really want to support something like `"issuer-request-uri": "https://EMAIL:123/forum/questions/?tag=networking&order=newest#top",
Unless I'm missing something, I don't think there should be any constraints on how the URI is constructed. We should say something about how it's encoded, though. That's a good point.

Revised text:
protocol. The Issuer parameters can be obtained from an Issuer via a directory  <ins> object, which is a JSON object RFC8259, Section 4 whose values are other JSON values RFC8259, Section 3 for the parameters. </ins> Each "token-keys" JSON object contains the following fields and corresponding raw values. which token key to use based on the order of keys in the list, with preference given to keys earlier in the list.  <ins> Altogether, the Issuer's directory could look like: </ins> Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-
Original text:
Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer- <del> directory. </del>  4. 8.1.  This document updates the "Token Type" Registry with the following values. <del> 8.2. </del>  This specification defines the following protocol messages, along with their corresponding media types: The definition for each media type is in the following subsections. <del> 8.2.1. </del>  application IESG <del> 8.2.2. </del>  application

Reviewer comments:
While we're here, I'd like to recommend we align the name of this well-known value to align with the request/response names. In particular, what do folks think about "/well-known/private-token-issuer-directory"?
you're probably missing a registration for your well-known in the IANA considerations, the registry is URL

Revised text:
Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-  <ins> directory; see wkuri-reg for the registration information for this well-known URI. </ins> 4. 8.1. <ins> This document updates the "Well-Known URIs" Registry WellKnownURIs with the following values. 8.2. </ins> This document updates the "Token Type" Registry with the following values.  <ins> 8.3. </ins> This specification defines the following protocol messages, along with their corresponding media types: The definition for each media type is in the following subsections.  <ins> 8.3.1. </ins> application IESG  <ins> 8.3.2. </ins> application
Original text:
Reference: Where this algorithm is defined  New entries in this registry are subject to the Specification Required registration policy (RFC8126, Section 4.6).  Designated experts need to ensure that the token type is sufficiently clearly

Reviewer comments:
We need a field to list some extra information about the blind RSA variants. Additional PR incoming for that change.

Revised text:
Reference: Where this algorithm is defined <ins> Notes: Any notes associated with the entry </ins> New entries in this registry are subject to the Specification Required registration policy (RFC8126, Section 4.6).  Designated experts need to ensure that the token type is sufficiently clearly
Original text:
offering clients an alternative type of challenge such as CAPTCHA for accessing a resource.  To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to.  In particular, clients SHOULD ignore token

Reviewer comments:
NAME can you give this a quick look and merge if you're OK with it?
I'll just merge it and we can revise if needed
If a server wants to use this auth scheme but the client doesn't support it, what's supposed to happen? Do you have a way for the server to discover that the client does support it?
If the client doesn't support the scheme, it will ignore challenges — this is the same as cases where the client doesn't support a particular token type, or it fails to fetch a token for any reason. This has a useful privacy property in that it doesn't leak information about if the client couldn't fetch a token or if just doesn't support tokens, or chooses not to try to fetch a token.
We do comment on server behavior here:
We can give a simple example where the origin sends a 401 response with a body that is a CAPTCHA, such that clients that don't support this see that instead of using a token.
An example like that would be good, but this makes me wonder: did we ever consider expressing the client's capability to support this token via a CH? I don't remember if we did or not.
I think adding a new fingerprinting surface for that in CH isn't great. There's talk instead of having a javascript capability API for the support.
I don't really think the fingerprinting concern is that significant. If a client supports it, then a server can more than likely (with very high probability) just probe it for a token and confirm its guess. The lack of a hint just makes the server's life more difficult without offering any meaningful privacy improvement to the client. In principle, the less signals the better, but this is a signal that can be determined anyway.
To be clear, I'm not suggesting that we actually propose a CH for this. I'm just raising the thought experiment.

Revised text:
offering clients an alternative type of challenge such as CAPTCHA for accessing a resource. <ins> For example, consider a scenario in which the client is a web browser, and the origin can accept either a token or a solution to a puzzle intended to determine if the client is a real human user.  The origin would send clients a 401 HTTP response that contains a token challenge in a "WWW-Authenticate" header field along with content that contains the puzzle to display to the user.  Clients that are able to respond with a token will be able to automatically return the token and not show the puzzle, while clients that either do not support tokens or are unable to fetch tokens at a particular time can present the user with the puzzle. </ins> To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to.  In particular, clients SHOULD ignore token
Original text:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable, and another that produces tokens that are <del> publicly verifiable.  The privately verifiable issuance protocol optionally supports public metadata during the issuance flow. </del>  1. This section describes a variant of the issuance protocol in private- flow for producing publicly verifiable tokens.  It differs from the <del> previous variant in two important ways: </del>  <del> The output tokens are publicly verifiable by anyone with the Issuer public key. </del>  <del> The issuance protocol does not admit public or private metadata to bind additional context to tokens. The first property means that any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. Beyond these differences, the publicly verifiable issuance protocol </del>  variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens

Reviewer comments:
From NAME issuance flow." Where does this metadata come up in the protocol? As far as I can tell, the two protocols look functionally equivalent modulo who can verify. Perhaps you removed metadata at some point? In particular, double check that the following claim in Section 6 is accurate: "The issuance protocol does not admit public or private metadata to bind additional context to tokens."

Revised text:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable, and another that produces tokens that are  <ins> publicly verifiable. </ins> 1. This section describes a variant of the issuance protocol in private- flow for producing publicly verifiable tokens.  It differs from the  <ins> previous variant in that the output tokens are publicly verifiable by anyone with the Issuer public key. </ins>  <ins> This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </ins>  <ins> Beyond this difference, the publicly verifiable issuance protocol </ins> variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens
Original text:
To verify a token, a verifier checks that Token.authenticator is a valid signature over the remainder of the token input as described <del> below.  The function "RSA-Verify(msg, pk, sig)" is a procedure to verify a signature "sig" over message "msg" using the public key "pk".  Its implementation is not specified in this document. </del>  6.5.

Reviewer comments:
From NAME
This should probably just invoke from RFC8017 directly, since the named variants we allow for this token type must use PSS.

Revised text:
To verify a token, a verifier checks that Token.authenticator is a valid signature over the remainder of the token input as described  <ins> 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). </ins> 6.5.
Original text:
issuance public key based on the blind RSA signature scheme BLINDRSA. This document does not cover the Privacy Pass architecture, including <del> choices that are necessary for ensuring that client privacy leaks. This information is covered in ARCHITECTURE. </del>  2.

Reviewer comments:
This should presumably say "for ensuring that client privacy does not leak" or "to prevent client privacy leaks."

Revised text:
issuance public key based on the blind RSA signature scheme BLINDRSA. This document does not cover the Privacy Pass architecture, including  <ins> choices that are necessary for deployment and application specific choices for protecting client privacy.  This information is covered in ARCHITECTURE. </ins> 2.
Original text:
5.5. Issuers are configured with Private and Public Key pairs, each <del> denoted "skI" and "pkI", respectively, used to produce tokens.  A RECOMMENDED method for generating key pairs is as follows: </del>  The key identifier for a public key "pkI", denoted "token_key_id", is computed as follows: Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens.  Each key <del> pair SHALL be generated as as specified in FIPS 186-4 DSS. </del>  The key identifier for a keypair (skI, pkI), denoted "token_key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-

Reviewer comments:
diverges from . In the earlier section: In the latter, this approximates to: ... with no 0x0002.
I would be fine with adding a token type separator to the type2 variant. It's a simple enough change to make and deploy right now. NAME NAME thoughts?
NAME is there a reason the type 1 key ID needs 0x0001 concatenated to it?
We did this for separation between privacy pass and other potential uses of the same key. I don't remember exactly why we didn't do this for type2.
Had a call, proposing to make things consistent by removing the for Type 1, since it doesn't seem to add any benefit, since the token_input is already binding the protocol to the type and challenge. Also recommending adding more text (in security considerations) to make it very clear that keys ought to not be reused across protocols.

Revised text:
5.5. Issuers are configured with Private and Public Key pairs, each  <ins> denoted "skI" and "pkI", respectively, used to produce tokens.  These keys MUST NOT be reused in other protocols.  A RECOMMENDED method for generating key pairs is as follows: </ins> The key identifier for a public key "pkI", denoted "token_key_id", is computed as follows: Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens.  Each key  <ins> pair SHALL be generated as as specified in FIPS 186-4 DSS.  These key pairs MUST NOT be reused in other protocols. </ins> The key identifier for a keypair (skI, pkI), denoted "token_key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-