[w3c/push-api] Declarative Web Push: `pushSubscriptionChange` requires Service Worker (Issue #401)

Dygear created an issue (w3c/push-api#401)

The promise of Declarative Web Push is that it doesn't require a service worker in order to function. There is however one area that is not covered and that is the [`pushSubscriptionChange`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/pushsubscriptionchange_event) event that is handed to the service worker when a user-agent changes its endpoint, p256dh, and auth values. This is often handled like so ...

```js
self.addEventListener('pushsubscriptionchange', function(event) {
  event.waitUntil(
    fetch('https://update.url/path', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        old_endpoint: event.oldSubscription ? event.oldSubscription.endpoint : null,
        new_endpoint: event.newSubscription ? event.newSubscription.endpoint : null,
        new_p256dh: event.newSubscription ? event.newSubscription.toJSON().keys.p256dh : null,
        new_auth: event.newSubscription ? event.newSubscription.toJSON().keys.auth : null
      })
    })
  );
});
```

The updated information needs to get to the server that is responsible for generating the WebPush payloads. They need to have current, correct information in order for the payloads to get to their intended target. When a user-agent decides that it wishes to update its endpoint, p256dh, and auth values the `pushSubscriptionChange` event is fired with the old and new values. Not having this information produces a dangling reference in the servers database until finally it attempts to send a Push to the user-agent's endpoint and receives a `410 Gone` reply.

That is a gap in the current Declarative Web Push implementation.

I come to you not just with the problem, but perhaps a potential solution. Given that the goal is to not have a service worker, we could use the [`/.well-known/`](https://datatracker.ietf.org/doc/html/rfc8615) directory structure to inform the server of a `pushSubscriptionChange`. I propose that the user-agent would send its subscription changes to `/.well-known/pushsubscriptionchange` URL of the domain that the push notification is subscribed from. That payload would be a POST request with the payload of Content-Type `application/json` having the payload like the current `pushSubscriptionChange` payload.

```json
{
  "oldSubscription": {
    "endpoint": "CURRENT_URL"
  },
  "newSubscription": {
    "endpoint": "NEW_URL",
    "keys": {
      "p256dh": "NEW_P256DH",
      "auth": "NEW_AUTH"
    }
  }
}
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/401
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/issues/401@github.com>