Change:
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.

Discussion:
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> <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. <del> This document has no IANA actions (yet). </del> <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