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

Commentary: cc 
 I found this sentence hard to interpret : both because of the use " transitive " and because , AIUI , the  does not directly accept attestations at all . I tried to be a bit more explicit in this phrasing : 
 Good clarification ! Please check out the linked PR where I applied a variant of your suggested text .
Issuer identity.  Tokens identify which Issuers are trusted for a
given issuance protocol.  The selected Issuer transitively
determines what types of attestation the Origin is willing to
accept.  For example, if a given Issuer "issuer.example" has two
trusted Attesters, then any Origin choosing "issuer.example" as
its Issuer is willing to accept attestation checks done by either
of these two Attesters.
Issuer identity.  Tokens identify which Issuers are trusted for a
given issuance protocol.  Each Issuer, in turn, determines which
Attesters it is willing to accept in the issuance protocol.  This
means that if an Origin origin.example accepts tokens issued by
Issuer issuer.example, and that Issuer in turn accepts different
types of attestation from more than one trusted Attester, then a
Client may use either of these trusted Attesters to issue and
redeem tokens for origin.example.  However, origin.example neither
explicitly specifies nor learns the Attesters or their attestation
formats used for token issuance.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 E.g. , consider a protocol where the Issuer signs a commitment to the token challenge . This fails as an unlinkable anonymous credentials because the signature is not randomized , but is has input secrecy because of the commitment . 
 In this hypothetical example , is the commitment not revealed during redemption ? If so , I think we could address this by saying that input secrecy is necessary but insufficient for unlinkability . Thoughts ?
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer, regardless of the
hardness assumptions of the underlying cryptographic protocol(s).
The issuance protocol can reveal the Issuer public key for the
purposes of determining which private key to use in producing the
token.  A result of this property is that the redemption flow is
unlinkable from the issuance flow.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer, regardless of the
hardness assumptions of the underlying cryptographic protocol(s).
The issuance protocol can reveal the Issuer public key for the
purposes of determining which private key to use in producing the
token.
Draft: draft-ietf-privacypass-protocol

Commentary: cc 
 Fixed by .
Beyond these considerations, it is worth highlighting the fact that
Client TokenRequest messages contain truncated token key IDs.  This
is done to minimize the chance that an Issuer can use distinct keys
for targeting specific users.  Since the key ID is truncated to a
single byte, an Issuer can partition the set of Clients into at most
256 different anonymity sets.  On top of this key ID space, Clients
SHOULD apply some form of key consistency mechanism to help ensure
they are not being given unique keys; see CONSISTENCY for more
details.
Draft: draft-ietf-privacypass-protocol

Commentary: cc 
 Let 's use different names to make this distinction clear . 
 This helps , thanks !
Issuer Public Key pkI, with a key identifier "key_id" computed as
described in issuer-configuration.
Issuer Public Key pkI, with a key identifier "token_key_id"
computed as described in issuer-configuration.
Issuer Public Key pkI, with a key identifier "key_id" computed as
described in public-issuer-configuration.
Issuer Public Key pkI, with a key identifier "token_key_id"
computed as described in public-issuer-configuration.
The key identifier for a keypair (skI, pkI), denoted "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.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defnied in
BLINDRSA.  All security considerations described in the VOPRF
document 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.
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.
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.
Beyond these considerations, it is worth highlighting the fact that
Client TokenRequest messages contain truncated token key IDs.  This
is done to minimize the chance that an Issuer can use distinct keys
for targeting specific users.  Since the key ID is truncated to a
single byte, an Issuer can partition the set of Clients into at most
256 different anonymity sets.  On top of this key ID space, Clients
SHOULD apply some form of key consistency mechanism to help ensure
they are not being given unique keys; see CONSISTENCY for more
details.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 LGTM ! 
 Is unconditional input secrecy meant to mean similar to unconditionally hiding ? If so , this probably deserves more explanation and justification in the architecture document as a requirement ; otherwise , a different term should probably be used . 
 To my knowledge unconditional input secrecy is the standard term here . What do you think should be to resolve this issue ? 
 I guess my main question is why is unconditional secrecy a requirement here ? 
 Because we do n't want the server to learn anything about the client 's private input regardless of its computational power . Take blind RSA as an example , which has this property . While a PQ adversary could break RSA , it could not learn the client 's private input from a protocol trace . 
 think this should be spelled out explicitly ; i.e. , say explicitly that the client 's private input should remain private even if some of the cryptographic hardness assumptions underlying the protocol become falsified . wonder if this would be a good place to use a SHOULD vs a MUST . I can see how unconditional secrecy is a desirable property , but , e.g. , TLS does n't have it for obvious reasons . 
 I sent a PR for ( 1 ) . I do n't think we should relax ( 2 ) . Future versions of the architecture can update this requirement to relax as desired .
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer.  The issuance
protocol can reveal the Issuer public key for the purposes of
determining which private key to use in producing the token.  A
result of this property is that the redemption flow is unlinkable
from the issuance flow.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer, regardless of the
hardness assumptions of the underlying cryptographic protocol(s).
The issuance protocol can reveal the Issuer public key for the
purposes of determining which private key to use in producing the
token.  A result of this property is that the redemption flow is
unlinkable from the issuance flow.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 Over a long enough timeline , attestations will be broken - through willful post - boot compromise , malware , or other means . Services that depend on attestations ( consumers of access tokens ) will observe clients that appear to pass attestation , but engage in behavior that indicates that the device is compromised ( e.g. trigger thousands of interactions per second ) . As it stands , the service consuming access tokens is not able to provide feedback that these attestations appear to be false negatives , and should be re - examined by the attester . Even if this feedback were to be provided out of band , it will be challenging for the attester to identify which devices are compromised and diagnose the nature of the compromise . I do not anticipate that this will become a pressing issue until the initial attestations are compromised , but it may be helpful to plan ahead for this scenario . 
 Thanks , This seems like something we ought to discuss in the architecture document .
The trustworthiness of attesters depends on their ability to
correctly and reliably perform attestation during the issuance
protocol.  However, in practice, certain types of attestation can
vary in value over time, e.g., if the attestation process is
compromised or maliciously automated.  These are considered
exceptional events and require configuration changes to address the
underlying cause.  For example, if attestation is compromised because
of a zero-day exploit on compliant devices, then the corresponding
attestation format should be untrusted until the exploit is patched.
Addressing changes in attestation quality is therefore a deployment-
specific task.  In Split Attester and Issuer deployments, Issuers can
choose to remove compromised Attesters from their trusted set until
the compromise is patched, without needing to modify Origin allow-
lists.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: From IETF 114 discussion : For the general captcha use cases , we do n't want websites to rely on privacy pass always working , to preventing locking out other clients . We should likely have discussion in the architecture document to suggest approaches to make sure servers ca n't rely on this for generic clients ( like browsers ) . Randomly not responding with tokens , other client - side heuristics . 
 I would put this in the auth - scheme document , where we already discuss user experience things . I 'll propose some text that we can wordsmith .
An origin MUST NOT assume that token challenges will always yield a
valid token.  Clients might experience issues running the issuance
protocol, e.g., because the attester or issuer is unavailable, or
clients might simply not support the requested token type.  Origins
SHOULD account for such operational or interoperability failures by
offering clients an alternative type of challenge such as CAPTCHA for
accessing a resource.
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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: From IANA : 
 LGTM pending suggestions .
The "Token Type" registry lists identifiers for issuance protocols
defined for use with the Privacy Pass token authentication scheme.
These identifiers are two-byte values, so the maximum possible value
is 0xFFFF = 65535.
IANA is requested to create a new "Privacy Pass Token Type" registry
in a new "Privacy Pass Parameters" page to list identifiers for
issuance protocols defined for use with the Privacy Pass token
authentication scheme.  These identifiers are two-byte values, so the
maximum possible value is 0xFFFF = 65535.
New entries in this registry are subject to the Specification
Required registration policy (RFC8126, Section 4.6).  Designated
experts need to ensure that the token type is sufficiently clearly
defined to be used for both token issuance and redemption, and meets
the common security and privacy requirements for issuance protocols
defined in Section 3.2 of ARCHITECTURE.
This registry also will also allow provisional registrations to allow
for experimentation with protocols being developed.  Designated
experts review, approve, and revoke provisional registrations.
Draft: draft-ietf-privacypass-protocol

Commentary: As raised by on the mailing list . Thanks ,
The Blind function is defined in OPRF, Section 3.3.2.  If the Blind
function fails, the Client aborts the protocol.  The Client stores
the nonce and challenge_digest values locally for use when finalizing
the issuance protocol to produce a token (as described in private-
finalize).
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 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 Token.nonce value is that which was sampled in private-request.
If the Finalize function fails, the Client aborts the protocol.
The rsabssa_blind function is defined in BLINDRSA, Section 5.1.1..
The Client stores the nonce and challenge_digest values locally for
use when finalizing the issuance protocol to produce a token (as
described in public-finalize).
The Token.nonce value is that which was sampled in private-request.
If the rsabssa_finalize function fails, the Client aborts the
protocol.
Draft: draft-ietf-privacypass-protocol

Commentary: This was previously underspecified , so hopefully this makes things clear . cc
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.
Draft: draft-ietf-privacypass-auth-scheme

Commentary: See .
Origins should only include challenges for different types of
issuance protocols with functionally equivalent properties.  For
instance, both issuance protocols in ISSUANCE have the same
functional properties, albeit with different mechanisms for verifying
the resulting tokens during redemption.  Since clients are free to
choose which challenge they want to consume when presented with
options, mixing multiple challenges with different functional
properties for one use case is nonsensical.
Draft: draft-ietf-privacypass-architecture

Commentary: See .
Issuer identity.  Tokens identify which issuers are trusted for a
given issuance protocol.
Issuer identity.  Tokens identify which Issuers are trusted for a
given issuance protocol.  The selected Issuer transitively
determines what types of attestation the Origin is willing to
accept.  For example, if a given Issuer "issuer.example" has two
trusted Attesters, then any Origin choosing "issuer.example" as
its Issuer is willing to accept attestation checks done by either
of these two Attesters.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions . This was raised in the previous WG meeting : This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem , and/or security considerations . There is also the option of declaring a separate document for addressing this . 
 A draft has been put forward for this by   : , and will be discussed at IETF 110 . Will leave this open for now , until this draft ( or some form of it ) is accepted .
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 participants are fit to operate as
participants in a Privacy Pass deployment.  This is precisely the
model used to control the Web's trust model.
Alternatively, Privacy Pass deployments might mitigate this problem
through implementation.  For example, rather than centralize the role
of attestation in one or few entities, attestation could be a
distributed function performed by a quorum of many parties, provided
that neither Issuers nor Origins learn which attester implementations
were chosen.  As a result, clients could have more opportunities to
switch between attestation participants.
Draft: draft-ietf-privacypass-protocol

Commentary: The publicly verifiable basic token issuance protocol does n't include an origin name that the issuer can see , so it does allow origins to be able to use that issuer ( as long as the know the key ) without explicit coordination or permission from the issuer . This is n't necessarily a problem , but we should likely mention it .
Otherwise, this variant is nearly identical.  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.
The output tokens are publicly verifiable by anyone with the
Issuer public key.
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.
Draft: draft-ietf-privacypass-architecture

Commentary: We current state this as the requirement : This could be misread in that we do allow forgeries when interacting with the Issuer directly . Clearly that 's not the intent , so let 's fix this .
One-more forgery security.  The issuance protocol MUST NOT allow
malicious Clients or Attesters (acting as Clients) to forge tokens
without interacting with the Issuer directly.
One-more forgery security.  The issuance protocol MUST NOT allow
malicious Clients or Attesters (acting as Clients) to forge tokens
offline or otherwise without interacting with the Issuer directly.
Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 draft - ietf - privacypass - architecture says in section 3.2 : Is that correct ? Is n't the ' token - key ' in draft - ietf - privacypass - auth - scheme providing the pub key ? Or do I misunderstand something here ? 
 Oops , yep , good catch ! We 'll fix this .
The mechanism by which clients obtain the Issuer public key is not
specified.  Clients may be configured with this key or they may
discover it via some other form.  See CONSISTENCY.
Clients obtain the Issuer public key directly from the Origin using
the process described in HTTP-Authentication.  Clients MAY apply some
form of key consistency check to determine if this public key is
consistency and correct for the specified Issuer.  See CONSISTENCY
for example mechanisms.  Depending on the deployment, the Attester
may be able to assist the Client in applying these consistency checks
across clients.
For certain types of issuance protocols, this model separates
attestation and redemption contexts.  However, Issuance protocols
that require the Issuer to learn information about the Origin, such
as that which is described in [rate-limited], are not appropriate
since they could link attestation and redemption contexts through the
Origin name.
For certain types of issuance protocols, this model separates
attestation and redemption contexts.  However, Issuance protocols
that require the Issuer to learn information about the Origin, such
as that which is described in RATE-LIMITED, are not appropriate since
they could link attestation and redemption contexts through the
Origin name.
This is the most general deployment model, and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see [rate-limited] for one such type of issuance protocol.
This is the most general deployment model, and is necessary for some
types of issuance protocols where the Attester plays a role in token
issuance; see RATE-LIMITED for one such type of issuance protocol.
Draft: draft-ietf-privacypass-protocol

Commentary: This is both a convenience for origins , as well as a way to support key rotation . 
 Thanks for this . IIUC the key rotation interval for non - rate - limited token issuance may be ambiguous . Since there is not necessarily a policy window defined in that case . Is that right ? This would be manageable be convention ; and trivial when a single entity controls both the issuer and origin . 
 Correct . The rotation window is currently not specified . Omitting that seems reasonable for this case . Origins can simply check in with issuers at some regular cadence as they deem fit . 
 The security considerations of the auth scheme should mention 0 - RTT specifically in its discussion of token replay .
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 Public Key values: an Issuer Public Key for an issuance
protocol.
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.
Each "token-keys" JSON object contains the following fields and
corresponding raw values.
Issuers MAY advertise multiple token-keys for the same token-type to
support key rotation.  In this case, Issuers indicate preference for
which token key to use based on the order of keys in the list, with
preference given to keys earlier in the list.
Draft: draft-ietf-privacypass-architecture

Commentary: The wording seems wrong , I think you meant token .
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer.  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.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce, to the Attester or Issuer.  The issuance
protocol can reveal the Issuer public key for the purposes of
determining which private key to use in producing the token.  A
result of this property is that the redemption flow is unlinkable
from the issuance flow.