Voluntary Application Server Identification (VAPID) for Web Push
Extracted elements (28)
RFC 8030 deliberately omits mandatory application server authentication to avoid constraining user agent/application server interactions and to preserve privacy properties; VAPID is a voluntary, opt-in supplement that addresses denial-of-service risks and subscription leakage without mandating identity.
VAPID uses a separate HTTP authentication scheme ('vapid') to identify this specific JWT profile, so that cryptographic agility (algorithm updates) can reuse existing HTTP authentication negotiation mechanisms rather than inventing new parameter negotiation.
X9.62 encoding is used over JWK for the public key parameter because JWK lacks a canonical form (making key comparison harder) and X9.62 is considerably smaller, reducing header size.
An application server that needs to replace its signing key must request creation of a new subscription from the user agent restricted to the updated key; there is no in-place key rotation mechanism for existing subscriptions.
A push service MAY reject a request with a 403 (Forbidden) status code if the JWT signature or its claims are invalid. A push service MUST NOT use information from an invalid token.
A push service MUST ignore the body of a subscription creation request that uses a media type other than 'application/webpush-options+json', and MUST ignore any unrecognized members in that JSON object.
A push service MUST NOT forward the JWT or public key to the user agent when delivering the push message.
A push service MUST reject a message sent to a restricted subscription if it includes no 'vapid' authentication or invalid 'vapid' authentication (401 if absent, 403 if invalid).
All unknown or unsupported parameters to 'vapid' authentication credentials MUST be ignored. The 'realm' parameter is ignored for this authentication scheme.
An application server MUST select a different private key for key exchange (RFC 8291) and for signing the authentication token; a push service SHOULD reject push messages where these keys are identical with a 400 (Bad Request).
An 'exp' (Expiry) claim MUST be included in the JWT, and MUST NOT be more than 24 hours from the time of the request, limiting the window of token reuse.
The application server signing key pair MUST be usable with ECDSA over the P-256 curve. This key establishes a consistent identity for the application server across multiple push messages.
The JWT 'aud' (Audience) claim MUST include the Unicode serialization of the origin of the push resource URL, binding the token to a specific push service.
The JWT MUST use JSON Web Signature (JWS) and the signature MUST use ECDSA on the NIST P-256 curve, identified as 'ES256'.
The 'sub' claim SHOULD include a contact URI as either a 'mailto:' or 'https:' URI if the application server wishes to provide contact details.
The 'vapid' authentication scheme MUST NOT be used with the Proxy-Authenticate or Proxy-Authorization header fields; it is for origin-server authentication only.
When a push message subscription has been restricted to an application server, the delivery request MUST include a JWT signed by the corresponding private key.
The JWT used in VAPID contains at minimum an 'aud' claim (push service origin), an 'exp' claim (expiry ≤24 hours), and optionally a 'sub' claim (contact URI) and additional public/private claims.
The 'vapid' HTTP authentication scheme carries a signed JWT in the 't' parameter and the corresponding ECDSA public key in the 'k' parameter, both in the Authorization header field.
This document creates the 'VAPID Authentication Scheme Parameters' registry (under 'Web Push Parameters'), operating under Specification Required policy, with initial entries for the 't' (JWT token) and 'k' (signing key) parameters.
This document registers the 'application/webpush-options+json' media type in the IANA Media Types registry for use with the Web Push protocol subscription restriction mechanism.
This document registers the 'vapid' authentication scheme in the IETF 'Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry' established by RFC 7235.
Changing a signing key breaks linkability between push messages; gradual migration to a new key reduces the risk that requests with the new key are misclassified as abusive by push services that track consistent identity.
Contact information in the 'sub' claim is unvalidated; a push service operator MUST NOT use unvalidated contact information as input to security-critical decisions.
JWT signature validation is computationally expensive, which is problematic for denial-of-service mitigation. Application servers are encouraged to reuse tokens so that push services can cache validation results.
The 'vapid' authentication scheme is vulnerable to replay attacks if an attacker acquires a valid JWT. HTTPS (required by RFC 8030) provides confidentiality, and limiting token validity to 24 hours reduces the value of a stolen token.
For subscription restriction, a JSON body of media type 'application/webpush-options+json' is sent with the subscription creation request; it contains a 'vapid' member holding the base64url-encoded uncompressed P-256 public key.
The 'k' parameter carries an ECDSA P-256 public key in uncompressed form per X9.62 encoding, then base64url-encoded per RFC 7515. This is the application server's signing public key.