Draft: draft-ietf-webpush-vapid

Commentary: These are some suggested fixes for some nits that came up from the  write - up review .
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 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 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 A):
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.
Paragraph (version B):
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.
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.  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, RFC8030 does not define a
mandatory system for authentication of application servers.
Paragraph (version A):
The terms "push message", "push service", "push subscription",
"application server", and "user agent" are used as defined in I-
D.ietf-webpush-protocol.
Paragraph (version B):
The terms "push message", "push service", "push subscription",
"application server", and "user agent" are used as defined in
RFC8030.
Paragraph (version A):
An "exp" (Expiry) claim MUST be included with the time after which
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.
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.
Paragraph (version A):
An application server requests the delivery of a push message as
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).
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 (auth).
Paragraph (version A):
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.
Paragraph (version B):
This authentication scheme is intended for use by an application
server when using the Web Push protocol RFC8030, but it could be used
in other contexts if applicable.
Paragraph (version A):
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 B):
The example in ex-restrict shows a restriction to the key used in ex-
push.  Extra whitespace is added to meet formatting constraints.
Paragraph (version A):
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.
Paragraph (version B):
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.