“Who sent this?” and “What does it say?” are different security questions in Web Push. VAPID identifies an application server to a push service. RFC 8291 protects the payload so the intended user agent can decrypt it. Browser permission to show notifications is a separate condition.

Concept diagram separating VAPID sender identification from RFC 8291 payload encryption

VAPID identifies the requesting application server

A web application server submits a message to a push service using subscription data. Under RFC 8292, VAPID lets the server include a signed token and public key associated with its application-server key. A push service can attribute requests to that key and, for a restricted subscription, require a token signed by its matching private key.

This is not the same as authenticating the name a person sees beside a notification. The signature links a request to an application-server key; it does not certify the message’s truth or the operator’s legal identity. An optional contact claim can help a push-service operator reach the application operator, but it remains information supplied by that operator. Losing or rotating the key can affect subscriptions, so key storage and rotation belong in the operational design.

RFC 8291 protects the body separately

Identifying a sender does not encrypt a payload. Web Push encryption uses key material associated with a subscription and fresh material created by the application server for a message. RFC 8291 describes P-256 Elliptic Curve Diffie–Hellman (ECDH) key agreement and key derivation for the content-encryption key and nonce.

The aim is to prevent a push service from inspecting, modifying, or forging a properly protected message body. It does not hide every fact needed to route and handle a request: the service still processes delivery information and timing. Encryption also cannot make a browser display an alert. Keep the boundary between content confidentiality and routing metadata explicit.

A subscription and display permission are different states

After a user grants notification permission and the site creates a Push API subscription, the browser returns data associated with a push service. It includes an endpoint and key material used when the application server sends a message. The server stores the subscription and prepares the request; a service worker handles the push event and may display a notification.

A subscription is a delivery target; permission is browser-managed user consent. If permission is denied or the subscription is revoked, valid server authentication and encryption do not restore the missing state. Endpoints and subscription keys should be access-controlled, kept out of ordinary logs, and removed when a subscription is no longer usable.

The protocol does not promise delivery

Web Push lets an application server submit messages for delivery. It cannot guarantee when an offline device will receive one, whether a browser will run in the background, or whether an operating system will show an alert. Network conditions, expiration settings, browser policy, user preferences, and power management all affect the outcome. A successful submission response is not evidence that a person saw or read the notification.

For sensitive content, consider that a notification may appear on a lock screen or shared device. A minimal message that directs the user to an authenticated page can reduce exposure. That is an operational privacy choice, not a display rule mandated by the two RFCs.

Review the design at each boundary

A review can ask three separate questions. Which server key does VAPID identify, and which subscriptions accept it? Is the payload encrypted using the Web Push procedure, and what routing information remains visible to the push service? How does the product handle permission changes, subscription renewal or removal, service-worker failures, and display behavior?

Test those paths independently. An authentication error points toward the VAPID token, key, or subscription restriction; a decryption failure points toward subscription key material and ciphertext; an alert that does not appear calls for checking permission, service-worker behavior, and browser or operating-system policy. One successful request cannot establish universal background delivery across browsers and devices.

From an expert perspective, web.dev’s implementation walkthrough distinguishes browser subscription keys from application-server keys. A review should follow where each key is created, stored, and rotated instead of treating “the Web Push key” as one credential.

Sources