Original text:
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).

Reviewer comments:
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.

Revised text:
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).