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

Commentary: From editor copy today : I found this intro to be a bit clunky . I did n't read the ARCHITECTURE reference yet but do n't think that should be a prerequisite to comprehension of the first para . How about something like
Privacy Pass tokens are unlinkable authenticators that can be used to
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.
Privacy Pass tokens are unlinkable authenticators that can be used to
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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: For example , What happens if validation fails here , is the challenge simply ignored or should the client do something more drastic ?
Upon receipt of this challenge, a client uses the message and keys in
the issuance protocol indicated by the token_type.  If the
TokenChallenge has a token_type the client does not recognize or
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
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
names for which current connection is not authoritative (according to
the TLS certificate).
Upon receipt of this challenge, a client uses the message and keys in
the issuance protocol indicated by the token_type.  If the
TokenChallenge has a token_type the client does not recognize or
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
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
names for which current connection is not authoritative (according to
the TLS certificate).
Draft: draft-ietf-privacypass-auth-scheme

Commentary:  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 ?
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
names containing the origin.
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
names containing the origin itself.
"origin_info" is an optional string containing one or more origin
names, which allows a token to be scoped to a specific set of
origins.  The string is prefixed with a 2-octet integer indicating
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
whitespace.
"origin_info" is an optional string containing one or more origin
names, which allows a token to be scoped to a specific set of
origins.  The string is prefixed with a 2-octet integer indicating
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
whitespace.  If this field is not empty, the Origin MUST include
its own name as one of the names in the list.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: 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
Token challenge: A requirement for tokens sent from an origin to a
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.
Token redemption: An action by which a client presents a token to
an origin, using the "Authorization" HTTP header.
Token challenge: A requirement for tokens sent from an origin to a
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.
Token redemption: An action by which a client presents a token to
an origin, using the "Authorization" HTTP header field.
Origins send a token challenge to clients in an "WWW-Authenticate"
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.
Origins send a token challenge to clients in an "WWW-Authenticate"
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.
The header MAY also include the standard "realm" attribute, if
desired.  Issuance protocols MAY require other attributes.
The header field MAY also include the standard "realm" attribute, if
desired.  Issuance protocols MAY require other attributes.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: 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 ,
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.
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, from the Reserved list of "greased" types (defined in token-
types), with some non-zero probability.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: Suspect the prose is not aligned with the structure , it says but there is no field in . 
 Yup , that should say . The name changed .
The authenticator value in the Token structure is computed over the
token_type, nonce, context, and token_key_id fields.
The authenticator value in the Token structure is computed over the
token_type, nonce, challenge_digest, and token_key_id fields.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: The security considerations of the auth scheme should mention 0 - RTT specifically in its discussion of token replay .
Applications SHOULD constrain tokens to a single origin unless the
use case can accommodate such replay attacks.
Applications SHOULD constrain tokens to a single origin unless the
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.
Draft: draft-ietf-privacypass-protocol

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

Commentary: cc 
 [ 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   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 - does not work perhaps this is the updated one ? -
the compromise is patched, without needing to modify Origin allow-
lists.
the compromise is patched.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.  The Issuer
accepts token requests that come from trusted Attesters.  Depending
on the issuance protocol, the Attester may relay these requests
between Client and Issuer over an authenticated channel, or trust may
be established in some other manner.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.  As with the joint
Origin and Issuer model, the Issuer accepts token requests that come
from trusted Attesters, and the details of that trust establishment
depend on the issuance protocol.
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.{
{?CENTRALIZATION=I-D.nottingham-avoiding-internet-centralization}}
discusses several ways in which this might be mitigated.  For
example, a multi-stakeholder governance model could be established to
determine what candidate participants are fit to operate as
participants in a Privacy Pass deployment.  This is precisely the
system used to control the Web's trust model.
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.
CENTRALIZATION discusses several ways in which this might be
mitigated.  For example, a multi-stakeholder governance model could
be established to determine what candidate participants are fit to
operate as participants in a Privacy Pass deployment.  This is
precisely the system used to control the Web's trust model.
Draft: draft-ietf-privacypass-architecture

Commentary: [ 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   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 - does not work perhaps this is the updated one ? -
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.
Draft: draft-ietf-privacypass-architecture

Commentary: [ 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   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 - does not work perhaps this is the updated one ? -
protocol, in the original Privacy Pass protocol PPSRV, tokens were
only issued to Clients that solved CAPTCHAs.  In this context, the
Attester attested that some client solved a CAPTCHA and the resulting
token produced by the Issuer was proof of this fact.
protocol, in the original Privacy Pass protocol PPEXT, tokens were
only issued to Clients that solved CAPTCHAs.  In this context, the
Attester attested that some client solved a CAPTCHA and the resulting
token produced by the Issuer was proof of this fact.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: To allow experimentation and private types , define a portion of the token type registry to be reserved for private use .
Values 0xFF00-0xFFFF are reserved for private use, to enable
proprietary uses and limited experimentation.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 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 .
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.
Draft: draft-ietf-privacypass-architecture

Commentary: This does n't go overboard and clarify non - collusion assumptions for all models . It simply states the requirement that entities with access to the attestation context and redemption context do not collude , and then generalizes somewhat for simplicity . cc 
 The architecture assumes that any two parties do not collude with each other . I think this is too strong an assumption . In particular , if the  does not collude with anyone else , what is the point of unlinkability of the issuance and redemption flows ? Looking at the use cases , it seems that where the Attester and Issuer are distinct there is a needed non - collusion assumption between them to achieve desirable privacy , but I think the origin colluding with one of the Issuer or Attester should be fine and would be worth considering in scope . Also , in addition to the non - collusion assumption , are there any other assumptions made on the parties , such as honest - but - curious , or do we consider them to be potentially fully malicious ? It would be nice to spell this out . 
 If the  colluded with the Issuer it would learn the client 's identity ( presumably ) , which would be bad . Ultimately , the desired property is that any sort of collusion that would allow the redemption context to be linked to the attestation context is prohibited . I 'll try to clarify .
A Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
browsing history.  Depending on the deployment model, separating
these contexts can take different forms.  The Origin, Attester, and
Issuer portrayed in fig-overview can be instantiated and deployed in
a number of ways.  This section covers some expected deployment
models and their corresponding security and privacy considerations.
The discussion below assumes non-collusion between entities when
operated by separate parties.  Mechanisms for enforcing non-collusion
are out of scope for this architecture.
A Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
browsing history.  Depending on the deployment model, separating
these contexts can take different forms.  The Origin, Attester, and
Issuer portrayed in fig-overview can be instantiated and deployed in
a number of ways.  This section covers some expected deployment
models and their corresponding security and privacy considerations.
The discussion below assumes non-collusion between entities that have
access to the attestation context and entities that have access to
the redemption context, as collusion between such entities would
enable linking of these contexts.  Generally, this means that
entities operated by separate parties do not collude.  Mechanisms for
enforcing non-collusion are out of scope for this architecture.
Draft: draft-ietf-privacypass-architecture

Commentary: 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 
 input secrecy requirement suggests that client private input would include the nonce , challenge , but does n't give any ideas what else might be part of the private input : 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 ? 
 issuance protocol only takes as input the TokenChallenge and client - generated nonce , both of which are considered private . It does n't take anything else as input . We should just say that directly . client nonce is a required part of the Token structure .
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
Client, Issuer, or other parties that produces a valid authenticator
over the Client's input, subject to the following security
requirements.
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
Client, Issuer, or other parties that produces a valid authenticator
over the Client's private input, subject to the following security
requirements.