Draft: draft-ietf-webpush-vapid

Commentary: This looks a lot worse than it really is . Reflowing text causes massive diffs , which github somehow manages to make look like entirely new text .
Paragraph (version A):
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 to a single application server.
Paragraph (version B):
An application server can use the method described to voluntarily
identify itself to a push service.  The "vapid" authentication scheme
allows a client to include its an identity in a signed token with
requests that it makes.  The signature can be used by the push
service to attribute requests that are made by the same application
server to a single entity.  The identification information can allow
the operator of a push service to contact the operator of the
application server.  The signature can be used to restrict the use of
a push subscription to a single application server.
Paragraph (version A):
An unfortunate consequence of this design is that a push service is
exposed to a greater risk of denial of service attack.  While
requests from application servers can be indirectly attributed to
user agents, this is not always efficient or even sufficient.
Providing more information about the application server directly to a
push service allows the push service to better distinguish between
legitimate and bogus requests.
Paragraph (version B):
An unfortunate consequence of the design of RFC8030 is that a push
service is exposed to a greater risk of denial of service attack.
While requests from application servers can be indirectly attributed
to user agents, this is not always efficient or even sufficient.
Providing more information about the application server directly to a
push service allows the push service to better distinguish between
legitimate and bogus requests.
Paragraph (version A):
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
(Forbidden) status code RFC7235 if the JWT signature or its claims
are invalid.
Paragraph (version B):
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
(Forbidden) status code RFC7235 if the JWT signature or its claims
are invalid.  A push service MUST NOT use information from an invalid
token.
Paragraph (version A):
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 B):
This authentication scheme is intended for use by an application
server when using the Web Push protocol RFC8030.
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-D.ietf-webpush-encryption and
signing the authentication token.  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):
Some elliptic curve 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 WEBPUSH-ENCRYPTION and
signing the authentication token.  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 A):
The user agent includes the public key of the application server when
requesting the creation of a push subscription.  This restricts use
of the resulting subscription to application servers that are able to
provide proof of possession for the corresponding private key.
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 media type of the body is
set to "application/webpush-options+json" (see mime for registration
of this media type).
Paragraph (version A):
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):
A user agent that wishes to create a restricted subscription includes
the public key of the application server when requesting the creation
of a push subscription.  This restricts use of the resulting
subscription to application servers that are able to provide proof of
possession for the corresponding private key.
Paragraph (version B):
The user agent then adds the public key 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.  The user agent adds a "vapid" member to this
JSON object that contains a 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 can ignore the body of a request to create a
subscription 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):
A push service MUST reject a message sent to a restricted push
subscription if that message includes no "vapid" authentication or
invalid "vapid" authentication.  A 401 (Unauthorized) status code
might be used if the authentication is absent; a 403 (Forbidden)
status code might be used if authentication is invalid.