Asymmetric Encryption vs Shared secret via ECDH I'm reading RFC8291. Here's a figure on how Web Push Notifications work in general:
    +-------+           +--------------+       +-------------+
    |  UA   |           | Push Service |       | Application |
    +-------+           +--------------+       +-------------+
        |                      |                      |
        |        Setup         |                      |
        |&lt;====================&gt;|                      |
        |           Provide Subscription              |
        |--------------------------------------------&gt;|
        |                      |                      |
        :                      :                      :
        |                      |     Push Message     |
        |    Push Message      |&lt;---------------------|
        |&lt;---------------------|                      |
        |                      |                      |

                                 Figure 1

Then, RFC8291 adds cryptography on top of it. If I understood correctly:

In the &quot;Provide Subscription&quot; step, the User Agent (UA) and the Application both agree on a shared secret using ECDH.
Then, when the Application wants to send a push notification to the UA, it encrypts symmetrically (via AES) the notification content using the shared secret.
The Push Service relays this encrypted notification to the UA.
The UA decrypts the notification content using the shared secret.

My question is: why use ECDH when simple asymmetric encryption/decryption can be used?

UA generates a private/public key pair.
In the &quot;Provide Subscription&quot; step, the UA sends its public key to the Application.
The Application, when it wants to send a push notification, encrypts the notification content with UA's public key.
Same as before, the Push Service, relays the encrypted message.
The UA decrypts the encrypted notification content with its private key.

What are the trade-offs between the method I described here, and the one in the RFC?
Your alternate method has an expensive public key operation for each push message.
While the first protocol does a key exchange just once per subscription and then continues with a symmetric key.
If in the key exchange both sides authenticated themselves (Or at least the Application) the user can rely on this, if authenticated encryption is used it still a fast symmetric key operation to decrypt and authenticate the message.