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

Commentary: Updated to use random values 
 please take a look ! 
 Origins can issue challenges for greased token types , etc , to ensure client can handle new types in the future . 
 One type of greasing might be adding random authentication credentials to the header , e.g. , . 
 We should recommend servers to send greased token types + parameters , as well as clients to send greased credentials .
This document defines several Reserved values, which can be used by
clients and servers to send "greased" values in token challenges and
responses to ensure that implementations remain able to handle
unknown token types gracefully (this technique is inspired by
RFC8701).  Implemenations SHOULD select reserved values at random
when including them in greased messages.  Servers can include these
in TokenChallenge structures, either as the only challenge when no
real token type is desired, or as one challenge in a list of
challenges that include real values.  Clients can include these in
Token structures when they are not able to present a real token
response.  The contents of the Token structure SHOULD be filled with
random bytes when using greased values.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: We could omit the authenticator value and just focus on how Token is constructed based on TokenChallenge , but it seems reasonable to include the authenticator so folks can also test that they 're computing the token key ID correctly . Generated from .
Privacy Pass tokens are unlinkable authenticators that can be used to
anonymously authorize a client (see I-D.ietf-privacypass-
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).  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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: These are covered in the architecture . 
 Bump
Clients initiate the issuance protocol using a challenge, a randomly
generated nonce, and a public key for the issuer.  The 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.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the client's private input, including the
challenge and nonce.  The issuance protocol can reveal the issuer
public key for the purposes of determining which private key to
use in producing the issuance protocol.  A result of this property
is that the redemption flow is unlinkable from the issuance flow.
One-more forgery security.  The issuance protocol MUST NOT allow
malicious clients to forge tokens without interacting with the
issuer directly.
Concurrent security.  The issuance protocol MUST be safe to run
concurrently with arbitrarily many clients.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: Spell out origin steps more clearly  token caching into its own section I tried having an overall " origin " and " client " section , but it did n't flow as well .
Select which issuer to use, and configure the issuer name and
token-key to include in WWW-Authenticate challenges.
Determine a redemption context construction to include in the
TokenChallenge, as discussed in context-construction.
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.
Note that it is possible for the WWW-Authenticate header to include
multiple challenges, in order to allow the client to fetch a batch of
multiple tokens for future use.
Caching and pre-fetching of tokens is discussed in caching.
An empty redemption context is not bound to any property of the
client session.
An empty redemption context is not bound to any property of the
client session.  Preventing double spending on tokens requires the
origin to keep state associated with the redemption context.  The
size of this state varies based on the size of the redemption
context.  For example, double spend state for unique, per-request
redemption contexts does only needs to exist within the scope of the
request connection or session.  In contrast, double spend state for
empty redemption contexts must be stored and shared across all
requests until token-key expiration or rotation.
Clients can generate multiple tokens from a single TokenChallenge,
and cache them for future use.  This improves privacy by separating
the time of token issuance from the time of token redemption, and
also allows clients to avoid any overhead of receiving new tokens via
the issuance protocol.
Cached tokens can only be redeemed when they match all of the fields
in the TokenChallenge: token_type, issuer_name, redemption_context,
and origin_info.  Clients ought to store cached tokens based on all
of these fields, to avoid trying to redeem a token that does not
match.  Note that each token has a unique client nonce, which is sent
in token redemption (redemption).
Draft: draft-ietf-privacypass-protocol

Commentary: Since metadata can be bound to tokens via TokenChallenge.redemptioncontext , and the origin is ultimately the one who determines what  is supported , there 's no more real need for the issuer _ to supply this metadata . So let 's go with the simpler VOPRF protocol instead ! Test vectors generated from the code here : cc 
 LGTM
Both Client and Issuer also share a common public string called
"info".
Here, 0x0004 is the two-octet identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupPOPRFClient is
defined in OPRF, Section 3.2.
Here, 0x0004 is the two-octet identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupVOPRFClient is
defined in OPRF, Section 3.2.
"blinded_request" is the Ne-octet blinded message defined above,
computed as "SerializeElement(blinded_msg)".  Ne is as defined in
OPRF, Section 4.
The value "tweaked_key" is stored locally and used later as described
in finalization.  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.
"blinded_msg" is the Ne-octet blinded message defined above,
computed as "SerializeElement(blinded_element)".  Ne is as defined
in OPRF, Section 4.
The values "token_input" and "blinded_element" are stored locally and
used later as described in finalization.  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 TokenRequest.blinded_msg is of the correct size.
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.
"evaluate_response" is the Ne-octet evaluated messaged, computed
as "SerializeElement(evaluated_msg)".
The TokenRequest.blinded_request is of the correct size.
If any of these conditions is not met, the Issuer MUST return an HTTP
400 error to the client.
"evaluate_msg" is the Ne-octet evaluated messaged, computed as
"SerializeElement(evaluate_element)".
Draft: draft-ietf-privacypass-auth-scheme

Commentary: Based on examples from IETF 113 .
"redemption_context" is an optional field.  If present, it allows
the origin to require that clients fetch tokens bound to a
specific context, as opposed to reusing tokens that were fetched
for other contexts.  When present, this value is a 32-byte context
generated by the origin.  This value can be a unique per-request
nonce, or represent some state such as properties of the client
session or current time window.  Valid lengths for this field are
either 0 or 32 bytes.  The field is prefixed with a single octet
indicating the length.  Challenges with redemption_context values
of invalid lengths MUST be ignored.
"redemption_context" is an optional field.  If present, it allows
the origin to require that clients fetch tokens bound to a
specific context, as opposed to reusing tokens that were fetched
for other contexts.  See context-construction for example contexts
that might be useful in practice.  When present, this value is a
32-byte context generated by the origin.  Valid lengths for this
field are either 0 or 32 bytes.  The field is prefixed with a
single octet indicating the length.  Challenges with
redemption_context values of invalid lengths MUST be ignored.
The TokenChallenge redemption context allows the origin to determine
the context in which a given token can be redeemed.  This value can
be a unique per-request nonce, constructed from 32 freshly generated
random bytes.  It can also represent state or properties of the
client session.  Some example properties and methods for constructing
the corresponding context are below.  This list is not exhaustive.
Context bound to a given time window: Construct redemption context
as SHA256(current time window).
Context bound to a client location: Construct redemption context
as SHA256(client IP address prefix).
Context bound to a given time window and location: Construct
redemption context as SHA256(current time window, client IP
address prefix).
An empty redemption context is not bound to any property of the
client session.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: From : said :
If a Client fetches a batch of multiple tokens for future use that
are bound to a specific redemption context (the redemption_context in
the TokenChallenge was not empty), Clients SHOULD discard these
tokens upon flushing state such as HTTP cookies COOKIES, or changing
networks.  Using these tokens in a context that otherwise would not
be linkable to the original context could allow the Origin to
recognize a Client.
Context-bound token challenges require clients to obtain matching
tokens when challenged, rather than presenting a token that was
obtained in the past.  This can make it more likely that issuance and
redemption events will occur at approximately the same time.  For
example, if a client is challenged for a token with a unique context
at time T1 and then subsequently obtains a token at time T2, a
colluding issuer and origin can link this to the same client if T2 is
unique to the client.  This linkability is less feasible as the
number of issuance events at time T2 increases.  Depending on the
"max-age" token challenge attribute, clients MAY try to augment the
time between getting challenged then redeeming a token so as to make
this sort of linkability more difficult.  For more discussion on
correlation risks between token issuance and redemption, see I-
D.ietf-privacypass-architecture.
Context-bound token challenges require clients to obtain matching
tokens when challenged, rather than presenting a token that was
obtained from a different context in the past.  This can make it more
likely that issuance and redemption events will occur at
approximately the same time.  For example, if a client is challenged
for a token with a unique context at time T1 and then subsequently
obtains a token at time T2, a colluding issuer and origin can link
this to the same client if T2 is unique to the client.  This
linkability is less feasible as the number of issuance events at time
T2 increases.  Depending on the "max-age" token challenge attribute,
clients MAY try to augment the time between getting challenged then
redeeming a token so as to make this sort of linkability more
difficult.  For more discussion on correlation risks between token
issuance and redemption, see I-D.ietf-privacypass-architecture.
As discussed in challenge, clients SHOULD discard any context-bound
tokens upon flushing cookies or changing networks, to prevent an
Origin using the redemption context state as a cookie to recognize
clients.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: For anyone unfamiliar with TLS struct notation , spell out the length fields in the text .
"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
to issue tokens that can be redeemed by this origin.
"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
to issue tokens that can be redeemed by this origin.  The string
is prefixed with a 2-octet integer indicating the length, in
network byte order.
"redemption_context" is an optional field.  If present, it allows
the origin to require that clients fetch tokens bound to a
specific context, as opposed to reusing tokens that were fetched
for other contexts.  When present, this value is a 32-byte context
generated by the origin.  This value can be a unique per-request
nonce, or represent some state such as properties of the client
session or current time window.  Valid lengths for this field are
either 0 or 32 bytes.  Challenges with redemption_context values
of invalid lengths MUST be ignored.
"origin_name" is an optional string containing the name of the
origin.  This allows a token to be scoped to a specific origin.
If empty, any non-origin specific token can be redeemed.
"redemption_context" is an optional field.  If present, it allows
the origin to require that clients fetch tokens bound to a
specific context, as opposed to reusing tokens that were fetched
for other contexts.  When present, this value is a 32-byte context
generated by the origin.  This value can be a unique per-request
nonce, or represent some state such as properties of the client
session or current time window.  Valid lengths for this field are
either 0 or 32 bytes.  The field is prefixed with a single octet
indicating the length.  Challenges with redemption_context values
of invalid lengths MUST be ignored.
"origin_name" is an optional string containing the name of the
origin, which allows a token to be scoped to a specific origin.
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.
Draft: draft-ietf-privacypass-protocol

Commentary: Generated from . cc 
 These test vectors should cover the whole flow of the protocol , starting with the input and producing a output .
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 "blind_sig", 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 "message/token-response".
Draft: draft-ietf-privacypass-protocol

Commentary: cc 
 This is fine , but why are you using a well - known location ? It seems like it 's just adding a RT so that people can avoid using a full URI for configuration . 
 can you help us understand what would be the preferred alternative ? At the end of the day , if I 'm an origin or client and need to get this information from an issuer , and all I have is the issuer name , what am I left with ? 
 So that 's the question -- what does the person using the service have to start with ? E.g. , if I know that the service I want to work with is " cloudflare " , I still have to discover something more specific , even with the current approach -- I need a hostname ( and possibly a port ) . It might be , but it equally could be or . So I have to find it somewhere , probably in documentation . Given that I have to go through that process as a consumer of this API , what 's the advantage of configuring with just a hostname , vs. a full URL -- allowing you to skip the .well - known location ? Skipping the .well - known saves latency and also avoids some caching issues ( i.e. , how long can you trust the information in it for ? How do you manage change ? ) There are reasons that this would be the case -- e.g. , if there 's a lot more configuration information to convey ( that has n't made it into the spec yet ) , the indirection is actually desirable for operational purposes , or that the hostname can be inferred / discovered automatically ( e.g. , with a DNS record for the registrable domain name ) . I 'm not deep enough into this protocol to know whether any of this is the case . 
 I would expect a common practice to be that folks are configured with the full authority ( and the implied : 443 port ) . And , they could then use to this discover additional information using a registered .well - known . But , to your point , if they 're configured this way , it 's probably reasonable to require them to simply be configured with the full URL used to obtain the configuration dictionary . That is , instead of configuring them , configure them with . I 'm not sure we have enough experience yet to know which of these would be preferred . It 's probably worth splitting this off into a separate issue to track as things progress . thoughts ? 
 See .
Issuer Request URI: a token request URL for generating access
tokens.  For example, an Issuer URL might be
https://issuer.example.net/example-token-request.  This parameter
uses resource media type "text/plain".
The Issuer parameters can be obtained from an Issuer via a directory
object, which is a JSON object whose field names and values are raw
values and URLs for the parameters.
Issuer directory resources have the media type "application/json" and
are located at the well-known location /.well-known/token-issuer-
directory.
Clients receive challenges for tokens, as described in AUTHSCHEME.
The basic token issuance protocols described in this document can be
interactive or non-interactive, and per-origin or cross-origin.
Draft: draft-ietf-privacypass-protocol

Commentary: It 's not obvious where to find these things ! cc
Here, 0x0004 is the two-octet identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in OPRF.
Here, 0x0004 is the two-octet identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupPOPRFClient is
defined in OPRF, Section 3.2.
The Issuer generates an HTTP response with status code 200 whose body
consists of "blind_sig", 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 "blind_sig", with the content type
set as "message/token-response".
Draft: draft-ietf-privacypass-protocol

Commentary: draft - irtf - cfrg - voprf-09 went out today , and this just aligns the basic issuance protocol on top of those changes . cc
Given this configuration and these inputs, the two messages exchanged
in this protocol are described below.
Given this configuration and these inputs, the two messages exchanged
in this protocol are described below.  This section uses notation
described in OPRF, Section 4, including SerializeElement and
DeserializeElement, SerializeScalar and DeserializeScalar, and
DeriveKeyPair.
"blinded_msg" is the Nk-octet request defined above.
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 = 48.
"blinded_request" is the Ne-octet blinded message defined above,
computed as "SerializeElement(blinded_msg)".  Ne is as defined in
OPRF, Section 4.
The value "tweaked_key" is stored locally and used later as described
in finalization.  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 TokenRequest contains a supported token_type.
The TokenRequest.blinded_msg is of the correct size.
The structure fields "evaluated_msg" and "proof" are as computed
above, where Ns is as defined in OPRF, Section 4.
"evaluate_response" is the Ne-octet evaluated messaged, computed
as "SerializeElement(evaluated_msg)".
"evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a
pair of Scalar values, computed as
"concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))",
where Ns is as defined in OPRF, Section 4.
Draft: draft-ietf-privacypass-protocol

Commentary: LGTM modulo the -latest change .
Note that the first round of the protocol is only necessitated for
certain ciphersuites that require client and servers commit to some
value.  When such commitment "com" is generated and sent to the
client, the client returns "com" with the "IssuanceRequest" message.
The server MUST check that the commitment corresponds to "com" that
was previously committed.  This requires the commitment to either be
a reference to some commitment on the server, or the commitment be an
encrypted (and authenticated) blob that the server can use to recover
commitment.  The mechanism by which servers handle this commitment is
implementation specific, and similar to how TLS session resumption
state is managed; see RFC8446 for details.  In addition, the "Commit"
function is implementation-specific and MUST be defined by the
underlying ciphersuite.
A server that is expecting some non-empty "com" to be passed must
abort the protocol on receiving a request containing an empty "com"
value.
Note that the first round of the protocol is only necessitated for
certain ciphersuites that require client and servers commit to some
value.  When such commitment "commit_resp" is generated and sent to
the client, the client returns "commit_resp" with the
"IssuanceRequest" message.  The server MUST check that the commitment
corresponds to "commit_resp" that was previously committed.  This
requires the commitment to either be a reference to some commitment
on the server, or the commitment be an encrypted (and authenticated)
blob that the server can use to recover commitment.  The mechanism by
which servers handle this commitment is implementation specific, and
similar to how TLS session resumption state is managed; see RFC8446
for details.  In addition, the "Commit" function is implementation-
specific and MUST be defined by the underlying ciphersuite.
A server that is expecting some non-empty "commit_resp" to be passed
must abort the protocol on receiving a request containing an empty
"commit_resp" value.