jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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 <del> over the Client's input, subject to the following security </del> <ins> over the Client's private input, subject to the following security </ins> requirements. Unconditional input secrecy.  The issuance protocol MUST NOT
Change:
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.

Discussion:
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. <del> 6. </del> <ins> 7. </ins> Beyond the aforementioned security goals for the issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to
Change:
To allow experimentation and private types, define a portion of the token type registry to be reserved for private use.

Discussion:
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
Change:
[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

Discussion:
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",
Change:
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.

Discussion:
clients. Applications SHOULD constrain tokens to a single origin unless the <del> use case can accommodate such replay attacks. </del> <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.
Change:
Suspect the prose is not aligned with the structure, it says but there is no field in .
Yup, that should say . The name changed.

Discussion:
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> <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-
Change:
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,

Discussion:
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> <ins> types, from the Reserved list of "greased" types (defined in token- types), with some non-zero probability. </ins> 4.
Change:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list

Discussion:
protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </del> <ins> client, using the "WWW-Authenticate" HTTP header field.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to <del> an origin, using the "Authorization" HTTP header. </del> <ins> an origin, using the "Authorization" HTTP header field. </ins> 2.

2.1. Origins send a token challenge to clients in an "WWW-Authenticate" <del> header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. </del> <ins> header field with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. </ins> Origins that support this authentication scheme need to handle the following tasks:

Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header MAY also include the standard "realm" attribute, if </del> <ins> The header field MAY also include the standard "realm" attribute, if </ins> desired.  Issuance protocols MAY require other attributes. <del> As an example, the WWW-Authenticate header could look like this: </del> <ins> As an example, the WWW-Authenticate header field could look like this: </ins> Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the

Caching and pre-fetching of tokens is discussed in caching. <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </del> <ins> Note that it is possible for the WWW-Authenticate header field to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header field could look like this: </ins> Origins should only include challenges for different types of issuance protocols with functionally equivalent properties.  For

credentials MUST be ignored. Clients present this Token structure to origins in a new HTTP request <del> using the Authorization header as follows: </del> <ins> using the Authorization header field as follows: </ins> For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate
Change:
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?

Discussion:
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> <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 <del> whitespace. </del> <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:
Change:
For example, What happens if validation fails here, is the challenge simply ignored or should the client do something more drastic?

Discussion:
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> <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).
Change:
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

Discussion:
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> <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.
Change:
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 ?

Discussion:
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> <ins> Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. </ins> 3.
Change:
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.

Discussion:
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> <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. <del> Altogether, the Issuer's JSON directory could look like: </del> <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-
Change:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!

Discussion:
5. The Privacy Pass issuance protocol is a two message protocol that <del> takes as input a challenge from the redemption protocol and produces a token, as shown in the figure below. </del> <ins> takes as input a TokenChallenge from the redemption protocol AUTHSCHEME, Section 2.1 and produces a Token AUTHSCHEME, Section 2.2, as shown in the figure below. </ins> Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See

computed as described in issuer-configuration. Challenge value "challenge", an opaque byte string.  For example, <del> this might be provided by the redemption protocol in HTTP- Authentication. </del> <ins> this might be provided by the redemption protocol in AUTHSCHEME. </ins> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.  This section uses notation

computed as described in public-issuer-configuration. Challenge value "challenge", an opaque byte string.  For example, <del> this might be provided by the redemption protocol in HTTP- Authentication. </del> <ins> this might be provided by the redemption protocol in AUTHSCHEME. </ins> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.

The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in <del> HTTP-Authentication as follows: </del> <ins> AUTHSCHEME as follows: </ins> The Token.nonce value is that which was sampled in private-request. If the rsabssa_finalize function fails, the Client aborts the

8.2. <del> This document updates the "Token Type" Registry with the following values. </del> <ins> This document updates the "Token Type" Registry from AUTHSCHEME, Section 5.2 with the following values. </ins> 8.3.
Change:
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

Discussion:
Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer- <del> directory. </del> <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. <del> 8.2. </del> <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. <del> 8.2.1. </del> <ins> 8.3.1. </ins> application

IESG <del> 8.2.2. </del> <ins> 8.3.2. </ins> application