Original text:
of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key. <del> This public key is then added to the request to create a push subscription as described in key.  The Crypto-Key header field includes exactly one ECDSA public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url RFC7515.  The example in ex-restrict shows a restriction to the key used in ex-push: </del>  An application might use the Web Push API API to provide the user agent with a public key. 6. <del> 6.1. This registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </del>  vapid This scheme is origin-server only and does not define a challenge. <del> 6.2. </del>  This creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is of the parameter. This registry initially contains the following entries: <del> 6.3. 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. vapid An ECDSA public key for use in validating vapid tokens restrict of this document </del>

Reviewer comments:
I know that it's the devil, but JSON 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 can't really judge the appropriateness of using JSON 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 don't mind json - just didn'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 don't want to think about that just yet :)

Revised text:
of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key.  <ins> 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". The example in ex-restrict shows a restriction to the key used in ex- push.  Extra whitespace is added to to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key. 6.  <ins> This document registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </ins> vapid This scheme is origin-server only and does not define a challenge.  <ins> 6.1. </ins> This creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is of the parameter. This registry initially contains the following entries: