agent and the push service and shared with the application server. All push messages are associated with a push message subscription.  A message sent from an application server to a user agent via a push service. into user agents. This resource provides read and delete access for a message <del> subscription.  A user agent monitor using a push message subscription.  Every push message subscription has exactly one push resource associated with it. </del>  A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type ensure that these URIs are not disclosed to unauthorized recipients (see authorization).  4. An application server requests the creation of a receipt subscription send the contents of push messages as they are sent by application servers. <del> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The response body is the entity body from the most recent request sent to the push resource. </del>  <del> In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push and receipt subscribe resources. </del>  A user agent can request the contents of the push message <del> subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0". </del>  A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. <del> 6.1. </del>  To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message failure response to the application server monitoring the receipt subscription resource. <del> 6.2. </del>  The application server requests the delivery of receipts from the push service by making a HTTP GET request to the receipt subscription instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. <del> Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was created by the push service when the application server requested message delivery.  A successful response includes a 410 (GONE) status code with no data. </del>  If the user agent fails to acknowledge the receipt of the push message and the push service ceases to retry delivery of the message A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a <del> subscription resource (see monitor), this can be signaled by returning a 400-series status code, such as 410 (Gone). </del>  A user agent or application server can request that a subscription be removed by sending a DELETE request to the push message subscription Found) or 410 (Gone) if an application server attempts to send a push message to a removed or expired push message subscription.  7.4. A push service that does not support reliable delivery over transient (e.g. an incoming call) or messages that are quickly superceded (e.g. the current number of unread emails).  8. This protocol MUST use RFC2818.  This includes any communications The Web Push WG (webpush@ietf.org) <del> urn:ietf:params:push:receipt </del>  This link relation type is used to identify a resource for creating new push message receipt subscriptions.

These are the initial and incomplete changes related to the subscription set feature. One remaining gap is how a push service correlates two different subscriptions. See the for the related thread.
Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the subscription set with the connection, and a server may then associate new subscriptions with the outstanding subscription set request. This could also provide a client with a way to manage 'groups' of subscription sets, since it could assume that the last subscription set it asked for is what new subscriptions on that connection will be attached to. This could be useful for the IoT use-cases where a client might want to have some input on which subscriptions are grouped together.
I was thinking even simpler for correlation: include link relation to a subscription set in the request. That allows clients to share a connection without risking the server creating a set that they can't use. For instance, applications using URL on windows could use the same HTTP/2 connection to a server (though I don't think that they do, the protocol permits, even encourages it). However, they might independently want to use push. Sharing a subscription set is not entirely practical in this case. Good point. In earlier discussions, one proposal was to pass the first subscription resource that was created (as parent) with subsequent subscription requests (children) to provide that common link between the user agent and push service. This allowed the user agent to make the decision to aggregate or not. If it did not pass a parent subscription, then the push service could not aggregate the separate subscriptions. My thought was to avoid 'special' properties on the first subscription. The subscription set ensures a clean separation between operations on aggregated and individual subscriptions. For example, the user agent can continue to GET (or poll) and DELETE individual subscriptions - including the first one. To enable the current proposal where the push service makes the decision to aggregate, there must be some form of client authentication/identification included with the subscription request in order for a push service to correlate the subscriptions. Darshak noted this in a previous message: I’m not sure how a PS can force a UA to aggregate (unless the PS somehow identifies the client based on authentication/cookie/something-else). I may be taking it out of context as "something-else", but Benjamin also commented: I'm associating one h2 connection as being one UA

agent and the push service and shared with the application server. All push messages are associated with a push message subscription. <ins> A message delivery context that is established between the user agent and the push service that collects multiple push message subscriptions into a set. </ins> A message sent from an application server to a user agent via a push service. into user agents. This resource provides read and delete access for a message  <ins> subscription.  A user agent monitor-subscription using a push message subscription.  Every push message subscription has exactly one push resource associated with it. This resource provides read and delete access for a collection of push message subscriptions.  A user agent monitor-set for all the push message subscriptions in the set.  A link relation of type "urn:ietf:params:push:set" identifies a push message subscription set. </ins> A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type ensure that these URIs are not disclosed to unauthorized recipients (see authorization). <ins> The push service MAY provide a URI for a subscription set resource in a link relation of type "urn:ietf:params:push:set".  If provided, the push service supports subscription sets.  If available, the user agent SHOULD use the subscription set to receive push messages rather than individual push message subscriptions. The push service MAY return new subscription sets in response to different subscription requests from the same user agent.  This allows the push service to control the grouping of the push message subscriptions. 3.1. PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </ins> 4. An application server requests the creation of a receipt subscription send the contents of push messages as they are sent by application servers.  <ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push" and a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by the application server. A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. 6.1. </ins>  <ins> There are minor differences between receiving push messages for a subscription and a subscripion set. A user agent requests the delivery of new push messages for a collection of push message subscriptions by making a GET request to a push message subscription set resource.  The push service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The synthetic request MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate the source of the message.  The response headers SHOULD provide a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by an application server. </ins> A user agent can request the contents of the push message  <ins> subscription set resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. </ins> A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired.  <ins> 6.2. </ins> To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message failure response to the application server monitoring the receipt subscription resource.  <ins> 6.3. </ins> The application server requests the delivery of receipts from the push service by making a HTTP GET request to the receipt subscription instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent.  <ins> Each receipt is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the same push message resource that was created by the push service when the application server requested message delivery.  A successful response includes a 410 (GONE) status code with no data. </ins> If the user agent fails to acknowledge the receipt of the push message and the push service ceases to retry delivery of the message A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a  <ins> subscription resource (see monitor-subscription), this can be signaled by returning a 400-series status code, such as 410 (Gone). </ins> A user agent or application server can request that a subscription be removed by sending a DELETE request to the push message subscription Found) or 410 (Gone) if an application server attempts to send a push message to a removed or expired push message subscription. <ins> 7.3.1. A push service MAY expire a subscription set at any time which MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (see monitor-set) this can be signaled by returning a 400-series status code, such as 410 (Gone). A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also remove all push message subscriptions in the set. If a specific push message subscription that is a member of a subscription set is expired or removed, then it MUST also be removed from its subscription set. </ins> 7.4. A push service that does not support reliable delivery over transient (e.g. an incoming call) or messages that are quickly superceded (e.g. the current number of unread emails). <ins> 7.5. If the push service requires that the user agent use push message subscription sets, then it MAY limit the number of concurrently active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter within a HTTP/2 SETTINGS frame RFC7540.  The user agent MAY be limited to one concurrent stream to manage push message subscriptions and one concurrent stream for each subscription set returned by the push service.  This could force the user agent to serialize subscription requests to the push service. </ins> 8. This protocol MUST use RFC2818.  This includes any communications The Web Push WG (webpush@ietf.org)  <ins> urn:ietf:params:push:set This link relation type is used to identify a collection of push message subscriptions. (this document) The Web Push WG (webpush@ietf.org) urn:ietf:params:push:receipts </ins> This link relation type is used to identify a resource for creating new push message receipt subscriptions.


application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type <del> "urn:ietf:params:push" and a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by the application server. </del>  A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate <del> the source of the message.  The response headers SHOULD provide a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by an application server. </del>  A user agent can request the contents of the push message subscription set resource immediately by including a RFC7240 with a

LGTM, just one nit.
I think that having the push service return the link relation on requests to subscriptions (and subscription sets) is enough. I think that perhaps it was added to push messages in error.
cc NAME

application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type  <ins> "urn:ietf:params:push".  The response body is the entity body from the most recent request sent to the push resource by the application server. </ins> A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate  <ins> the source of the message.  The response body is the entity body from the most recent request sent to the push resource by an application server. </ins> A user agent can request the contents of the push message subscription set resource immediately by including a RFC7240 with a


application server by a user agent.  The push message is included in the body of the request. <del> A push service MAY generate a 413 (Payload Too Large) status code in response to requests that include an entity body that is too large. Push services MUST NOT generate a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </del>  5.1.

Looks good aside from that one thing, the resolution of which I'll leave to your discretion.
As discussed in cc NAME The earlier proposal from JR - URL - was to include a reference to 429 with Retry-Header: URL The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request. For example: HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 Would this address your requirements? ...Brian

application server by a user agent.  The push message is included in the body of the request.  <ins> A push service MAY return a 429 (Too Many Requests) status code RFC6585 when an application server has exceeded its rate limit for push message delivery to a push resource.  The push service SHOULD also include a Retry-After header RFC7231 to indicate how long the application server is requested to wait before it makes another request to the push resource. A push service MAY return a 413 (Payload Too Large) status code RFC7231 in response to requests that include an entity body that is too large.  Push services MUST NOT return a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </ins> 5.1.


4.1. <del> PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </del>  5.

This replaces the PENDING section on correlation. I know that NAME wanted to simply rely on ambient authority of some sort, but I think that this is the cleanest option. It doesn't cost us anything significant either.
Does the PS return the push:set with each subscribe response or just the first one? If returned in all cases, can the push:set change between responses? If so, does the UA MUST use the latest one? For a PS that wants to strongly require aggregation - besides using concurrent stream limits - can it return an error if the push:set is not included?
Good questions, both of them, I'll add a commit that answers them (rather than answer them in these comments).
Answers provided (more words added)...

4.1.  <ins> The aggregation of multiple subscriptions into a subscription set can represent a significant efficiency improvement for a push service. For that reason, if a subscription set is available, a user agent MUST indicate an existing subscription set in a request to create a subscription.  However, a user agent MAY omit the subscription set if it is unable to receive push messages that are aggregated for the lifetime of the subscription.  This might be necessary if the user agent is forwarding requests from other clients. The user agent adds a subscription set link relation to the request to create a subscription.  This indicates which subscription set the subscription is to be bound to. This gives the push service the option to create a subscription within an existing subscription set.  The push service returns the same subscription set in the response, though it MAY use a new subscription set if it is unable to reuse the provided one. A push service MAY reject a request if it contains an unknown or invalid subscription set, or a request that does not include a subscription set.  An 429 status code can be used to indicate that too many requests to create subscriptions sets were made. How a push service detects that requests come from the same user agent is implementation-dependent and could take ambient information into consideration, such as the TLS connection, source IP address and port.  Implementers are reminded that using some heuristics can produce false positives and cause requests to be rejected incorrectly. </ins> 5.


A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type <del> "urn:ietf:params:push" is used to identify a push resource. </del>  A push message resource is created to identify push messages that have been accepted by the push service.  The push message resource A receipt subscribe resource is used by an application server to create a receipt subscription (see receipt_subscription).  A link <del> relation of type "urn:ietf:params:push:receipt" is used to identity a receipt subscribe resource. </del>  An application server request_receipt for push messages using a <del> receipt subscription. </del>  3. of type "urn:ietf:params:push". The push service MUST provide a URI for a receipt subscribe resource <del> in a link relation of type "urn:ietf:params:push:receipt". </del>  An application-specific method is used to distribute the push and receipt subscribe URIs to the application server.  Confidentiality 6.1. <del> An application server can use the Push-Receipt header field to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent.  The Push-Receipt header field is a URI-Reference as defined in Section 2.7 of RFC7230. </del>  <del> The application sets the Push-Receipt header field value to a receipt </del>  subscription URI.  This receipt subscription resource MUST be created from the same receipt subscribe resource which was returned with the push message subscription response (see message_subscription). urn:ietf:params:push:receipt This link relation type is used to identify a resource for <del> creating new push message receipt subscriptions. </del>  (this document)

Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.

A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type  <ins> "urn:ietf:params:push" identifies a push resource. </ins> A push message resource is created to identify push messages that have been accepted by the push service.  The push message resource A receipt subscribe resource is used by an application server to create a receipt subscription (see receipt_subscription).  A link  <ins> relation of type "urn:ietf:params:push:receipts" identifies a receipt subscribe resource. </ins> An application server request_receipt for push messages using a  <ins> receipt subscription.  A link relation of type "urn:ietf:params:push:receipt" is identifies a receipt subscription. </ins> 3. of type "urn:ietf:params:push". The push service MUST provide a URI for a receipt subscribe resource  <ins> in a link relation of type "urn:ietf:params:push:receipts". </ins> An application-specific method is used to distribute the push and receipt subscribe URIs to the application server.  Confidentiality 6.1.  <ins> An application server can use the "urn:ietf:params:push:receipt" link relation type to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent. </ins>  <ins> The application sets the link relation value to a receipt </ins> subscription URI.  This receipt subscription resource MUST be created from the same receipt subscribe resource which was returned with the push message subscription response (see message_subscription). urn:ietf:params:push:receipt This link relation type is used to identify a resource for  <ins> receiving delivery confirmations for push messages. (this document) The Web Push WG (webpush@ietf.org) urn:ietf:params:push:receipts This link relation type is used to identify a resource for subscribing to delivery confirmations for push messages. </ins> (this document)


call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert. <del> An application server can use the TTL header field to limit the time that a push message is retained by a push service.  The TTL header field contains a value in seconds that describes how long a push message is retained by the push service. Once the Time-To-Live (TTL) period elapses, the push service MUST NOT attempt to deliver the push message to the user agent.  A push service might adjust the TTL value to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays. </del>  A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or application server needs to account for transit delays in selecting a TTL header field value. <del> Absence of the TTL header field is interpreted as equivalent to a zero value.  A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message.  After delivery, the push service is permitted to immediately remove a push message with a zero TTL.  This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource.  Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. </del>  If the user agent is unavailable, a push message with a zero TTL expires and is never delivered. <del> A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL header field in the response that includes the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. </del> 6.3. A push message that has been stored by the push service can be For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64 alphabet RFC4648.  A push service that receives a request with a <del> Topic header field that does not meet these constraints MUST return an HTTP 400 (Bad Request) status code to the application server. </del>  A push message update request creates a new push message resource and simultaneously deletes any existing message resource that has a

As discussed on the , requiring the TTL header field will simplify implementations and avoid potential errors. A 400 (Bad Request) MUST be returned by the push service if the TTL header field is missing.
NAME notes that prioritization can be important. This is true. Maybe look at somehow integrating URL
First, we need to clarify whether there are scenarios that require priorities to be included in the base specification: NAME : As I went through the draft I wasn't able to understand how the push service will handle message prioritization (for the same subscription). Is the expectation that the app server will send them in the right sequence and the push server will use a FIFO (first in first out) queue? The scenario I have in mind is a social network application that can push news alerts and incoming chat notifications. I would expect the chat notification to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push service that will be able to act based on some form of prioritization indicator. Priority is a fairly basic requirement and I hope it can get handled in a header so it can be consistently enforced by the push service. NAME : Prioritization is a concern if there are multiple messages to deliver at the same time. This happens most often when a device comes back from a short nap (as mobile devices do all the time). With a small number of messages, this might not be a big deal, but if there is a backlog to clear, it could be. I have a draft on signaling priorities that could be used in this context: URL
Once we have clarity on scenarios and requirements and evaluated the importance of this feature, then we can consider designs. NAME has proposed nice-02 for the scenario above. NAME : Would it make sense to use the Prefer header instead of the TTL header. This would allow carrying prioritization info for messages (the prioritization is only relative to the application server's own set of messages) to be carried in the Prefer header (e.g. Prefer: priority=5, wait=10). Also the wait 0 can be used to indicate the equivalent of TTL 0 or we can even define a new preference token. NAME : Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work._
Discussed in Yokohama: we will leave this out of the core document; we will await a proposal that we can use as the basis for further discussion.
Priority is too overloaded a term, since it may refer to: Message Ordering Urgency ("Niceness") as in "Is it urgent enough to wake the device and burn the battery?" Updating this issue to be specific to urgency. I plan to adapt and integrate Martin's as a proposed solution. For example: Nice 0 - send urgent message immediately and wake up the user agent Nice 1 - send opportunistically – send prior to expiration if no urgent messages are queued Nice 2 - send opportunistically – allow to expire if no urgent messages are queued
We plan to include the Nice header in an upcoming version of our implementation with the following deliberate violation: Requests not bearing the Nice header will be treated as messages of default priority (similar to Nice: 1 in Brian's description). The issue of defaulting to high priority is that the consequences of forgetting to include the header (waking up the UA) are disproportionate to the error - especially for more active users or users using a lower end device, this can have a very negative effect on the device's battery life. There's definite value in allowing the push service to optimize for the default case. The application server can then supply the Nice header to clarify the intent and urgency of the message.
NAME this is interesting. I'd like to reach some sort of consensus on how to present priority, especially defaults. Would recasting the header field into a three-valued enumeration of high/normal/low be a better fit for your use case? Webpush might interpret high as needing an urgent wakeup and low as being something that could wait until there were other messages to send. At that point, we might as well call it Priority it's no longer really appropriate to call it :( That suggests values of urgent, normal and non-urgent such as are used in the mail header field, which might be a better choice.
I have to admit, I have a few concerns about this proposal. 1) Priority - Push notifications are already pretty much temporal and priority, right? Essentially, this would offer a two state option of "Deliver this to my app NOW!" or "Deliver this whenever." My concern and complaint would be that the low priority messages probably shouldn't go through the web push channel. Instead, the app could spin up on it's own and check for outstanding messages that it might have, rather than use a complicated mechanism like push to do it. 2) Privacy - I like to think of the Push system as being like a mailman who's a jerk. A priority flag on a message would be delivered in the clear and would tell all the world, "Hey, if you're going to spend any time trying to break into a message, this would be a really good candidate." You could bury the flag inside the encrypted body, of course, but then you'd either have to make the UA far smarter about dealing with the body content of a push notification and that's probably not a great idea either. 3) Management - Doing distribution control on the server doesn't really make a lot of sense. For one, the connection between the server and the UA is always open, so the message should get distributed. This also means that if the UA is queuing these messages, it will have to determine when to toss messages when it runs low on resources, making low priority messages even more lossy. Plus, I'm willing to bet that apps will want to replace or recall low priority messages, meaning that there will eventually be some queue management system the UA will require, and I can see whatever battery savings that low priority messages might bring being eaten by the UA dealing with them. tl;dr: have the app pull low priority messages when it likes. Push is a "high priority" system.
I think both your messages present good arguments for reasoning about this as urgency rather than priority. NAME Having thought about this more, I do agree that probably is not the best term. I certainly subscribe to Brian's mapping of the {0, 1, 2} values to their interpretation in context of Web Push, but those would work with {high, normal, low} urgency as well. NAME Let me reply to each of your points individually. (1) An incoming phone call (real-time messaging) is more urgent than a received e-mail or social media invite, while you'd still like to know about the latter prior to the next use of your e-mail client. We'd like to avoid apps spinning up on their own to effectively poll for information, that could have a very negative impact on battery life. (2) My goal is to avoid waking the UA up if there is no need to, so embedding this in the encrypted payload would not work. Does reasoning about this as urgency rather than priority help in regards to the attack vector? Several kinds of urgent messages tend to be more ephemeral as well. (3) Distribution control on the server allows non-urgent message transmissions to be intelligently grouped together if the user isn't using their device, e.g. when they're asleep. This allows the open connection to remain in a lower activity state (e.g. PCH) for longer, using significantly less energy, while still allowing for the immediate delivery of urgent messages. Furthermore, doing distribution control on your server allows the deletion and replacement of non-urgent messages to be done without informing the UA at all, for example following URL for message collapsing.
I suppose I'm still not really seeing the value of this. As you note, a highly urgent message would require the UA to do work, the app to be woken and all the various things that should be required. It's a significant action. I'm not really sure I'd find it useful to be woken up at 3AM to be told that a server is down, oh, and that four of my old high school friends killed snakes in Farmville. It may be that my server manages Farmville's virtual snake generation and both sets of information are equally useful, but probably not. Messages are still noted as being "special" and therefore there's user meta data potentially being exposed, there's additional management and storage work that the server would need to do( particularly if a large partner were to start using this function) just to keep the app from doing a HTTP request. I feel that we're adding a fair bit of complexity for little real gain. An app can still gather "low priority" messages from it's own server according to that app's specific logic. If there are additional complexities around those low priority messages, we can remain gleefully unaware of them and remain focused on ensuring that a message of import gets through our system as quickly and reliably as we can afford. Of course, there's absolutely nothing preventing a push provider from offering this as a proprietary feature as well. I'd just rather this protocol not be made a magnificent hammer to use on every nail.
Having had a conversation with Ben about this, let me also clarify a few things. 1) An app could start for any reason. User activity, timer, etc. There is nothing preventing or discouraging that app from checking it's server for outstanding messages right now. 2) I understand the appeal of having extra information handed to an app that is being woken by a high priority message may bring. I feel that perhaps it would be better for app developers to understand that sending messages incurs a device cost. Instead of trying to fix the protocol (where only a small population may set a flag indicating "This message isn't urgent"), we instead make sure that app developers simply only send messages via our system that may cause folks to uninstall their app. 3) The idea of "low priority" messages bother me because any messages that are undelivered will bring complexity. If you have a message that reflects state (like 50 unread mail) do we deliver 50 messages? Perhaps it might make sense to consider "collapse" messages as low priority by default, as I believe you're suggesting, and deliver those to the UA only when a high priority "normal" notification is sent. Sorry if I seem overly dense or antagonistic. I'll blame a head cold.
NAME So far this only seems to cover the header sent to the Push Service, I assume there's some corresponding change to how a UA asks a Push Service for notifications such that it can do a one-off poll that indicates if there's any Nice 0 messages? I'm somewhat concerned that Nice 2 messages increase database load for a Push Service, since accepting those notifications requires a database hit to see if they should even be stored. Speaking of collapse keys, how do they go with urgency levels? Are topics unique to the urgency level? It would be weird for a Nice 0 message to replace a Nice 1 message with the same topic. I would expect topics with different urgency to be separate, or undefined improper behavior. Edit: Not worried about the Nice 2 db read, since in cases there's no Nice 0 it'd avoid a db write which is generally more expensive than a read anyways.
NAME Part of the efficiency advantage of a push service is its ability to coalesce multiple messages into a single message to a user agent. That means delaying some messages. Urgency indicators help the push service decide how much delay is acceptable. (And as NAME notes, if the user agent can indicate an urgency on its polling request, that might govern push service behaviour as well. For instance, a mobile device that is on battery power overnight might want the push service to treat "normal" requests as "non-urgent" for that period.) NAME for simplicity, I would expect that the urgency of an updated push message will simply update the urgency of the topic. If it was previously non-urgent and becomes urgent, then it should be delivered urgently. (I can't imagine the opposite happening very often, but there you are).
NAME my main thought was that it could cause some odd results, since if its a Nice 2 topic, and there were no Nice 0 stored, it wouldn't collapse but actually just delete the existing one. Why a topic would go from Nice 1 -> Nice 2, I don't know offhand but I guess someone could dream up a case for that.
The headers should provide enough information to enable the push service to optimize for network and battery usage. "Urgent" is clear - deliver ASAP, no matter what. A push service may look for abuse of "urgent", and I don't think it should be default. If the device is offline: urgent may still be affected by expiration and collapse, but as soon as the device gets connected urgent will be delivered. The main issue is what kind of optimizations we can do for the others - and how to provide the right information in the headers so it's clear for both sender and push service what actions can be taken if a message is not urgent. One problem is how long can the push service delay a non-urgent message, if the device is connected. Expiration is not a good indicator - for "mail messages waiting" you may want a large expiry ( 1 day ) but you want to limit the delay for 15 min. If user is connected, message will be delayed up to 15 min, if not - it'll still be held for 1 day, and collapsed with more recent messages. If a device is 'charging' and on wifi ( desktop browser ) - the push service may choose to just send all messages immediately - there are costs for delaying the messages. The spec shouldn't require that "nice=2" messages will be delayed - the nice should be an indication that some delay is acceptable. It's up to the app to notify or not notify you in the middle of the night that you got some unimportant notification. If the device is on battery - and maybe hasn't been used for some time ( for example screen off, didn't move) - it makes a lot of sense to delay all messages until device is active. Keep in mind that on some devices when this mode is detected, apps may also be restricted on what they can do with incoming messages for battery saving. And the device itself may have some update windows when it can process the messages. IMHO this is the most important use of Nice - saving user's battery and making sure the apps can handle the messages. TTL=0 ( or very short expiration ) is another factor - not clear how it should interact with niceness. The main use is to not save the storage costs, if device is not connected.
The WebPush spec covers how the client asks for notifications. When we talk of how the Push server has urgency values attached to notifications, I assume this means by necessity we will be talking about how the Push server knows all these various things about the client to make these determinations? NAME Do you plan on introducing additional flags for the client when making a notification request that conveys all this additional knowledge (on wifi, 'charging', etc) to the Push service? Is it the right place for the Push service to choose how to optimize delivery, or should the client flag indicate what level of urgency it wants notifications for?
GCM uses a binary protocol for UA-push service, which already has the flags ( it wouldn't work otherwise for the deep sleep for example ). I think common ones could be added to webpush spec, but with lots of care - we don't want the UA to send notifications too often (for example on state change). A start would be to define a header for the 'monitor' request, with a list of flags, and define common ones ( charging, network type ).
Noting earlier httpbis discussion on the use of instead of a custom header
PushSubsctiption has two parameter: endpoint and subscriptionId. ReceiptEndpoint should be added. I leave comment here and not in webpush api until this draft is close to be final regarding this.
This is not actionable in the protocol draft. Please open an issue in the W3C repo if appropriate.
This is just for the request from the application server to the push service. Can we require a TTL value for web-push notifications? The current behavior is not obvious to an implementer and likely to lead them to think they've successfully sent messages when they're actually dropped. If you omit the TTL, then the value is assumed to be 0. This results in the message being dropped, but the 201 status is still returned. An astute implementer will notice in this case that no Location header is present, since no resource was actually created. Regarding the resource creation, the spec does not clearly state whether a Location header should be returned for a TTL of 0 since its intended that the message is only delivered to an online user. If so, it would be useful to mention. In the past 2 days, out of approximately 76k webpush notifications to our service, 23k of them were dropped due to a missing TTL header, but a 201 status was returned. Defaulting a missing TTL header seems ripe for implementer issues (I have a hard time believing this many dropped notifications was intentional). If it was a required header, we could return a 401 which would very quickly alert developers about the problem. Cheers, Ben
Brian, Martin and Elio, Thanks for the offline coordination and for putting this version together. I finally managed to get to review the draft and it looks good for the most part. I made a few comments on the issues in github so I won't repeat them here. A couple topics came to mind and I would like to throw them here for further clarification from the authors: Prioritization As I went through the draft I wasn't able to understand how the push service will handle message prioritization (for the same subscription). Is the expectation that the app server will send them in the right sequence and the push server will use a FIFO (first in first out) queue? The scenario I have in mind is a social network application that can push news alerts and incoming chat notifications. I would expect the chat notification to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push service that will be able to act based on some form of prioritization indicator. Priority is a fairly basic requirement and I hope it can get handled in a header so it can be consistently enforced by the push service. Message deduplication and retries. Section 6.1 talks about acknowledging push messages and that the user agent must acknowledge with an HTTP DELETE if the message was delivered at least once. Should we have a mechanism in place to account for message deduplication? I might be wrong but I can see situations where the three parties (AS, PS, UA) end up in some race conditions and the AS ends up retrying. It would be good to clarify that the push messages for the same application event instance (e.g. call from Bob) MUST have the same identifier so they can be duplicated at the PS so they don't get sent multiple times to the UE. Regards, Dan -----Original Message----- From: Webpush [mailto:EMAIL] On Behalf Of Brian Raymor (MS OPEN TECH) Sent: Wednesday, April 15, 2015 5:43 PM To: EMAIL Subject: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-URL As requested at the last WebPush meeting in Dallas, Martin, Elio, and I have merged our proposals into a straw-man for review. During that process, we've captured issues at: URL but will now migrate those discussions to the WebPush mailing list in the next few days. ...Brian -----Original Message----- A new version of I-D, draft-thomson-webpush-protocol-URL has been successfully submitted by Brian Raymor and posted to the IETF repository. Name: draft-thomson-webpush-protocol Revision: 00 Title: Generic Event Delivery Using HTTP Push Document date: 2015-04-15 Group: Individual Submission Pages: 21 URL: URL Status: URL Htmlized: URL Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at URL The IETF Secretariat Webpush mailing list EMAIL URL
Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work.
Hi all, At the Dallas meeting, I had volunteered to review the draft and provide some feedback and comments. I’m a little behind on that but here’s the first installment I tried to capture the example end to end webpush flow (just to make sure I understand it correctly) in the following diagram: URL There were a couple of places where I didn’t quite get the intent of the spec (they are marked in red in the diagram above and referenced below) Section 4 – The first sentence in the last paragraph “A push service SHOULD provide the same receipt subscribe URI to user agents”. I’m trying to understand what this means. If we are referring to the "URL" URI in the example in Section 4, how exactly does the push service provide this URI to the user-agent. Is the intent to say that it should provide the same URI to a given application server? (I’ve marked this with the red arrow in the diagram) Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 Section 5.1 - Would be useful to give an example of where/when the Push-Receipt header is sent and what the value looks like. I'm guessing the example value should be "URL" but it would help to just explicitly show it. Also, as I understand it, if the application server does not want a push message receipt, it would not do anything that is specified in Section 4 and so will also not send the Push-Receipt header. Is that correct? If so, does the Push Server still need to send back a 201 Created (with the Location header populated) or should it send back a 200 OK instead. To take an example of a push message for a call notification, the AS is expecting the notification to be delivered immediately and its going to get an inherent acknowledgement by the mere fact that the actual app was woken up to receive the call. If stuff in Section 4 and Section 6.2 does not happen, can the interaction between the UA and the PS be simplified (the PS can itself delete the push message resource) Section 6 - Sentence in second last paragraph – "In response to this request, the push service SHOULD return link references to the push and receipt subscribe resources, plus expiration information" Are these the original URL's generated by the PS (i.e. /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV and /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ) or are these the corresponding uri's generated in response to the application server's messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN and /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct? Push message prioritization - Would it make sense to use the Prefer header instead of the TTL header. This would allow carrying prioritization info for messages (the prioritization is only relative to the application server's own set of messages) to be carried in the Prefer header (e.g. Prefer: priority=5, wait=10). Also the wait 0 can be used to indicate the equivalent of TTL 0 or we can even define a new preference token. Darshak
[...] The draft really doesn't say, partly because we didn't discuss it much, partly because I think that we'd want some flexibility. I've opened an issue on this in our issue tracker so that we don't forget this. Prioritization is a concern if there are multiple messages to deliver at the same time. This happens most often when a device comes back from a short nap (as mobile devices do all the time). With a small number of messages, this might not be a big deal, but if there is a backlog to clear, it could be. I have a draft on signaling priorities that could be used in this context: URL Do you think that we need to address this in a basic protocol specification, or can it rely on other specifications. Yes, reliability is hard. The intent is to have the application mark messages and perform deduplication if it does resending, especially within the TTL period that the push service promises. In terms of the protocol, there is a proposal for message replacement that might reduce the need for some of this, but Brian, Elio and I decided that we'd let this draft stabilize before talking about that feature: URL

call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert.  <ins> An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery.  The TTL header field contains a value in seconds that suggests how long a push message is retained by the push service. A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field. A push service MAY retain a push message for a shorter duration than requested.  It indicates this by returning a TTL header field in its response with the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. Once the TTL period elapses, the push service MUST NOT attempt to deliver the push message to the user agent.  A push service might adjust the TTL value to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays. </ins> A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or application server needs to account for transit delays in selecting a TTL header field value.  <ins> A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message.  After delivery, the push service is permitted to immediately remove a push message with a zero TTL.  This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource. Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. </ins> If the user agent is unavailable, a push message with a zero TTL expires and is never delivered.  6.3. A push message that has been stored by the push service can be For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64 alphabet RFC4648.  A push service that receives a request with a  <ins> Topic header field that does not meet these constraints MUST return a 400 (Bad Request) status code to the application server. </ins> A push message update request creates a new push message resource and simultaneously deletes any existing message resource that has a


6.3.  A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids send the contents of push messages as they are sent by application servers.  Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers.  Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the

Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.

6.3. <ins> For a device that is battery-powered, it is often critical that it remains dormant for extended periods.  Radio communication in particular consumes significant power and limits the length of time that the device can operate. To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forward messages of a specific urgency. An application server MAY include an Urgency header field in its request for push message delivery.  This header field indicates the message urgency.  The push service MUST not forward the Urgency header field to the user agent.  A user agent MAY include the Urgency header field when requesting push messages to indicate that it only wants to receive messages at an equal or greater urgency. An absent Urgency header field indicates that the request is to be forwarded at "normal" urgency.  Multiple values for the header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code. 6.4. </ins> A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the


A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (monitor- <del> set) this can be signaled by returning a 400-series status code, such as 410 (Gone). </del>  A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also

As suggested by NAME
Thanks to all for the discussion, I was lazy and missed the MUST 404 on the section above.
The language for subscription and subscription sets is still a bit asymmetical. I'll merge this PR and make the subsequent edits. For example can remove versus MAY expire ...

A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (monitor-  <ins> set) this can be signaled by returning a 404 (Not Found) status code. </ins> A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also


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 <del> that are made by the same application server to a single entity.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </del>  1. to a push service allows the push service to better distinguish between legitimate and bogus requests.  This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though cookies, though the push service would not be able to offload any state as a result.  3. This document has no IANA actions (yet).

I welcome any level of feedback. One specific question is how to specify the association token when creating a new subscription. I used my beloved header, but the token may be something other than a DH public value. Do you know of appropriate headers that could be used for this purpose?
I think that this is pretty good. I would want to tighten this a little more, but until we decide on an approach, we're somewhat constrained in what we can say.
My understanding is that this is just a proposal, the formal draft (either separately or merged with the main draft) would not mention the alternative options either, right?
Yeah, this is just input for discussion. If we decide on an approach, it's probably something we can merge into one of the other drafts. Or, it could remain separate and we could either remove the alternatives or move them to an appendix.

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  <ins> that are made by the same application server to a single entity, and reduce the need for endpoint secrecy by being able to associate subscriptions with an application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </ins> 1. to a push service allows the push service to better distinguish between legitimate and bogus requests. <ins> Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads.  In situations where usage of a subscription can be limited to a single application server, the ability to associate said subscription with the application server provides could reduce the impact of a data leak. </ins> This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though cookies, though the push service would not be able to offload any state as a result. <ins> 2.2. The public key or otherwise public token offered by the application service to the push service may also be used to associate a subscription with the application server that can prove possession of the private counterpart. Subscription association reduces the reliance on endpoint secrecy by requiring this proof to be presented when requesting delivery of a push message.  This can provide an additional level of security in a situation where the application server may suffer a data leak. 2.2.1. The user agent may include the public token of the application server to associate the subscription with when creating a subscription, when developer has made the association token available.  For example, the Web Push API API could enable the public token of the application server to associate the subscription with in the "association" field of the PushSubscriptionOptions dictionary. The URL-safe base-64 encoded RFC4648 representation of the token may be included by the user agent by including a Crypto-Key header in the request to create a new subscription. As an extension, accepting multiple keys to be specified in the Crypto-Key header when creating a subscription would allow a subscription to be associated with multiple application servers. This would require more state to be maintained by the push service for each subscription. 2.2.2. When a subscription has been associated with an application server, the request for push message delivery must include proof of possession of the private counterpart of the token that was used when creating the subscription. If the application server cannot satisfy this requirement, the application server must reject the delivery and generate a 401 (Unauthorized) status code. </ins> 3. This document has no IANA actions (yet).


As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior <del> to requesting delivery of a push message.  By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication.  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. </del>  An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While

This closes but does not completely address ?
You mean that I missed yes, I missed that on my first check. Let me know if you find anything else. (I haven't used the header field in the example to concentrate on the important bits.)
Introduction By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication. In webpush-05, there is no longer an explicit request to create such a subscription. It's created implicitly as the result of requesting a push message delivery with receipts. Example In webpush-05, this changes to: and a reference to RFC7240 added.

As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior  <ins> 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. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While


2. <del> Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes a continuous identity for the application server. </del>  When requesting delivery of a push message, the application includes a JSON Web Token (JWT) RFC7519, signed using its signing key.  The

1 Application Server Self-Identification Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve [FIPS186]. What is the rationale for SHOULD rather than MUST?

2.  <ins> Application servers that wish to self-identity generate and maintain a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the application server that is consistent across multiple messages. </ins> When requesting delivery of a push message, the application includes a JSON Web Token (JWT) RFC7519, signed using its signing key.  The


JWT with the header and body shown in ex-jwt.  This JWT would be valid until 2016-01-21T01:53:25Z RFC3339. <del> The first part of the JWT is effectively fixed.  Would be it acceptable to require that that segment is omitted from the header field? </del> 3. A new "WebPush" HTTP authentication scheme RFC7235 is defined.  This

What is "that segment"?
Optimizations, like dropping the header segment, tend to be problematic for some implementers, particularly since the final signature is derived from the first two segments. Also, dropping the header segment prevents possible future changes for encryption types, versioning, or other potentially required items.
Agreed. I was requesting clarification because it was unclear what omission was being proposed. For example, if it was the header, then that would be a problem because states that the alg parameter MUST be present and MUST be understood and processed by implementations.
I'll confirm with the list, but NAME is right here. We can pay a little extra here. It will mean that there is some possibility of variation in the header (whitespace), but we know how to do that.

JWT with the header and body shown in ex-jwt.  This JWT would be valid until 2016-01-21T01:53:25Z RFC3339.  3. A new "WebPush" HTTP authentication scheme RFC7235 is defined.  This


When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of <del> possession for the associated private key or token that was used when creating the push subscription. </del>  A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a the public key used to sign the JWT doesn't match the one that was included in the creation of the push message. <del> A push subscription that is not restricted to a particular key MAY still validate a token that is present, except for the last check.  A push service MAY then reject a request if the token is found to be invalid. </del> In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to

This was either in error, or could refer to "JWT" instead.
There are multiple references to a token that are unclear: ...
The first is just a mistake; a relic of a previous version. It can be removed. The second refers to JWT. I'll fix that.

When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of  <ins> possession for the associated private key that was used when creating the push subscription. </ins> A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a the public key used to sign the JWT doesn't match the one that was included in the creation of the push message.  In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to


2.2.  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

LGTM, thank you! Is the addition required because of the following language in 7519?
Well, that's a good reason, but is the main reason. See the discussion leading up to that.
I read the thread and issue; reading JWT, there was nothing prohibiting providing additional fields (aside from that SHOULD), so I was wondering if specifying this is a normative requirement or a good clarification :-).
If I may, clarification is always good. One should presume that the readers of these specs may not be fully versed in the subtle details of other, reliant specs, so a bit of useful info like this might be very welcome.
As noted in the arguments of , there is a need for an "extra data" field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators.
Started thread: URL JR requests that we allow the inclusion of extra stuff in a vapid token: URL field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators. <<< I think that the general idea is fine. Better this than trying to pack the "sub" field with extra stuff. JR, would it suffice to point out that the (or even ) claims can be added to the token? Allowing multiple fields gives the application server a fair bit more flexibility. If that's OK, we should point out that this is possible so that push services don't lose the extra data because they aren't aware that it might exist.

2.2. <ins> An application server MAY include additional claims using public or private names (see Sections 4.2 and 4.3 of RFC7519).  Since the JWT is in a header field, the size of additional claims SHOULD be kept as small as possible. 2.3. </ins> 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


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 <del> that are made by the same application server to a single entity.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </del>  1. to a push service allows the push service to better distinguish between legitimate and bogus requests.  This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though 3. <del> This document has no IANA actions (yet). </del>  4.  TLS 1.2 RFC5246 does not provide any confidentiality protections for client certificates.  A network attacker can therefore see the identification information that is provided by the application

NAME can you check that this is all OK with you? I've made you an author :)
SG, thanks. The only difference with my PR seems to be removal of details, which I guess are too specific for the proposal phase.

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  <ins> that are made by the same application server to a single entity, and reduce the need for endpoint secrecy by being able to associate subscriptions with an application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </ins> 1. to a push service allows the push service to better distinguish between legitimate and bogus requests. <ins> Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads.  In situations where usage of a subscription can be limited to a single application server, the ability to associate said subscription with the application server provides could reduce the impact of a data leak. </ins> This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though 3.  <ins> A stable identifier for an application server - such as a public key or a token - could also be used to associate a subscription with the application server. Subscription association reduces the reliance on endpoint secrecy by requiring proof of possession to be demonstrated by an application server when requesting delivery of a push message.  This provides an additional level of protection against leaking of the details of the push subscription. 3.1. The user agent includes the public key or token of the application server when requesting the creation of a subscription.  For example, the Web Push API API could allow an application to provide a public key as part of a new field on the "PushSubscriptionOptions" dictionary. This token might then be added to the request to create a push subscription. Allowing the inclusion of multiple keys when creating a subscription would allow a subscription to be associated with multiple application servers or application server instances.  This would require more state to be maintained by the push service for each subscription. 3.2. When a subscription has been associated with an application server, the request for push message delivery MUST include proof of possession for the associated private key or token that was used when creating the subscription.  Requests that do not contain proof of possession are rejected with a 401 (Unauthorized) status code. </ins> 4. <ins> This document has no IANA actions (yet). 5. </ins> TLS 1.2 RFC5246 does not provide any confidentiality protections for client certificates.  A network attacker can therefore see the identification information that is provided by the application


this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the webpush protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del>  4.

attn: NAME
Thanks !
From NAME authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key" already needs to have code to handle EC for the e2e encryption. The main concern is an attacker 'acking' or unsubscribing - since the messages are e2e encrypted they can't read it.
This looks good to me.

this authentication scheme. This authentication scheme is intended for use by an application  <ins> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </ins> 4.


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>

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 :)

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:


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. <del> This can used to reduce the secrecy for push subscription URLs by </del>  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 1. <del> 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. </del>  As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior 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 <del> the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </del>  An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While the special meaning described in RFC2119. The terms "push message", "push service", "push subscription", <del> "application server", and "user agent" are used as defined in I- D.ietf-webpush-protocol. </del>  2. that share the same origin. An "exp" (Expiry) claim MUST be included with the time after which <del> 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. </del>  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 2.3. An application server requests the delivery of a push message as <del> 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). </del>  Note that the example header fields in this document include extra line wrapping to meet formatting constraints. this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del>  3.1. is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex- <del> push.  Extra whitespace is added to to meet formatting constraints. </del>  An application might use the Web Push API API to provide the user agent with a public key. 6.1. <del> 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. </del>  Registrations MUST include the following information:

These are some suggested fixes for some nits that came up from the Shepherd write-up review.

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.  <ins> This can be used to reduce the secrecy for push subscription URLs by </ins> 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 1.  <ins> 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. </ins> As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior 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  <ins> the protocol provides.  For these reasons, RFC8030 does not define a mandatory system for authentication of application servers. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While the special meaning described in RFC2119. The terms "push message", "push service", "push subscription",  <ins> "application server", and "user agent" are used as defined in RFC8030. </ins> 2. that share the same origin. An "exp" (Expiry) claim MUST be included with the time after which  <ins> 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. </ins> 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 2.3. An application server requests the delivery of a push message as  <ins> 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). </ins> Note that the example header fields in this document include extra line wrapping to meet formatting constraints. this authentication scheme. This authentication scheme is intended for use by an application  <ins> server when using the Web Push protocol RFC8030, but it could be used in other contexts if applicable. </ins> 3.1. is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex-  <ins> push.  Extra whitespace is added to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key. 6.1.  <ins> 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. </ins> Registrations MUST include the following information: