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

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

Discussion:
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> <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 <del> previous variant in two important ways: </del> <ins> previous variant in that the output tokens are publicly verifiable by anyone with the Issuer public key. </ins> <del> The output tokens are publicly verifiable by anyone with the Issuer public key. </del> <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> <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> <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
Change:
From NAME
This should probably just invoke from RFC8017 directly, since the named variants we allow for this token type must use PSS.

Discussion:
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> <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.
Change:
This should presumably say "for ensuring that client privacy does not leak" or "to prevent client privacy leaks."

Discussion:
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> <ins> choices that are necessary for deployment and application specific choices for protecting client privacy.  This information is covered in ARCHITECTURE. </ins> 2.
Change:
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.

Discussion:
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> <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 <del> pair SHALL be generated as as specified in FIPS 186-4 DSS. </del> <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-
Change:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.

Discussion:
The Issuer parameters can be obtained from an Issuer via a directory object, which is a JSON object (RFC8259, Section 4) whose values are <del> other JSON values (RFC8259, Section 3) for the parameters. </del> <ins> other JSON values (RFC8259, Section 3) for the parameters.  The contents of this JSON object are defined in directory-values. </ins> <del> Each "token-keys" JSON object contains the following fields and corresponding raw values. </del> <ins> Each "token-keys" JSON object contains the fields and corresponding raw values defined in tokenkeys-values. </ins> Issuers MAY advertise multiple token-keys for the same token-type to support key rotation.  In this case, Issuers indicate preference for

Altogether, the Issuer's 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- directory; see wkuri-reg for the registration information for this well-known URI. </del> <ins> Issuer directory resources have the media type "application/token- issuer-directory" and are located at the well-known location /.well- known/token-issuer-directory; see wkuri-reg for the registration information for this well-known URI. </ins> 4.

8. <ins> This section contains considerations for IANA. </ins> 8.1. This document updates the "Well-Known URIs" Registry WellKnownURIs

This specification defines the following protocol messages, along with their corresponding media types: <ins> Token issuer directory: "application/token-issuer-directory" </ins> TokenRequest: "application/private-token-request" TokenResponse: "application/private-token-response"

application <del> private-token-request </del> <ins> token-issuer-directory </ins> N/A

application <ins> private-token-request N/A None "binary" see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 8.3.3. application </ins> private-token-response N/A
Change:
doesn't define . The preceding text to the example says that Nk is 512, but AFAICT the value of Nk is not relevant to the example.
Section 8.2 defines Nk=256 for type 0x0002. Section 6.1 should still apply for any value Nk if another type is added for a different size key. My two suggestions would be: (1) mention in Section 6.1 that Nk is fixed according to the token type definition and (2) use Nk=256 for the example so it matches the only currently defined blind token type (0x0002).

Discussion:
DeriveKeyPair. The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for <del> OPRF(P-384, SHA-384). </del> <ins> OPRF(P-384, SHA-384).  The constant "Nk" is defined by private-token- type. </ins> 5.1.

this might be provided by the redemption protocol in AUTHSCHEME. Given this configuration and these inputs, the two messages exchanged <del> in this protocol are described below. </del> <ins> in this protocol are described below.  The constant "Nk" is defined by public-token-type. </ins> 6.1.
Change:
Are the changes to other files on this one intentional NAME ?
Oh, hrm, no, they're not. I'll remove them.
NAME fixed!
There are several related issues in URL Should the well-known location require mTLS? The two well-known public implementations previously highlighted by Apple disagree on this point. Our opinion: mTLS should not be required for the token issuer directory. is underspecified. Should this be an absolute URI, a relative URI, or allow either format? Our opinion: We prefer relative URIs, and think either option should be supported. A relative URI is also used by at least one well-known public implementation.
No. That's deployment specific decision. Either is fine, as evidenced by current implementations. We'll make this clear.
Since this URI is intended to be used as a URL later in the protocol -- and the description in fact calls it a URL -- would it be cleaner to name the parameter "Issuer Request URL"/? What "thing" is actually ? The directory itself is , the resulting content is JSON (whose strings do not carry a notion of media types), and the token request/response using this URI use /.
I think just dropping the media type mention at all is probably best here. It's just a URL string, so let's just call it that. Does work for you?
That looks much better. Should the parameter also be ?

Discussion:
Issuers MUST provide two parameters for configuration: <del> Issuer Request URI: A token request URL for generating access </del> <ins> Issuer Request URL: A token request URL for generating access </ins> tokens.  For example, an Issuer URL might be <del> https://issuer.example.net/request.  This parameter uses resource media type "text/plain". </del> <ins> https://issuer.example.net/request. </ins> Issuer Public Key values: A list of Issuer Public Keys for the issuance protocol.
Change:
ends with two paragraphs that really belong in Section 5.2, because they are about the processing of the request.

Discussion:
"application/private-token-request".  An example request is shown below. <ins> 5.2. </ins> Upon receipt of the request, the Issuer validates the following conditions:

The TokenRequest.blinded_msg is of the correct size. If any of these conditions is not met, the Issuer MUST return an HTTP <del> 400 error to the client. 5.2. Upon receipt of a TokenRequest, the Issuer tries to deseralize </del> <ins> 400 error to the client.  The Issuer then tries to deseralize </ins> TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is

request is "application/private-token-request".  An example request is shown below: <ins> 6.2. </ins> Upon receipt of the request, the Issuer validates the following conditions:

If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client. <del> 6.2. If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </del> <ins> Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </ins> This is encoded and transmitted to the client in the following TokenResponse structure:
Change:
Rewrite parts of intro Clean up protocol overview Rewrite API functions Rewrite protocol instantiation Update ciphersuites (This is a big change, apologies!) cc NAME NAME for reviews (will also notify mailing list).
API has been updated at URL quite substantially.
SecretKey, to me, implies a symmetric key. Can we make this PrivateKey? That's the terminology used (mostly) in RFC7748, at least.
Done in

Discussion:
6.3.2. <ins> For this functionality, note that we supply multiple tokens in "msg" to "Evaluate".  This allows batching a single proof object for multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf only permits a single input, we follow the advice for providing vectors of inputs. </ins> 6.3.3. <ins> Similarly to "Issue", we follow the advice for providing vectors of inputs to the "Unblind" function for verifying the batched proof object. </ins> 6.3.4. 6.3.5.
Change:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.

Discussion:
type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, token-types. Challenges with unsupported token_type values MUST be ignored. <ins> This value determines the structure and semantics of the rest of the structure. </ins> "issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed

The structure fields are defined as follows: "token_type" is a 2-octet integer, in network byte order.  This <del> value must match the value in the challenge (challenge). </del> <ins> value must match the value in the challenge (challenge).  This value determines the structure and semantics of the rest of the structure. </ins> "nonce" is a 32-octet message containing a client-generated random nonce.

Name: Name of the issuance protocol <ins> Token Structure: The contents of the Token structure TokenChallenge Structure: The contents of the TokenChallenge structure </ins> Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable

Name: Private Use <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: N/A Public Metadata: N/A

Name: VOPRF (P-384, SHA-384) <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: N Public Metadata: N

Name: Blind RSA (2048-bit) <ins> Token Structure: As defined in TokenChallenge Structure: As defined in </ins> Publicly Verifiable: Y Public Metadata: N

The Privacy Pass architecture consists of four logical entities - Client, Origin, Issuer, and Attester - that work in concert for token redemption and issuance.  This section describes the purpose of token <del> redemption and issuance and the requirements on the relevant participants. </del> <ins> the redemption and issuance protocols and the requirements on the relevant participants. </ins> The typical interaction flow for Privacy Pass uses the following steps:

opportunistically present Token values to Origins without a corresponding TokenChallenge. <ins> The structure and semantics of the TokenChallenge and Token messages depend on the issuance protocol and token type being used; see AUTHSCHEME for more information. </ins> The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept in the redemption context.  There are a number of ways in which the token

redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. <ins> The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; see ISSUANCE for more information. </ins> Clients interact with the Attester and Issuer to produce a token in response to a challenge.  The context in which an Attester vouches for a Client during issuance is referred to as the attestation
Change:
The interaction model here doesn't really need to use HTTP as far as I can tell. Obviously, the specific protocols need to be more concrete, but the architecture works without specifically saying that the interactions use HTTP. The overview specifically mentions HTTP only with respect to the Client-Origin interactions, not other interactions, but I can't see how this is necessary.
No, it doesn't need to use HTTP. The auth scheme document that instantiates the challenges and redemption does use HTTP, but other mechanisms can be used.
I'm OK de-emphasizing HTTP in the architecture if it helps simplify the presentation. Beyond it overly restrictive, was there another reason that led to this issue, NAME
Only that I know that this has obvious applications beyond HTTP and the architecture has no direct need to use it.
Request/response is still a bit implying HTTP, but I'm OK with this change.

Discussion:
Privacy Pass is an architecture for authorization based on privacy- preserving authentication mechanisms.  Typical approaches for <del> authorizing clients, such as through the use of long-term cookies, are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information.  These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </del> <ins> authorizing clients, such as through the use of long-term state (cookies), are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information. These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </ins> At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance.  The redemption protocol,

The typical interaction flow for Privacy Pass uses the following steps: <del> A Client interacts with an Origin by sending an HTTP request.  The Origin sends an HTTP response that contains a token challenge that indicates a specific Issuer to use.  Note that the request might be made as part of accessing a resource normally, or with the specific intent of triggering a token challenge. </del> <ins> A Client interacts with an Origin by sending a request or otherwise interacting with the Origin in a way that triggers a response containing a token challenge.  The token challenge indicates a specific Issuer to use. </ins> If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of