Code change:
scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. <ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </ins> 8.1. The protection afforded by TLS does not protect content from the push <del> service.  Without additional safeguards, a push service is able to see and modify the content of the messages. Applications are able to provide additional confidentiality, integrity or authentication mechanisms within the push message itself.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The process of providing the application server with subscription information provides a convenient medium for key agreement. The Web Push API codifies this practice by requiring that each push subscription created by the browser be bound to a browser generated encryption key.  Pushed messages are authenticated and decrypted by the browser before delivery to applications.  This scheme ensures that the push service is unable to examine the contents of push messages. The public key for a subscription ensures that applications using that subscription can identify messages from unknown sources and discard them.  This depends on the public key only being disclosed to entities that are authorized to send messages on the channel.  The push service does not require access to this public key. </del> <ins> service.  Without additional safeguards, a push service can inspect and modify the message content. For its requirements, the API has adopted I-D.ietf-webpush-encryption to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies. </ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used

Related discussion:
text: Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.