Skip to main content

2. Overview

2. Overview​

A general model for push services includes three basic actors: a user agent, a push service, and an application (server).

 +-------+           +--------------+       +-------------+
 |  UA   |           | Push Service |       | Application |
 +-------+           +--------------+       |   Server    |
     |                      |               +-------------+
     |      Subscribe       |                      |
     |--------------------->|                      |
     |       Monitor        |                      |
     |<====================>|                      |
     |                      |                      |
     |          Distribute Push Resource           |
     |-------------------------------------------->|
     |                      |                      |
     :                      :                      :
     |                      |     Push Message     |
     |    Push Message      |<---------------------|
     |<---------------------|                      |
     |                      |                      |

Figure 1: WebPush Architecture

At the very beginning of the process, a new message subscription is created by the user agent and then distributed to its application server. This subscription is the basis of all future interactions between the actors. A subscription is used by the application server to send messages to the push service for delivery to the user agent. The user agent uses the subscription to monitor the push service for any incoming message.

To offer more control for authorization, a message subscription is modeled as two resources with different capabilities:

  • A subscription resource is used to receive messages from a subscription and to delete a subscription. It is private to the user agent.

  • A push resource is used to send messages to a subscription. It is public and shared by the user agent with its application server.

It is expected that a unique subscription will be distributed to each application; however, there are no inherent cardinality constraints in the protocol. Multiple subscriptions might be created for the same application, or multiple applications could use the same subscription. Note, however, that sharing subscriptions has security and privacy implications.

Subscriptions have a limited lifetime. They can also be terminated by either the push service or the user agent at any time. User agents and application servers must be prepared to manage changes in the subscription state.

2.1. HTTP Resources​

This protocol uses HTTP resources [RFC7230] and link relations [RFC5988]. The following resources are defined:

push service: This resource is used to create push message subscriptions (Section 4). A URL for the push service is configured into user agents.

push message subscription: This resource provides read and delete access for a message subscription. A user agent receives push messages (Section 6) using a push message subscription. Every push message subscription has exactly one push resource associated with it.

push message subscription set: This resource provides read and delete access for a collection of push message subscriptions. A user agent receives push messages (Section 6.1) for all the push message subscriptions in the set. A link relation of type urn:ietf:params:push:set identifies a push message subscription set.

push: An application server requests the delivery (Section 5) of a push message using a push resource. A link relation of type urn:ietf:params:push identifies a push resource.

push message: The push service creates a push message resource to identify push messages that have been accepted for delivery (Section 5). The push message resource is also deleted by the user agent to acknowledge receipt (Section 6.2) of a push message.

receipt subscription: An application server receives delivery confirmations (Section 5.1) for push messages using a receipt subscription. A link relation of type urn:ietf:params:push:receipt identifies a receipt subscription.

Last updated on