Draft: draft-ietf-webpush-protocol

Commentary: 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 do n'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 for the separate drafts for optional content encoding and authentication . 
 Moving to -05 . Waiting for a decision on the VAPID call for adoption .
Paragraph (version A):
Requesting the delivery of events is particularly important for the
Web Push API.  The subscription, management and monitoring functions
are currently fulfilled by proprietary protocols; these are adequate,
but do not offer any of the advantages that standardization affords.
Paragraph (version B):
Requesting the delivery of events is particularly important for the
W3C Push API.  The subscription, management and monitoring functions
are currently fulfilled by proprietary protocols; these are adequate,
but do not offer any of the advantages that standardization affords.
Paragraph (version A):
The protection afforded by TLS does not protect content from the push
service.  Without additional safeguards, a push service is able to
see and modify the content of the messages.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
The protection afforded by TLS does not protect content from the push
service.  Without additional safeguards, a push service can inspect
and modify the message content.
Paragraph (version B):
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.
Paragraph (version A):
Discarding unwanted messages at the user agent based on message
authentication doesn't protect against a denial of service attack on
the user agent.  Even a relatively small volume of push messages can
cause battery-powered devices to exhaust power reserves.
Paragraph (version A):
An application can limit where valid push messages can originate by
limiting the distribution of push URIs to authorized entities.
Ensuring that push URIs are hard to guess ensures that only
application servers that have been given a push URI can use it.
Paragraph (version B):
A user agent can control where valid push messages originate by
limiting the distribution of push URIs to authorized application
servers.  Ensuring that push URIs are hard to guess ensures that only
application servers that have received a push URI can use it.
Paragraph (version B):
Push messages that are not successfully authenticated by the user
agent will not be delivered, but this can present a denial of service
risk.  Even a relatively small volume of push messages can cause
battery-powered devices to exhaust power reserves.
Paragraph (version B):
To address this case, the API has adopted I-D.ietf-webpush-vapid,
which allows a user agent to restrict a subscription to a specific
application server.  The push service can then identity and reject
unwanted messages without contacting the user agent.
Paragraph (version A):
End-to-end confidentiality mechanisms, such as those in API, prevent
an entity with a valid push message subscription URI from learning
the contents of push messages.  Push messages that are not
successfully authenticated will not be delivered by the API, but this
can present a denial of service risk.
Paragraph (version A):
Conversely, a push service is also able to deny service to user
agents.  Intentional failure to deliver messages is difficult to
distinguish from faults, which might occur due to transient network
errors, interruptions in user agent availability, or genuine service
outages.
Paragraph (version A):
Server request logs can reveal subscription-related URIs.  Acquiring
a push message subscription URI enables the receipt of messages or
deletion of the subscription.  Acquiring a push URI permits the
sending of push messages.  Logging could also reveal relationships
between different subscription-related URIs for the same user agent.
Encrypted message contents are not revealed to the push service.
Paragraph (version A):
Limitations on log retention and strong access control mechanisms can
ensure that URIs are not learned by unauthorized entities.
Paragraph (version B):
A push service is also able to deny service to user agents.
Intentional failure to deliver messages is difficult to distinguish
from faults, which might occur due to transient network errors,
interruptions in user agent availability, or genuine service outages.
Paragraph (version B):
Server request logs can reveal subscription-related URIs or
relationships between subscription-related URIs for the same user
agent.  Limitations on log retention and strong access control
mechanisms can ensure that URIs are not revealed to unauthorized
entities.