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

Commentary: cc for
deployment discusses deployment models that are possible in practice.
Beyond possible implications on security and privacy properties of
the resulting system, Privacy Pass deployments can impact the overall
ecosystem in two important ways: (1) discriminatory treatment of
Clients and the viability of an open Web, and (2) centralization.
This section describes considerations relevant to these topics.
Origins can use tokens as a signal for distinguishing between Clients
that are capable of completing attestation with one Attester trusted
by the Origin's chosen Issuer, and Clients that are not capable of
doing the same.  A consequence of this is that Privacy Pass could
enable discriminatory treatment of Clients based on Attestation
support.  This could lead to harmful ecosystem effects if left
unresolved.
In principle, Issuers should strive to work with a set of Attesters
that are suitable for all Clients, thereby mitigating such
discriminatory behavior.  In practice, this may require tradeoffs in
what type of attestation Issuers are willing to trust so as to enable
more widespread support.
For example, to disallow discriminatory behavior between Clients with
and without device attestation support, an Issuer may wish to support
Attesters that support CAPTCHA-based attestation.  This means that
the overall attestation value of a Privacy Pass token is bound by the
difficulty in spoofing or bypassing either one of these attestation
procedures.
Draft: draft-ietf-privacypass-protocol

Commentary: Oops .
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.
Here, "P384-SHA384" is the identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupVOPRFClient is
defined in OPRF, Section 3.2.
Draft: draft-ietf-privacypass-protocol

Commentary: cc for an extra set of eyes to check me here -- ASN.1 is not my forte . I went based on the implementation , which I think matches what  did , but I would definitely appreciate confirmation ! 
 Friendly bump and =) 
 Do you have a test vector / example to make sure it matches what I believe ? 
 yeah , each includes the encoded public key ( ) . 
 Example , taken from the current test vector : 
 Looks good to me . But yeah ,  is not the most concise nor readable format . 
 ASN1 matches my expectations as well . 
 ... we should make it clear , and provide test vectors to make sure it matches . The test vector could include public keys in PEM format and then print out the expected key ID .
The key identifier for a keypair (skI, pkI), denoted "token_key_id",
is computed as SHA256(encoded_key), where encoded_key is a DER-
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI
object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash
algorithm and salt size.  The salt size MUST match the output size of
the hash function associated with the public key and token type.
The key identifier for a keypair (skI, pkI), denoted "token_key_id",
is computed as SHA256(encoded_key), where encoded_key is a DER-
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI
object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash
algorithm and salt size.  The salt size MUST match the output size of
the hash function associated with the public key and token type.  The
parameters field for the digest used in the mask generation function
and the digest being signed MUST be omitted.
Draft: draft-ietf-privacypass-architecture

Commentary: good suggestions ! I merged them all . 
 This system extensively uses tokens that are only loosely bound to usage contexts . Possession of a token is pretty much all that is necessary . That means that tokens might be stolen or hoarded and then replayed . The architecture draft says nothing about this as a risk , but it probably should . 
 Agree , especially for for cached tokens . I thought we had mentioned this somewhere , but if not , let 's make sure it 's included .
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step-redemption and
redeem its token.
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step-redemption and
redeem its token; see hoarding for security considerations of
cached tokens.
Depending on the Origin's token challenge, Clients can request and
cache more than one token using an issuance protocol.  Cached tokens
help improve privacy by separating the time of token issuance from
the time of token redemption, and also allow Clients to reduce the
overhead of receiving new tokens via the issuance protocol.
As a consequence, Origins that send token challenges which are
compatible with cached tokens need to take precautions to ensure that
tokens are not replayed.  This is typically done via keeping track of
tokens that are redeemed for the period of time in which cached
tokens would be accepted for particular challenges.
Moreover, since tokens are not intrinsically bound to Clients, it is
possible for malicious Clients to collude and share tokens in a so-
called "hoarding attack."  As an example of this attack, many
distributed Clients could obtain cacheable tokens and them share them
with a single Client to redeem in a way that would violate an
Origin's attempt to limit tokens to any one particular Client.
Draft: draft-ietf-privacypass-architecture

Commentary: I think that this definition is incorrect . The latest sentence is from the definition of Origin - Client unlinkability : 
 good catch . Copy - pasta error .
Issuer-Client unlinkability.  This is similar to Origin-Client
unlinkability in that a Client in an issuance context is
indistinguishable from any other Client that might use the same
issuance context.  The set of Clients that share the same
redemption context is referred to as a redemption anonymity set.
Attester-Origin unlinkability.  This is similar to Origin-Client
and Issuer-Client unlinkability.  It means that given two
attestation contexts, the Attester cannot determine if both
contexts correspond to the same Origin or two different Origins.
The set of Clients that share the same attestation context is
referred to as an anonymity set.
Issuer-Client unlinkability.  This is similar to Origin-Client
unlinkability in that a Client in an issuance context is
indistinguishable from any other Client that might use the same
issuance context.  The set of Clients that share the same issuance
context is referred to as an issuance anonymity set.
Attester-Origin unlinkability.  This is similar to Origin-Client
and Issuer-Client unlinkability.  It means that given two
attestation contexts, the Attester cannot determine if both
contexts correspond to the same Origin or two different Origins.
The set of Clients that share the same attestation context is
referred to as an attestation anonymity set.
Draft: draft-ietf-privacypass-architecture

Commentary: The issuance overview step 3 says that the  and Attester interact to do whatever is necessary to convince the Attester to attest . But there does n't seem to be any pretext for this process to be initiated . Step 4 says that the client requests issuance ( via the Attester ) , which would provide the necessary cause to start the attesting process . Should these steps be swapped ? 
 Either the attester is an intermediary to the flow ( which is what we 're doing in practice ) , or it is a separate flow . So the prerequisite is that the client knows it wants to request a token from an issuer , and then it does attestation . 
 Perhaps this could be made more clear if we say that the client , upon deciding it wants to invoke the issuance protocol , then begins the deployment - specific attestation process with its trusted attester ? I can suggest some text for this .
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step-redemption and
redeem its token.  Otherwise, it invokes the issuance protocol to
request a token from the designated Issuer.
The first step in the issuance protocol is attestation.
Specifically, the Attester performs attestation checks on the
Client.  These checks could be proof of solving a CAPTCHA, device
trust, hardware attestation, etc (see attester).
If attestation succeeds, the client creates a Token Request to
send to the designated Issuer (generally via the Attester).  The
Attester and Issuer might be functions on the same server,
depending on the deployment model (see deployment).  Depending on
the details of Attestation, the Client can send the Token Request
to the Attester alongside any attestation information.  If
attestation fails, the Client receives an error and issuance
aborts without a token.
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step-redemption and
redeem its token.
If the Client does not have a token available and decides it wants
to obtain one (or more) bound to the token challenge, it then
invokes the issuance protocol.  As a prerequisite to the issuance
protocol, the Client runs the deployment specific attestation
process that is required for the designated Issuer.  Client
attestation can be done via proof of solving a CAPTCHA, checking
device or hardware attestation validity, etc; see attester for
more details.
If the attestation process completes successfully, the client
creates a Token Request to send to the designated Issuer
(generally via the Attester).  The Attester and Issuer might be
functions on the same server, depending on the deployment model
(see deployment).  Depending on the attestation process, it is
possible for attestation to run alongside the issuance protocol,
e.g., where Clients send necessary attestation information to the
Attester along with their Token Request.  If the attestation
process fails, the Client receives an error and issuance aborts
without a token.
Draft: draft-ietf-privacypass-architecture

Commentary: The interaction model here does n'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 ca n't see how this is necessary . 
 No , it does n'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 , 
 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 .
Privacy Pass is an architecture for authorization based on privacy-
preserving authentication mechanisms.  Typical approaches for
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.
Privacy Pass is an architecture for authorization based on privacy-
preserving authentication mechanisms.  Typical approaches for
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.
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.
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.
Draft: draft-ietf-privacypass-architecture

Commentary: Sorry , I had to wrap this .
If the Client has a token, it includes it in a subsequent HTTP
request to the Origin, as authorization.  This token is sent only
once.  The Origin validates that the token was generated by the
expected Issuer and has not already been redeemed for the
corresponding token challenge.  If the Client does not have a
token, perhaps because issuance failed, the client does not reply
to the Origin's challenge with a new request.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: The token_type field in and determines the remainder of each of these structures . This is n't explicitly stated anywhere , but I think it 's an implicit assumption we 've all been making .
"token_type" is a 2-octet integer, in network byte order.  This
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.
"token_type" is a 2-octet integer, in network byte order.  This
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.
This value determines the structure and semantics of the rest of
the structure.
"token_type" is a 2-octet integer, in network byte order.  This
value must match the value in the challenge (challenge).
"token_type" is a 2-octet integer, in network byte order.  This
value must match the value in the challenge (challenge).  This
value determines the structure and semantics of the rest of the
structure.
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
redemption and issuance and the requirements on the relevant
participants.
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
the redemption and issuance protocols and the requirements on the
relevant participants.
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.
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.
Draft: draft-ietf-privacypass-architecture

Commentary: After talking with and it seems like we could benefit from more clarity around attestation . In particular , we could improve clarity by providing a mapping between the terminology used in the architecture document and the terminology used in the RATS working group ( which already does attestation stuff ) . Moreover , we could provide more examples of how attestation might actually work in practice . Currently , the diagrams just have this opaque "  " message that 's sent in the issuance protocol , but expanding on that with details and an example or two could help align everyone 's mental model .
Capable of solving a CAPTCHA.  Clients that solve CAPTCHA
challenges can be attested to have this capability for the purpose
of being ruled out as a bot or otherwise automated Client.
Client state.  Clients can be associated with state and the
attester can attest to this state.  Examples of state include the
number of issuance protocol invocations, the Client's geographic
region, and whether the client has a valid application-layer
account.
Trusted device.  Some Clients run on trusted hardware that are
capable of producing device-level attestation statements.
Each of these attestation types has different security properties.
For example, attesting to having a valid account is different from
attesting to running on trusted hardware.  In general, minimizing the
set of attestation formats helps minimize the amount of information
leaked through a token.
Attestation is an important part of the issuance protocol.  In
Privacy Pass, attestation is the process by which an Attester bears
witness to, confirms, or authenticates a Client so as to verify a
property about the Client that is required for Issuance.  RFC9334
describes an architecture for attestation procedures.  Using that
architecture as a conceptual basis, Clients are RATS attesters that
produce attestation evidence, and Attesters are RATS verififiers that
appraise the validity of attestation evidence.
The type of attestation procedure is a deployment-specific option and
outside the scope of the issuance protocol.  Example attestation
procedures are below.
Solving a CAPTCHA.  Clients that solve CAPTCHA challenges can be
attested to have this capability for the purpose of being ruled
out as a bot or otherwise automated Client.
Presenting evidence of Client device validity.  Some Clients run
on trusted hardware that are capable of producing device-level
attestation evidence.
Proving properties about Client state.  Clients can be associated
with state and the Attester can verify this state.  Examples of
state include the Client's geographic region and whether the
Client has a valid application-layer account.
Attesters may support different types of attestation procedures.  A
type of attestation procedure is also referred as an attestation
format.
In general, each attestation format has different security
properties.  For example, attesting to having a valid account is
different from attesting to running on trusted hardware.  In general,
minimizing the set of attestation formats helps minimize the amount
of information leaked through a token.
Draft: draft-ietf-privacypass-protocol

Commentary: ends with two paragraphs that really belong in Section 5.2 , because they are about the processing of the request .
If any of these conditions is not met, the Issuer MUST return an HTTP
400 error to the client.
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.
Draft: draft-ietf-privacypass-protocol

Commentary: Are the changes to other files on this one intentional ? 
 Oh , hrm , no , they 're not . I 'll remove them . 
 fixed ! 
 There are several related issues in 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  ( 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 ?
Issuer Request URI: A token request URL for generating access
tokens.  For example, an Issuer URL might be
https://issuer.example.net/request.  This parameter uses resource
media type "text/plain".
Issuer Request URL: A token request URL for generating access
tokens.  For example, an Issuer URL might be
https://issuer.example.net/request.
Draft: draft-ietf-privacypass-protocol

Commentary: does n'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 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 ) .
The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for
OPRF(P-384, SHA-384).
The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for
OPRF(P-384, SHA-384).  The constant "Nk" is defined by private-token-
type.
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.  The constant "Nk" is defined
by public-token-type.
Draft: draft-ietf-privacypass-protocol

Commentary: 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 is n't always . 
 What would be the benefit of a media type here if the content will always be JSON ? That is , I do n't see how a media type would influence consumers of the resource . 
 So that you can make it clear that it is this specific  , as opposed to some other  . 
 The table appears without the text referring to it , even with an " as follows " . It might be better to reference it directly .
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.
Each "token-keys" JSON object contains the following fields and
corresponding raw values.
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.  The
contents of this JSON object are defined in directory-values.
Each "token-keys" JSON object contains the fields and corresponding
raw values defined in tokenkeys-values.
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.
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.
This section contains considerations for IANA.