jiebi/TextFlow huggingface dataset:
Original text:
empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation.  2.1.2. Clients can generate multiple tokens from a single TokenChallenge,

Reviewer comments:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Revised text:
empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. <ins> Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention.  Origins should consider the operational complexity of this shared state before choosing to share redemption contexts.  Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context. </ins> 2.1.2. Clients can generate multiple tokens from a single TokenChallenge,
Original text:
Issuer identity.  Tokens identify which issuers are trusted for a given issuance protocol. <del> Interactive or non-interactive.  Tokens can either be interactive or not.  An interactive token is one which requires a freshly issued token based on the challenge, whereas a non-interactive token can be issued proactively and cached for future use. </del>  Per-origin or cross-origin.  Tokens can be constrained to the Origin for which the challenge originated, or can be used across Origins. Depending on the use case, Origins may need to maintain state to <del> track redeemed tokens.  For example, Origins that accept non- interactive, cross-origin tokens SHOULD track which tokens have been redeemed already, since these tokens can be issued and then spent multiple times in response to any such challenge.  See double-spend for discussion. </del>  Origins that admit cross-origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with

Reviewer comments:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Revised text:
Issuer identity.  Tokens identify which issuers are trusted for a given issuance protocol.  <ins> Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and cache tokens.  For example, an empty redemption context always allows tokens to be issued and redeemed non-interactively, whereas a fresh and random redemption context means that the redeemed token must be issued only after the client receives the challenge. See Section 2.1.1 of HTTP-Authentication for more details. </ins> Per-origin or cross-origin.  Tokens can be constrained to the Origin for which the challenge originated, or can be used across Origins. Depending on the use case, Origins may need to maintain state to  <ins> track redeemed tokens.  For example, Origins that accept cross-origin across shared redemption contexts tokens SHOULD track which tokens have been redeemed already in those redemption contexts, since these tokens can be issued and then spent multiple times in response to any such challenge.  See Section 2.1.1 of HTTP-Authentication for discussion. </ins> Origins that admit cross-origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with
Original text:
reconstruct a Client's browsing history. Attestation and redemption context unlinkability requires that these <del> events be separated over time, e.g., through the use of non- interactive tokens that can be issued without a fresh Origin challenge, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </del>  4.2.

Reviewer comments:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Revised text:
reconstruct a Client's browsing history. Attestation and redemption context unlinkability requires that these  <ins> events be separated over time, e.g., through the use of tokens with an empty redemption context, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </ins> 4.2.
Original text:
6.1. <del> When applicable for non-interactive tokens, all Origins SHOULD implement a robust storage-query mechanism for checking that tokens sent by clients have not been spent before.  Such tokens only need to be checked for each Origin individually.  But all Origins must perform global double-spend checks to avoid clients from exploiting the possibility of spending tokens more than once against distributed token checking systems.  For the same reason, the global data storage must have quick update times.  While an update is occurring it may be possible for a malicious client to spend a token more than once. 6.2. </del> When a Client holds tokens for an Issuer, it is possible for any verifier to invoke that client to redeem tokens for that Issuer. This can lead to an attack where a malicious verifier can force a

Reviewer comments:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Revised text:
6.1.  When a Client holds tokens for an Issuer, it is possible for any verifier to invoke that client to redeem tokens for that Issuer. This can lead to an attack where a malicious verifier can force a
Original text:
previous variant in two important ways: The output tokens are publicly verifiable by anyone with the <del> Issuer public key; and </del>  The issuance protocol does not admit public or private metadata to bind additional context to tokens. <del> Otherwise, this variant is nearly identical.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer- configuration for how this key pair is generated. </del>  Clients provide the following as input to the issuance protocol:

Reviewer comments:
The publicly verifiable basic token issuance protocol doesn't include an origin name that the issuer can see, so it does allow origins to be able to use that issuer (as long as the know the key) without explicit coordination or permission from the issuer. This isn't necessarily a problem, but we should likely mention it.

Revised text:
previous variant in two important ways: The output tokens are publicly verifiable by anyone with the  <ins> Issuer public key. </ins> The issuance protocol does not admit public or private metadata to bind additional context to tokens.  <ins> 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 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 as input to the protocol.  See public-issuer-configuration for how this key pair is generated. </ins> Clients provide the following as input to the issuance protocol:
Original text:
Issuer portrayed in fig-overview can be instantiated and deployed in a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. <del> The discussion below assumes non-collusion between entities when operated by separate parties.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </del>  4.1.

Reviewer comments:
This doesn't go overboard and clarify non-collusion assumptions for all models. It simply states the requirement that entities with access to the attestation context and redemption context do not collude, and then generalizes somewhat for simplicity. cc NAME NAME
The architecture assumes that any two parties do not collude with each other. I think this is too strong an assumption. In particular, if the Origin does not collude with anyone else, what is the point of unlinkability of the issuance and redemption flows? Looking at the use cases, it seems that where the Attester and Issuer are distinct there is a needed non-collusion assumption between them to achieve desirable privacy, but I think the origin colluding with one of the Issuer or Attester should be fine and would be worth considering in scope. Also, in addition to the non-collusion assumption, are there any other assumptions made on the parties, such as honest-but-curious, or do we consider them to be potentially fully malicious? It would be nice to spell this out.
If the Origin colluded with the Issuer it would learn the client's identity (presumably), which would be bad. Ultimately, the desired property is that any sort of collusion that would allow the redemption context to be linked to the attestation context is prohibited. I'll try to clarify.

Revised text:
Issuer portrayed in fig-overview can be instantiated and deployed in a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations.  <ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to the redemption context, as collusion between such entities would enable linking of these contexts.  Generally, this means that entities operated by separate parties do not collude.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </ins> 4.1.
Original text:
used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is <del> "message/token-request".  An example request is shown below. </del>  Upon receipt of the request, the Issuer validates the following conditions:

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is  <ins> "application/private-token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:
Original text:
where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body <del> consists of TokenResponse, with the content type set as "message/ token-response". </del>  5.3.

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body  <ins> consists of TokenResponse, with the content type set as "application/ private-token-response". </ins> 5.3.
Original text:
The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request <del> is "message/token-request".  An example request is shown below, where Nk = 512. </del>  Upon receipt of the request, the Issuer validates the following conditions:

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request  <ins> is "application/private-token-request".  An example request is shown below, where Nk = 512. </ins> Upon receipt of the request, the Issuer validates the following conditions:
Original text:
The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type <del> set as "message/token-response". </del>  6.3.

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type  <ins> set as "application/private-token-response". </ins> 6.3.
Original text:
This specification defines the following protocol messages, along with their corresponding media types: <del> TokenRequest: "message/token-request" </del>  <del> TokenResponse: "message/token-response" </del>  The definition for each media type is in the following subsections. 8.2.1. <del> message </del>  <del> token-request </del>  N/A

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
This specification defines the following protocol messages, along with their corresponding media types:  <ins> TokenRequest: "application/private-token-request" </ins>  <ins> TokenResponse: "application/private-token-response" </ins> The definition for each media type is in the following subsections. 8.2.1.  <ins> application </ins>  <ins> private-token-request </ins> N/A
Original text:
8.2.2. <del> message </del>  <del> access-token-response </del>  N/A

Reviewer comments:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Revised text:
8.2.2.  <ins> application </ins>  <ins> private-token-response </ins> N/A
Original text:
its own name as one of the names in the list. When used in an authentication challenge, the "PrivateToken" scheme <del> uses the following attributes: </del>  "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not

Reviewer comments:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Revised text:
its own name as one of the names in the list. When used in an authentication challenge, the "PrivateToken" scheme  <ins> uses the following parameters: </ins> "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not
Original text:
and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. <del> This attribute is required for all challenges. </del>  "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge.

Reviewer comments:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Revised text:
and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks.  <ins> This parameter is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge.
Original text:
include padding.  As an Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the <del> base64url string includes "=" characters.  This attribute MAY be </del>  omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. <del> "max-age", an optional attribute that consists of the number of </del>  seconds for which the challenge will be accepted by the origin. Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header field MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </del>  As an example, the WWW-Authenticate header field could look like this:

Reviewer comments:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Revised text:
include padding.  As an Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the  <ins> base64url string includes "=" characters.  This parameter MAY be </ins> omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.  <ins> "max-age", an optional parameter that consists of the number of </ins> seconds for which the challenge will be accepted by the origin. Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.  <ins> The header field MAY also include the standard "realm" parameter, if desired.  Issuance protocols MAY require other parameters.  Clients SHOULD ignore unknown parameters in challenges, except if otherwise specified by issuance protocols. </ins> As an example, the WWW-Authenticate header field could look like this: