jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-privacypass-protocol

Commentary: 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 . thoughts ? 
 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 do n't remember exactly why we did n't do this for type2 . 
 Had a call , proposing to make things consistent by removing the for Type 1 , since it does n'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 .
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens.  Each key
pair SHALL be generated as as specified in FIPS 186-4 DSS.
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens.  Each key
pair SHALL be generated as as specified in FIPS 186-4 DSS.  These key
pairs MUST NOT be reused in other protocols.
Draft: draft-ietf-privacypass-protocol

Commentary: This should presumably say " for ensuring that client privacy does not leak " or " to prevent client privacy leaks . "
This document does not cover the Privacy Pass architecture, including
choices that are necessary for ensuring that client privacy leaks.
This information is covered in ARCHITECTURE.
This document does not cover the Privacy Pass architecture, including
choices that are necessary for deployment and application specific
choices for protecting client privacy.  This information is covered
in ARCHITECTURE.
Draft: draft-ietf-privacypass-protocol

Commentary: From 
 This should probably just invoke from RFC8017 directly , since the named variants we allow for this token type must use PSS .
To verify a token, a verifier checks that Token.authenticator is a
valid signature over the remainder of the token input as described
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.
To verify a token, a verifier checks that Token.authenticator is a
valid signature over the remainder of the token input as described
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).
Draft: draft-ietf-privacypass-protocol

Commentary: From 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 . "
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
publicly verifiable.  The privately verifiable issuance protocol
optionally supports public metadata during the issuance flow.
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
publicly verifiable.
The output tokens are publicly verifiable by anyone with the
Issuer public key.
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
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.
This section describes a variant of the issuance protocol in private-
flow for producing publicly verifiable tokens.  It differs from the
previous variant in that the output tokens are publicly verifiable by
anyone with the Issuer public key.
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.
Beyond this difference, 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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: 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 does n'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 does n't support the scheme , it will ignore challenges — this is the same as cases where the client does n'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 does n't leak information about if the client could n't fetch a token or if just does n'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 do n'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 do n't remember if we did or not . 
 I think adding a new fingerprinting surface for that in CH is n't great . There 's talk instead of having a javascript capability API for the support . 
 I do n'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 .
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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: What is this illustration trying to convey ? I found it confusing .
Clients and relying parties interact using this scheme to perform the
token challenge and token redemption flow.  Clients use a token
issuance protocol to actually fetch tokens to redeem.
Clients and relying parties (origins) interact using this scheme to
perform the token challenge and token redemption flow.  In
particular, origins challenge clients for a token with an HTTP
Authentication challenge (using the WWW-Authenticate response header
field).  Clients then respond to that challenge with an HTTP
authentiation response (using the Authorization request header
field).  Clients produce an authentication response based on the
origin's token challenge by running the token issuance protocol
ISSUANCE.  The act of presenting a token in an Authorization request
header is referred to as token redemption.  This interaction between
client and origin is shown below.
Token redemption: An action by which a client presents a token to
an origin, using the "Authorization" HTTP header field.
Token redemption: An action by which a client presents a token to
an origin in an HTTP request, using the "Authorization" HTTP
header field.
Draft: draft-ietf-privacypass-protocol

Commentary: ... I think . I 'm double checking to see if there is any other improper HTTP usage . 
 The Issuance protocol depends on HTTP , so I 'd expect this to be cited . Then we get into the HTTP terminology alignment game . For example , where the document says something like should be substituted for as per
This document describes the issuance protocol for Privacy Pass.  It
specifies two variants: one that is privately verifiable based on the
oblivious pseudorandom function from OPRF, and one that is publicly
verifiable based on the blind RSA signature scheme BLINDRSA.
This document describes the issuance protocol for Privacy Pass built
on HTTP.  It specifies two variants: one that is privately verifiable
based on the oblivious pseudorandom function from OPRF, and one that
is publicly verifiable based on the blind RSA signature scheme
BLINDRSA.
The values "token_input" and "blinded_element" are stored locally and
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
"application/private-token-request".  An example request is shown
below.
The values "token_input" and "blinded_element" are stored locally and
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 content.  The media type for this request is
"application/private-token-request".  An example request is shown
below.
The Issuer generates an HTTP response with status code 200 whose body
consists of TokenResponse, with the content type set as "application/
private-token-response".
The Issuer generates an HTTP response with status code 200 whose
content consists of TokenResponse, with the content type set as
"application/private-token-response".
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 "application/private-token-request".  An example request is shown
below, where Nk = 512.
The Client then generates an HTTP POST request to send to the Issuer,
with the TokenRequest as the content.  The media type for this
request is "application/private-token-request".  An example request
is shown below, where Nk = 512.
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
set as "application/private-token-response".
The rsabssa_blind_sign function is defined in BLINDRSA,
Section 5.1.2..  The Issuer generates an HTTP response with status
code 200 whose content consists of TokenResponse, with the content
type set as "application/private-token-response".
Draft: draft-ietf-privacypass-protocol

Commentary: 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
Issuer directory resources have the media type "application/json" and
are located at the well-known location /.well-known/token-issuer-
directory.
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.
This document updates the "Well-Known URIs" Registry WellKnownURIs
with the following values.
Draft: draft-ietf-privacypass-protocol

Commentary: 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 does n'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 !
The Privacy Pass issuance protocol is a two message protocol that
takes as input a challenge from the redemption protocol and produces
a token, as shown in the figure below.
The Privacy Pass issuance protocol is a two message protocol that
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.
This document updates the "Token Type" Registry with the following
values.
This document updates the "Token Type" Registry from AUTHSCHEME,
Section 5.2 with the following values.
Draft: draft-ietf-privacypass-protocol

Commentary: The configuration section lists several requirements that depend on  , but a JSON specification is not given . I 'm guessing you probably want 
 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 " : " " , 
 Unless I 'm missing something , I do n'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 .
The Issuer parameters can be obtained from an Issuer via a directory
object, which is a JSON object whose values are other JSON objects
and URLs for the parameters.
The Issuer parameters can be obtained from an Issuer via a directory
object, which is a JSON object RFC8259, Section 4 whose values are
other JSON values RFC8259, Section 3 for the parameters.
Draft: draft-ietf-privacypass-protocol

Commentary: This is probably just a nitpick but I do n't understand what you 're assuming here . If the messages are encoded as raw byte format , is n't that really what the document is all about ? Maybe what you want to be saying is more like what s in the ?
We assume that all protocol messages are encoded into raw byte format
before being sent across the wire.
Unless otherwise specified, this document encodes protocol messages
in TLS notation from TLS13, Section 3.
Draft: draft-ietf-privacypass-protocol

Commentary: There are two cases where the term seems to be used with importance . I suspect that the Internet is n't actually that important in the context / scope of this protocol document , especially since the architecture document does n't mention it . 
 Yep , good catch . It 's not . 
 Is there a more polite way to phrase this disclaimer ? 
 This follows RFC 2119 ( ) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents . Though technically these should probably be " SHOULD NOT " and " SHALL NOT " to be in line with the RFC terms . 
 What requirements are being defined in the quoted text though ? Is it simply a statement of fact like " this document does n't cover architectural stuff " or is it " implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document " ? 
 this is just a statement of fact -- we do n't need to shout it =)
The Privacy Pass protocol provides a privacy-preserving authorization
mechanism.  In essence, the protocol allows clients to provide
cryptographic tokens that prove nothing other than that they have
been created by a given server in the past I-D.ietf-privacypass-
architecture.
This document DOES NOT cover the architectural framework required for
running and maintaining the Privacy Pass protocol in the Internet
setting.  In addition, it DOES NOT cover the choices that are
necessary for ensuring that client privacy leaks do not occur.  Both
of these considerations are covered in I-D.ietf-privacypass-
architecture.
The Privacy Pass protocol provides a privacy-preserving authorization
mechanism.  In essence, the protocol allows clients to provide
cryptographic tokens that prove nothing other than that they have
been created by a given server in the past ARCHITECTURE.
This document does not cover the Privacy Pass architecture, including
choices that are necessary for ensuring that client privacy leaks.
This information is covered in ARCHITECTURE.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
blind RSA documents also apply in the Privacy Pass use-case.
Considerations related to broader privacy and security concerns in a
multi-Client and multi-Issuer setting are deferred to the
Architecture document I-D.ietf-privacypass-architecture.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
blind RSA documents also apply in the Privacy Pass use-case.
Considerations related to broader privacy and security concerns in a
multi-Client and multi-Issuer setting are deferred to the
Architecture document ARCHITECTURE.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: it 's not crystal - clear what the interaction model for this auth scheme is . In many auth schemes , the credential is repeated on each request , to keep the protocol stateless , and to prove the client 's identity . However , that does n't seem to be desireable here -- not only would it make all of those responses uncacheable , it would ( AIUI ) ' spend ' a lot of private tokens . OTOH , the ' realm ' parameter is explicitly supported ( albiet without much detail ) , which implies the opposite . I think the preferred interaction model is that a token is only spent upon an explicit challenge from the server , but it was difficult to discern this from the documentation . Either way , it 'd be good to clarify this . 
 Correct , the client should n't spend a token multiple times , and should n't keep including the credential on future requests . We could drop the realm text , but I think allowing it as a MAY does leave open use cases that might want to segment up different use cases of tokens . 
 Yeah , unless there 's a reason to omitting it , I think keeping the MAY for the realm is fine . I tried to get a sense for how clients are intended to use other auth schemes from RFC 9110 , but it was n't clear to me . do you know of other auth scheme specifications that make the interaction model more clear ?
Unlike many authentication schemes in which a client will present the
same credentials across multiple requests, tokens used with the
"PrivateToken" scheme are single-use credentials, and are not reused.
Spending the same token value more than once allows the origin to
link multiple transactions to the same client.  In deployment
scenarios where origins send token challenges to request tokens,
origins ought to expect at most one request containing a token from
the client in reaction to a particular challenge.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: HTTP is a stateless protocol ; there is no concept of a ' session ' .
For token types that support public verifiability, origins verify the
token authenticator using the public key of the issuer, and validate
that the signed message matches the concatenation of the client nonce
and the hash of a valid TokenChallenge.  For context-bound tokens,
origins store or reconstruct the contexts of previous TokenChallenge
structures in order to validate the token.  A TokenChallenge MAY be
bound to a specific HTTP session with client, but origins can also
accept tokens for valid challenges in new sessions.  Origins SHOULD
implement some form of double-spend prevention that prevents a token
with the same nonce from being redeemed twice.  This prevents clients
from "replaying" tokens for previous challenges.  For context-bound
tokens, this double-spend prevention can require no state or minimal
state, since the context can be used to verify token uniqueness.
For token types that support public verifiability, origins verify the
token authenticator using the public key of the issuer, and validate
that the signed message matches the concatenation of the client nonce
and the hash of a valid TokenChallenge.  For context-bound tokens,
origins store or reconstruct the contexts of previous TokenChallenge
structures in order to validate the token.  A TokenChallenge MAY be
bound to a specific TLS session with a client, but origins can also
accept tokens for valid challenges in new sessions.  Origins SHOULD
implement some form of double-spend prevention that prevents a token
with the same nonce from being redeemed twice.  This prevents clients
from "replaying" tokens for previous challenges.  For context-bound
tokens, this double-spend prevention can require no state or minimal
state, since the context can be used to verify token uniqueness.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: Nit : I suspect this would be more accurate if it said :
In addition to working with different token issuance protocols, this
scheme supports optionally associating tokens with origin-chosen
contexts and specific origin names.  Relying parties that request and
redeem tokens can choose a specific kind of token, as appropriate for
its use case.  These options allow for different deployment models to
prevent double-spending, and allow for both interactive (online
challenges) and non-interactive (pre-fetched) tokens.
In addition to working with different token issuance protocols, this
scheme optionally supports use of tokens that are associated with
origin-chosen contexts and specific origin names.  Relying parties
that request and redeem tokens can choose a specific kind of token,
as appropriate for its use case.  These options allow for different
deployment models to prevent double-spending, and allow for both
interactive (online challenges) and non-interactive (pre-fetched)
tokens.