jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-webpush-vapid

Commentary: This turned out to be easy enough . An empty challenge is n't difficult to define .
Paragraph (version A):
The "vapid" authentication scheme is used to identify the specific
profile of JWT defined in this document.  A different authentication
scheme is needed to update the signature algorithm or other
parameters.  This ensures that existing mechanisms for negotiating
authentication scheme can be used rather than defining new parameter
negotiation mechanisms.
Paragraph (version A):
An application server requests the delivery of a push message as
described in RFC8030.  If the application server wishes to self-
identify, it includes an Authorization header field with credentials
that use the "vapid" authentication scheme (auth).
Paragraph (version B):
The "vapid" HTTP authentication scheme (auth) is used to identify the
specific profile of JWT defined in this document.  A different
authentication scheme is needed to update the signature algorithm or
other parameters.  This ensures that existing mechanisms for
negotiating authentication scheme can be used rather than defining
new parameter negotiation mechanisms.
Paragraph (version B):
An application server requests the delivery of a push message as
described in RFC8030.  If the application server wishes to self-
identify, it includes an Authorization header field with credentials
that use the "vapid" authentication scheme.
Paragraph (version A):
This authentication scheme does not require a challenge.  Clients are
able to generate the Authorization header field without any
additional information from a server.  Therefore, a challenge for
this authentication scheme MUST NOT be sent in a WWW-Authenticate
header field.
Paragraph (version B):
The challenge for the "vapid" authentication scheme contains only the
"auth-scheme" production.  No parameters are currently defined.
Paragraph (version A):
This document creates a "Vapid Authentication Scheme Parameters"
registry for parameters to the "vapid" authentication scheme.  This
registry is under the "WebPush Parameters" grouping.  The registry
operates on the "Specification Required" policy RFC5226.
Paragraph (version B):
This document creates a "Vapid Authentication Scheme Parameters"
registry for parameters to the "vapid" authentication scheme.  These
parameters are defined for use in requests (in the Authorization
header field) and for challenges (in the WWW-Authenticate header
field).  This registry is under the "WebPush Parameters" grouping.
The registry operates on the "Specification Required" policy RFC5226.
Paragraph (version B):
The header field or header fields where the parameter can be used.
Draft: draft-ietf-webpush-vapid

Commentary: Just use HTTPS . It does n't hurt to say it one more time .
Paragraph (version A):
This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT.  Applying narrow limits to the
period over which a replayable token can be reused limits the
potential value of a stolen token to an attacker and can increase the
difficulty of stealing a token.
Paragraph (version B):
This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT.  Sending requests using HTTPS as
required by RFC8030 provides confidentiality.  Additionally, applying
narrow limits to the period over which a replayable token can be
reused limits the potential value of a stolen token to an attacker
and can increase the difficulty of stealing a token.
Draft: draft-ietf-webpush-vapid

Commentary: From the secdir review by   .
Paragraph (version A):
An "exp" (Expiry) claim MUST be included with the time after which
the token expires.  This limits the time over which a token is
valid.  An "exp" claim MUST NOT be more than 24 hours from the
time of the request.
Paragraph (version B):
An "exp" (Expiry) claim MUST be included with the time after which
the token expires.  This limits the time over which a token is
valid.  An "exp" claim MUST NOT be more than 24 hours from the
time of the request.  Limiting this to 24 hours balances the need
for reuse against the potential cost and likelihood of theft of a
valid token.
Draft: draft-ietf-webpush-vapid

Commentary: Small tweak suggested by   .
Paragraph (version A):
An application server that needs to replace its signing key needs to
create a new subscription that is restricted to the updated key.
Application servers need to remember the key that was used when
creating a given subscription.
Paragraph (version B):
An application server that needs to replace its signing key needs to
request the creation of a new subscription by the user agent that is
restricted to the updated key.  Application servers need to remember
the key that was used when requesting the creation of a subscription.
Draft: draft-ietf-webpush-vapid

Commentary: I 'm including all of the nits found . 
 LGTM , thanks !
Paragraph (version A):
An application server can voluntarily identify itself to a push
service using the described technique.  This identification
information can be used by the push service to attribute requests
that are made by the same application server to a single entity.
This can be used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application
server.  An application server is further able to include additional
information that the operator of a push service can use to contact
the operator of the application server.
Paragraph (version B):
An application server can use the method described to voluntarily
identify itself to a push service.  This identification information
can be used by the push service to attribute requests that are made
by the same application server to a single entity.  An application
server can include additional information that the operator of a push
service can use to contact the operator of the application server.
This identification information can be used to restrict the use of a
push subscription a single application server.
Paragraph (version A):
The "t" parameter of the Authorization header field contains a JWT;
the "k" parameter includes the base64url-encoded key that signed that
token.  The JWT input values and the JWK RFC7517 corresponding to the
signing key are shown in ex-decoded with additional whitespace added
for readability purposes.  This JWT would be valid until
2016-01-21T01:53:25Z RFC3339.
Paragraph (version B):
The "t" parameter of the Authorization header field contains a JWT;
the "k" parameter includes the base64url-encoded key that signed that
token.  The JWT input values and the JWK RFC7517 corresponding to the
signing key are shown in ex-decoded with additional whitespace added
for readability purposes.  This JWT would be valid until
2016-01-23T04:36:08Z RFC3339.
Draft: draft-ietf-webpush-vapid

Commentary: This is what we 've agreed to .
Paragraph (version B):
The "vapid" authentication scheme is used to identify the specific
profile of JWT defined in this document.  A different authentication
scheme is needed to update the signature algorithm or other
parameters.  This ensures that existing mechanisms for negotiating
authentication scheme can be used rather than defining new parameter
negotiation mechanisms.
Draft: draft-ietf-webpush-vapid

Commentary: As suggested by
Paragraph (version A):
The public key is then added to the request to create a push
subscription.  The push subscription request is extended to include a
body.  The body of the request is a JSON object as described in
RFC7159.  A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form
X9.62 and base64url encoded RFC7515.  The MIME media type of the body
is set to "application/json".
Paragraph (version B):
The public key is then added to the request to create a push
subscription.  The push subscription request is extended to include a
body.  The body of the request is a JSON object as described in
RFC7159.  A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form
X9.62 and base64url encoded RFC7515.  The media type of the body is
set to "application/webpush-options+json" (see mime for registration
of this media type).
Paragraph (version B):
A push service MUST ignore the body of a request that uses a
different media type.  For the "application/webpush-options+json"
media type, a push service MUST ignore any members on this object
that it does not understand.
Paragraph (version B):
This document registers a new authentication scheme, a registry for
parameters of that scheme, and media type for push options.
Paragraph (version B):
This document registers the "application/webpush-options+json" media
type in the "Media Types" registry following the process described in
RFC6838.
Paragraph (version B):
See RFC7159 for security considerations specific to JSON.
Paragraph (version B):
See RFC7159 for interoperability considerations specific to JSON.
Paragraph (version B):
This document.
Paragraph (version B):
Web browsers, via the Web Push Protocol RFC8030.
Paragraph (version B):
None, see RFC7159.
Paragraph (version B):
For use with the Web Push Protocol RFC8030.
Paragraph (version B):
See "Authors' Addresses" section of this document.
Draft: draft-ietf-webpush-vapid

Commentary: In response to the review from PTAL .
Paragraph (version A):
An application server that needs to replace its signing key needs to
create a new subscriptions that are restricted to the updated key.
Application servers need to remember the key that was used when
creating a given subscription.
Paragraph (version B):
An application server that needs to replace its signing key needs to
create a new subscription that is restricted to the updated key.
Application servers need to remember the key that was used when
creating a given subscription.
Draft: draft-ietf-webpush-vapid

Commentary: I know that it 's the devil , but  is the obvious choice here . 
 Why would it be obvious ? application / x - www - form - urlencoded or a request parameter ? 
 It 's an obvious choice given the proprietary precedence in the industry . I ca n't really judge the appropriateness of using  as opposed to an alternative -- this change LGTM assuming it is . Since the UA chooses the PS , there is no need for encryption . JSON provides good extensibility for additional ( proprietary ) data that may have to be transmitted over this channel . 
 At least it 's not xml ... I do n't mind json - just did n't think it is so obvious . It does open an important question : will the user be allowed to pass more information to the push service ( voluntarily ) ? But +1 on this change . 
 Probably , but I do n't want to think about that just yet :)
Paragraph (version B):
The public key is then added to the request to create a push
subscription.  The push subscription request is extended to include a
body.  The body of the request is a JSON object as described in
RFC7159.  A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form
X9.62 and base64url encoded RFC7515.  The MIME media type of the body
is set to "application/json".
Paragraph (version B):
The example in ex-restrict shows a restriction to the key used in ex-
push.  Extra whitespace is added to to meet formatting constraints.
Paragraph (version A):
This registers the "vapid" authentication scheme in the "Hypertext
Transfer Protocol (HTTP) Authentication Scheme Registry" established
in RFC7235.
Paragraph (version B):
This document registers the "vapid" authentication scheme in the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
established in RFC7235.
Paragraph (version A):
This registers a "vapid" parameter for the Crypto-Key header field in
the "Hypertext Transfer Protocol (HTTP) Crypto-Key Parameters"
established in I-D.ietf-httpbis-encryption-encoding.
Draft: draft-ietf-webpush-vapid

Commentary:     ! 
 From authenticated with VAPID , all subsequent subscribe , unsubscribe , ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key " already needs to have code to handle EC for the e2e encryption . The main concern is an attacker ' acking ' or unsubscribing - since the messages are e2e encrypted they ca n't read it . 
 This looks good to me .
Paragraph (version A):
This authentication scheme is intended for use by an application
server when using the webpush protocol I-D.ietf-webpush-protocol, but
it could be used in other contexts if applicable.
Paragraph (version B):
This authentication scheme is intended for use by an application
server when using the Web Push protocol I-D.ietf-webpush-protocol,
but it could be used in other contexts if applicable.
Draft: draft-ietf-webpush-vapid

Commentary: LGTM , thank you ! Is the addition required because of the following language in 7519 ? 
 Well , that 's a good reason , but is the main reason . See the discussion leading up to that . 
 I read the thread and issue ; reading JWT , there was nothing prohibiting providing additional fields ( aside from that SHOULD ) , so I was wondering if specifying this is a normative requirement or a good clarification :-) . 
 If I may , clarification is always good . One should presume that the readers of these specs may not be fully versed in the subtle details of other , reliant specs , so a bit of useful info like this might be very welcome . 
 As noted in the arguments of , there is a need for an " extra data " field which would be used by the parties using the VAPID claims . This data would contain information useful to the publisher of the claim ( e.g. the originating server ID , transaction ID , or other possibly VAPID consumer opaque data ) . This extra data ( " vapid - ext " ? ) field would allow consistent , predictable definition rather than a set of ' one - offs ' that may be difficult to find or ignored by operators . 
 Started thread :
Mailing list commentary: requests that we allow the inclusion of extra stuff in a vapid token : As noted in the arguments of # 23 , there is a need for an " extra data " field which would be used by the parties using the VAPID claims . This data would contain information useful to the publisher of the claim ( e.g. the originating server ID , transaction ID , or other possibly VAPID consumer opaque data ) . This extra data ( " vapid - ext " ? ) field would allow consistent , predictable definition rather than a set of ' one - offs ' that may be difficult to find or ignored by operators . < < < I think that the general idea is fine . Better this than trying to pack the " sub " field with extra stuff . , would it suffice to point out that the ( or even ) claims can be to the token ? Allowing multiple fields gives the application server a fair bit more flexibility . If that 's OK , we should point out that this is possible so that push services do n't lose the extra data because they are n't aware that it might exist .
Paragraph (version B):
An application server MAY include additional claims using public or
private names (see Sections 4.2 and 4.3 of RFC7519).  Since the JWT
is in a header field, the size of additional claims SHOULD be kept as
small as possible.
Draft: draft-thomson-webpush-vapid

Commentary: As this is the naming used by encryption - encoding-01 :
Paragraph (version A):
Note that with push message encryption I-D.ietf-webpush-encryption,
this results in two values in the Crypto-Key header field, one with
the a "p256dh" key and another with a "p256ecdsa" key.
Paragraph (version A):
Some implementations permit the same P-256 key to be used for signing
and key exchange.  An application server MUST select a different
private key for the key exchange (i.e., "p256dh") and signing (i.e.,
"p256ecdsa").  Though a push service is not obligated to check either
parameter for every push message, a push service SHOULD reject push
messages that have identical values for these parameters with a 400
(Bad Request) status code.
Paragraph (version B):
Note that with push message encryption I-D.ietf-webpush-encryption,
this results in two values in the Crypto-Key header field, one with
the a "dh" key and another with a "p256ecdsa" key.
Paragraph (version B):
Some implementations permit the same P-256 key to be used for signing
and key exchange.  An application server MUST select a different
private key for the key exchange (i.e., "dh") and signing (i.e.,
"p256ecdsa").  Though a push service is not obligated to check either
parameter for every push message, a push service SHOULD reject push
messages that have identical values for these parameters with a 400
(Bad Request) status code.
Draft: draft-thomson-webpush-vapid

Commentary: This was either in error , or could refer to " JWT " instead . 
 There are multiple references to a token that are unclear : ... 
 The first is just a mistake ; a relic of a previous version . It can be removed . The second refers to JWT . I 'll fix that .
Paragraph (version A):
When a push subscription has been associated with an application
server, the request for push message delivery MUST include proof of
possession for the associated private key or token that was used when
creating the push subscription.
Paragraph (version B):
When a push subscription has been associated with an application
server, the request for push message delivery MUST include proof of
possession for the associated private key that was used when creating
the push subscription.
Paragraph (version A):
A push subscription that is not restricted to a particular key MAY
still validate a token that is present, except for the last check.  A
push service MAY then reject a request if the token is found to be
invalid.
Draft: draft-thomson-webpush-vapid

Commentary: What is " that segment " ? 
 Optimizations , like dropping the header segment , tend to be problematic for some implementers , particularly since the final signature is derived from the first two segments . Also , dropping the header segment prevents possible future changes for encryption types , versioning , or other potentially required items . 
 Agreed . I was requesting clarification because it was unclear what omission was being proposed . For example , if it was the header , then that would be a problem because states that the alg parameter MUST be present and MUST be understood and processed by implementations . 
 I 'll confirm with the list , but is right here . We can pay a little extra here . It will mean that there is some possibility of variation in the header ( whitespace ) , but we know how to do that .
Paragraph (version A):
The first part of the JWT is effectively fixed.  Would be it
acceptable to require that that segment is omitted from the header
field?
Draft: draft-thomson-webpush-vapid

Commentary: " This " meaning the value of the Authorization header ?
Paragraph (version A):
This equates to a JWT with the header and body shown in ex-jwt.  This
JWT would be valid until 2016-01-21T01:53:25Z RFC3339.
Paragraph (version B):
The value of the Authorization header field is a base64url-encoded
JWT with the header and body shown in ex-jwt.  This JWT would be
valid until 2016-01-21T01:53:25Z RFC3339.
Draft: draft-thomson-webpush-vapid

Commentary: 1 Application Server Self - Identification Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature ( ECDSA ) over the P-256 curve [ FIPS186 ] . What is the rationale for SHOULD rather than MUST ?
Paragraph (version A):
Application servers SHOULD generate and maintain a signing key pair
usable with elliptic curve digital signature (ECDSA) over the P-256
curve FIPS186.  Use of this key when sending push messages
establishes a continuous identity for the application server.
Paragraph (version B):
Application servers that wish to self-identity generate and maintain
a signing key pair.  This key pair MUST be usable with elliptic curve
digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this
key when sending push messages establishes an identity for the
application server that is consistent across multiple messages.
Draft: draft-thomson-webpush-vapid

Commentary: This closes but does not completely address ? 
 You mean that I missed yes , I missed that on my first check . Let me know if you find anything else . ( I have n't used the header field in the example to concentrate on the important bits . ) 
 By the same measure , requesting the creation of a subscription for push message receipts has no prior authentication . In webpush-05 , there is no longer an explicit request to create such a subscription . It 's created implicitly as the result of requesting a push message delivery with receipts . In webpush-05 , this changes to : and a reference to RFC7240 .
Paragraph (version A):
As a consequence of the expected deployment architecture, there is no
basis for an application server to be known to a push service prior
to requesting delivery of a push message.  By the same measure,
requesting the creation of a subscription for push message receipts
has no prior authentication.  Requiring that the push service be able
to authenticate application servers places an unwanted constraint on
the interactions between user agents and application servers, who are
the ultimate users of a push service.  That constraint would also
degrade the privacy-preserving properties the protocol provides.  For
these reasons, I-D.ietf-webpush-protocol does not define a mandatory
system for authentication of application servers.
Paragraph (version B):
As a consequence of the expected deployment architecture, there is no
basis for an application server to be known to a push service prior
to requesting delivery of a push message.  Requiring that the push
service be able to authenticate application servers places an
unwanted constraint on the interactions between user agents and
application servers, who are the ultimate users of a push service.
That constraint would also degrade the privacy-preserving properties
the protocol provides.  For these reasons, I-D.ietf-webpush-protocol
does not define a mandatory system for authentication of application
servers.
Draft: draft-thomson-webpush-vapid

Commentary: Enacting the good suggestion from with a little more prejudice than he might have anticipated .
Paragraph (version B):
Some implementations permit the same P-256 key to be used for signing
and key exchange.  An application server MUST select a different
private key for the key exchange (i.e., "p256dh") and signing (i.e.,
"p256ecdsa").  Though a push service is not obligated to check either
parameter for every push message, a push service SHOULD reject push
messages that have identical values for these parameters with a 400
(Bad Request) status code.