Original text:
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. <del> This can used to reduce the secrecy for push subscription URLs by </del>  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 1. <del> The Web Push protocol I-D.ietf-webpush-protocol describes how an application server is able to request that a push service deliver a push message to a user agent. </del>  As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior 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 <del> the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </del>  An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While the special meaning described in RFC2119. The terms "push message", "push service", "push subscription", <del> "application server", and "user agent" are used as defined in I- D.ietf-webpush-protocol. </del>  2. that share the same origin. An "exp" (Expiry) claim MUST be included with the time after which <del> the token expires.  This limits the time that a token over which a token is valid.  An "exp" claim MUST NOT be more than 24 hours from the time of the request. </del>  This JWT is included in an Authorization header field, using an auth- scheme of "vapid".  A push service MAY reject a request with a 403 2.3. An application server requests the delivery of a push message as <del> described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field with credentials that use the "vapid" authentication scheme (auth). </del>  Note that the example header fields in this document include extra line wrapping to meet formatting constraints. this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del>  3.1. is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex- <del> push.  Extra whitespace is added to to meet formatting constraints. </del>  An application might use the Web Push API API to provide the user agent with a public key. 6.1. <del> This 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. </del>  Registrations MUST include the following information:

Reviewer comments:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.

Revised text:
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.  <ins> This can be used to reduce the secrecy for push subscription URLs by </ins> 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 1.  <ins> The Web Push protocol RFC8030 describes how an application server is able to request that a push service deliver a push message to a user agent. </ins> As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior 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  <ins> the protocol provides.  For these reasons, RFC8030 does not define a mandatory system for authentication of application servers. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While the special meaning described in RFC2119. The terms "push message", "push service", "push subscription",  <ins> "application server", and "user agent" are used as defined in RFC8030. </ins> 2. that share the same origin. An "exp" (Expiry) claim MUST be included with the time after which  <ins> 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. </ins> This JWT is included in an Authorization header field, using an auth- scheme of "vapid".  A push service MAY reject a request with a 403 2.3. An application server requests the delivery of a push message as  <ins> 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). </ins> Note that the example header fields in this document include extra line wrapping to meet formatting constraints. this authentication scheme. This authentication scheme is intended for use by an application  <ins> server when using the Web Push protocol RFC8030, but it could be used in other contexts if applicable. </ins> 3.1. is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex-  <ins> push.  Extra whitespace is added to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key. 6.1.  <ins> 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. </ins> Registrations MUST include the following information: