Draft: draft-ietf-webpush-vapid

Commentary: Found some minor stuff in the draft , and had two questions ( below ) . If I should send those to the list instead , let me know :) Does an application server have to have a unique keypair ? E.g lets say I have multiple application servers sitting behind a load balancer , could I just share the keys used for vapid between them ? In 5.2 : Why is a MAY ? If I , as a UA , create a restricted subscription my assumption would be that that is actually checked , right ? If the Push Service is not planning to check it anyway , would n't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time ? 
 The concept of an application server does not define the quantity — it 's fine for multiple servers to share a single key .  text allowing additional claims ( ) which further clarifies that it 's fine to include more specific information , for example which server created the message , which is useful if the push service has means for dealing with this . ( E.g. QoS or analytics . ) I do n't recall why that 's a MAY . We certainly should n't forward unauthorized messages for restricted subscriptions to the user . /cc The changes themselves look good , thanks ! :) 
 Thanks for the explanation Should I open an issue regarding the ?
Paragraph (version A):
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.
Paragraph (version B):
Application servers that wish to self-identify 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.
Paragraph (version A):
If the application server wishes to provide contact details it MAY
include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD
include a contact URI for the application server as either a
"mailto:" (email) RFC6068 or an "https:" RFC2818 URI.
Paragraph (version B):
If the application server wishes to provide contact details it MAY
include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD
include a contact URI for the application server as either a
"mailto:" (email) RFC6068 or an "https:" RFC2818 URI.
Paragraph (version A):
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
with credentials that use the "WebPush" authentication scheme auth
and a Crypto-Key header field that includes its public key key.
Paragraph (version B):
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
with credentials that use the "WebPush" authentication scheme (auth)
and a Crypto-Key header field that includes its public key (key).