Distribute the subscription secrets safely
01A user agent, such as a browser, receives messages through a push service. Its application shares subscription material only with an authorized application server.
In this separate unsafe case, the proposed channel is not authenticated and confidentiality-protected. The application must not send its subscription secret on that path; the stop occurs before distribution.
Source for this drawing: RFC 8291 · Read RFC section 2.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Encryption needs protected key distribution before message delivery.
- The user agent creates a P-256 Elliptic Curve Diffie-Hellman (ECDH) key pair and an authentication secret for each new subscription. A public key can be shared; the private key stays local.
- The authentication secret MUST be a hard-to-guess 16-octet sequence. It SHOULD come from a cryptographically strong random number generator. An octet is one byte.
- The subscription public key and authentication secret go to an authorized application server over an authenticated, confidentiality-protected medium. That protection is a MUST; HTTPS is a sufficient example, not the only possible medium.
- The push service relays messages. It is not given the user agent private key or the authentication secret in this scheme. Protecting each HTTP hop alone would not hide message content from that intermediary.
RFC 8030 defines the wider subscription/delivery protocol. This chapter covers RFC 8291’s key-distribution boundary. The displayed fixed values are public RFC test data, not keys to reuse for real messages. These illustrations do not send notifications or implement a production encryptor.
Read the RFC section ↗