Draft: draft-ietf-webpush-vapid

Commentary: 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 .
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
If the application server cannot satisfy this requirement, the
application server must reject the delivery and generate a 401
(Unauthorized) status code.