jiebi/TextFlow huggingface dataset:
Original text:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del>  "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined "token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del>  "blinded_msg" is the Nk-octet request defined above.

Reviewer comments:
Is this the most exact way to put this? For byte arrays like a hash, I generally don't think of it as being network- or host- byte order. Do we have other docs that refer to stuff like this that we can crib from?
Nothing comes to mind right now, but I'm happy to look at alternatives.
Works for me =)
We should be explicit about what this means: This means that the byte is the last/rightmost byte of the hash, in order. Misinterpretation of this caused some confusion in interop.
Here's an attempt at saying this in other words to be extra clear?

Revised text:
"token_type" is a 2-octet integer, which matches the type in the challenge.  <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined "token_type" is a 2-octet integer, which matches the type in the challenge.  <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Nk-octet request defined above.
Original text:
Reference: Where this algorithm is defined  The initial contents for this registry are defined in the table below.

Reviewer comments:
Updated to use random values
NAME please take a look!
Origins can issue challenges for greased token types, etc, to ensure client can handle new types in the future.
One type of greasing might be adding random authentication credentials to the header, e.g., .
We should recommend servers to send greased token types + parameters, as well as clients to send greased credentials.

Revised text:
Reference: Where this algorithm is defined <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 unknown token types gracefully (this technique is inspired by RFC8701).  Implemenations SHOULD select reserved values at random when including them in greased messages.  Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values.  Clients can include these in Token structures when they are not able to present a real token response.  The contents of the Token structure SHOULD be filled with random bytes when using greased values. </ins> The initial contents for this registry are defined in the table below.
Original text:
3. <del> Issuers MUST provide one parameter for configuration: </del>  Issuer Request URI: a token request URL for generating access tokens.  For example, an Issuer URL might be https://issuer.example.net/example-token-request.  This parameter uses resource media type "text/plain".  The Issuer parameters can be obtained from an Issuer via a directory <del> object, which is a JSON object whose field names and values are raw values and URLs for the parameters. </del>  <del> As an example, 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:
This is both a convenience for origins, as well as a way to support key rotation.
Thanks for this. IIUC the key rotation interval for non-rate-limited token issuance may be ambiguous. Since there is not necessarily a policy window defined in that case. Is that right? This would be manageable be convention; and trivial when a single entity controls both the issuer and origin.
Correct. The rotation window is currently not specified. Omitting that seems reasonable for this case. Origins can simply check in with issuers at some regular cadence as they deem fit.
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.

Revised text:
3.  <ins> Issuers MUST provide two parameters for configuration: </ins> Issuer Request URI: a token request URL for generating access 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 protocol. </ins> The Issuer parameters can be obtained from an Issuer via a directory  <ins> object, which is a JSON object whose values are other JSON objects and URLs for the parameters. Each "token-keys" JSON object contains the following fields and corresponding raw values. Issuers MAY advertise multiple token-keys for the same token-type to support key rotation.  In this case, Issuers indicate preference for which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. </ins>  <ins> Altogether, the Issuer's JSON 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:
privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization. <del> The mechanism by which clients obtain the Issuer public key is not specified.  Clients may be configured with this key or they may discover it via some other form.  See CONSISTENCY. </del>  Depending on the use case, issuance may require some form of Client anonymization service similar to an IP-hiding proxy so that Issuers For certain types of issuance protocols, this model separates attestation and redemption contexts.  However, Issuance protocols that require the Issuer to learn information about the Origin, such <del> as that which is described in [rate-limited], are not appropriate since they could link attestation and redemption contexts through the </del>  Origin name. 4.3. This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token <del> issuance; see [rate-limited] for one such type of issuance protocol. </del>  In this model, the Attester, Issuer, and Origin have a separate view of the Client: the Attester sees potentially sensitive Client identifying information, such as account identifiers or IP addresses,

Reviewer comments:
cc NAME
draft-ietf-privacypass-architecture says in section 3.2: Is that correct? Isn't the 'token-key' in draft-ietf-privacypass-auth-scheme providing the pub key? Or do I misunderstand something here?
Oops, yep, good catch! We'll fix this.

Revised text:
privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization.  <ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some form of key consistency check to determine if this public key is consistency and correct for the specified Issuer.  See CONSISTENCY for example mechanisms.  Depending on the deployment, the Attester may be able to assist the Client in applying these consistency checks across clients. </ins> Depending on the use case, issuance may require some form of Client anonymization service similar to an IP-hiding proxy so that Issuers For certain types of issuance protocols, this model separates attestation and redemption contexts.  However, Issuance protocols that require the Issuer to learn information about the Origin, such  <ins> as that which is described in RATE-LIMITED, are not appropriate since they could link attestation and redemption contexts through the </ins> Origin name. 4.3. This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token  <ins> issuance; see RATE-LIMITED for one such type of issuance protocol. </ins> In this model, the Attester, Issuer, and Origin have a separate view of the Client: the Attester sees potentially sensitive Client identifying information, such as account identifiers or IP addresses,
Original text:
One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens <del> without interacting with the Issuer directly. </del>  Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients.

Reviewer comments:
We current state this as the requirement: This could be misread in that we do allow forgeries when interacting with the Issuer directly. Clearly that's not the intent, so let's fix this.

Revised text:
One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens  <ins> offline or otherwise without interacting with the Issuer directly. </ins> Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients.
Original text:
to a different issuer or a different token type, to allow clients to choose a preferred issuer or type.  4. The security properties of token challenges vary depending on whether

Reviewer comments:
From IETF 114 discussion: For the general captcha use cases, we don't want websites to rely on privacy pass always working, to preventing locking out other clients. We should likely have discussion in the architecture document to suggest approaches to make sure servers can't rely on this for generic clients (like browsers). Randomly not responding with tokens, other client-side heuristics.
I would put this in the auth-scheme document, where we already discuss user experience things. I'll propose some text that we can wordsmith.

Revised text:
to a different issuer or a different token type, to allow clients to choose a preferred issuer or type. <ins> An origin MUST NOT assume that token challenges will always yield a valid token.  Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type.  Origins SHOULD account for such operational or interoperability failures by 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 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 types in token challenges with some non-zero probability. </ins> 4. The security properties of token challenges vary depending on whether
Original text:
past day.  Attesters should not admit attestation types that result in small anonymity sets.  3.2.2. Issuers MUST be uniquely identifiable by all Clients with a

Reviewer comments:
cc NAME
Over a long enough timeline, attestations will be broken - through willful post-boot compromise, malware, or other means. Services that depend on attestations (consumers of access tokens) will observe clients that appear to pass attestation, but engage in behavior that indicates that the device is compromised (e.g. trigger thousands of interactions per second). As it stands, the service consuming access tokens is not able to provide feedback that these attestations appear to be false negatives, and should be re-examined by the attester. Even if this feedback were to be provided out of band, it will be challenging for the attester to identify which devices are compromised and diagnose the nature of the compromise. I do not anticipate that this will become a pressing issue until the initial attestations are compromised, but it may be helpful to plan ahead for this scenario.
Thanks, NAME This seems like something we ought to discuss in the architecture document.

Revised text:
past day.  Attesters should not admit attestation types that result in small anonymity sets. <ins> The trustworthiness of attesters depends on their ability to correctly and reliably perform attestation during the issuance protocol.  However, in practice, certain types of attestation can vary in value over time, e.g., if the attestation process is compromised or maliciously automated.  These are considered exceptional events and require configuration changes to address the underlying cause.  For example, if attestation is compromised because of a zero-day exploit on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched. Addressing changes in attestation quality is therefore a deployment- specific task.  In Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2. Issuers MUST be uniquely identifiable by all Clients with a
Original text:
Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the <del> challenge and nonce, to the Attester or Issuer.  The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del>  One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens

Reviewer comments:
cc NAME
LGTM!
Is unconditional input secrecy meant to mean similar to unconditionally hiding? If so, this probably deserves more explanation and justification in the architecture document as a requirement; otherwise, a different term should probably be used.
To my knowledge unconditional input secrecy is the standard term here. What do you think should be added to resolve this issue?
I guess my main question is why is unconditional secrecy a requirement here?
Because we don't want the server to learn anything about the client's private input regardless of its computational power. Take blind RSA as an example, which has this property. While a PQ adversary could break RSA, it could not learn the client's private input from a protocol trace.
I think this should be spelled out explicitly; i.e., say explicitly that the client's private input should remain private even if some of the cryptographic hardness assumptions underlying the protocol become falsified. I wonder if this would be a good place to use a SHOULD vs a MUST. I can see how unconditional secrecy is a desirable property, but, e.g., TLS doesn't have it for obvious reasons.
I sent a PR for (1). I don't think we should relax (2). Future versions of the architecture can update this requirement to relax as desired.

Revised text:
Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the  <ins> challenge and nonce, to the Attester or Issuer, regardless of the hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens
Original text:
hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the <del> token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del>  One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens

Reviewer comments:
cc NAME
E.g., consider a protocol where the Issuer signs a commitment to the token challenge. This fails as an unlinkable anonymous credentials because the signature is not randomized, but is has input secrecy because of the commitment.
In this hypothetical example, is the commitment not revealed during redemption? If so, I think we could address this by saying that input secrecy is necessary but insufficient for unlinkability. Thoughts?

Revised text:
hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the  <ins> token. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens
Original text:
others may not have this property. Issuer identity.  Tokens identify which Issuers are trusted for a <del> given issuance protocol.  The selected Issuer transitively determines what types of attestation the Origin is willing to accept.  For example, if a given Issuer "issuer.example" has two trusted Attesters, then any Origin choosing "issuer.example" as its Issuer is willing to accept attestation checks done by either of these two Attesters. </del>  Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and

Reviewer comments:
cc NAME
I found this sentence hard to interpret: both because of the use "transitive" and because, AIUI, the Origin does not directly accept attestations at all. I tried to be a bit more explicit in this phrasing:
Good clarification! Please check out the linked PR where I applied a variant of your suggested text.

Revised text:
others may not have this property. Issuer identity.  Tokens identify which Issuers are trusted for a  <ins> given issuance protocol.  Each Issuer, in turn, determines which Attesters it is willing to accept in the issuance protocol.  This means that if an Origin origin.example accepts tokens issued by Issuer issuer.example, and that Issuer in turn accepts different types of attestation from more than one trusted Attester, then a Client may use either of these trusted Attesters to issue and redeem tokens for origin.example.  However, origin.example neither explicitly specifies nor learns the Attesters or their attestation formats used for token issuance. </ins> Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and
Original text:
types of participants, underlying cryptographic constructions used when issuing tokens, and even privacy properties. <del> Clients initiate the Token issuance protocol using the challenge, a randomly generated nonce, and public key for the Issuer.  The Token issuance protocol itself can be any interactive protocol between </del>  Client, Issuer, or other parties that produces a valid authenticator <del> over the Client's input, subject to the following security </del>  requirements. Unconditional input secrecy.  The issuance protocol MUST NOT

Reviewer comments:
This clarifies the inputs to the issuance protocol as constrained by the current HTTP authentication document. It also notes that these inputs may change in the future to accommodate different issuance protocols and Token formats. cc NAME NAME
The input secrecy requirement suggests that client private input would include the nonce, challenge, but doesn't give any ideas what else might be part of the private input: Why is it important to have a client nonce? Is this something that needs to be spelled out in the architecture document or left to the particular issuance protocol specifications?
The issuance protocol only takes as input the TokenChallenge and client-generated nonce, both of which are considered private. It doesn't take anything else as input. We should just say that directly. A client nonce is a required part of the Token structure.

Revised text:
types of participants, underlying cryptographic constructions used when issuing tokens, and even privacy properties.  <ins> Clients initiate the issuance protocol using the challenge, a randomly generated nonce, and public key for the Issuer, all of which are the Client's private input to the protocol and ultimately bound to an output Token; see Section 2.2. of HTTP-Authentication for details.  Future specifications may change or extend the Client's input to the issuance protocol to produce Tokens with a different structure. The issuance protocol itself can be any interactive protocol between </ins> Client, Issuer, or other parties that produces a valid authenticator  <ins> over the Client's private input, subject to the following security </ins> requirements. Unconditional input secrecy.  The issuance protocol MUST NOT
Original text:
5.4.  A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants.{ were chosen.  As a result, clients could have more opportunities to switch between attestation participants. <del> 6. </del>  Beyond the aforementioned security goals for the issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to

Reviewer comments:
cc NAME NAME
The privacy considerations section should probably include a discussion on timing correlation. The timing issues are non-trivial here; in particular, in the scenarios where the token is issued online in response to a token challenge (which is suggested in all of the diagrams, and which is required if the origin requires session-bound tokens). In that case, the anonymity set of issuance flows that could match a redemption flow is limited to those that started after the challenge was sent and ended before the token was redeemed. Even if process takes a second (which seems slow to me), you need a fairly popular issuer service to get a non-trivial anonymity set, and any (obviously desirable) improvements in the latency of this process put further pressure on the anonymity set. I think there should be a caution against deploying PrivacyPass in a setting where the issuance rate can be low, at least in combination with session-bound context.
This is a good suggestion! I proposed text that adds this under the privacy considerations section.

Revised text:
5.4. <ins> Side-channel attacks, such as those based on timing correlation, could be used to link attestation and redemption contexts together. In particular, for interactive tokens that are bound to a Client- specific redemption context, the anonymity set of Clients during the issuance protocol consists of those Clients that started issuance between the time of the Origin's challenge and the corresponding token redemption.  Depending on the number of Clients using a particular Issuer during that time window, the set can be small. Appliations should take such side channels into consideration before choosing a particular deployment model and type of token challenge and redemption context. 6. </ins> A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants.{ were chosen.  As a result, clients could have more opportunities to switch between attestation participants.  <ins> 7. </ins> Beyond the aforementioned security goals for the issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to