[Jmap] Re: Working group last call draft-ietf-jmap-webpush-vapid

[Phillip Tao <[e-mail]>]

The only other thing I wonder about is that RFC 8292 Section 4.2 seems to say that the application server should proactively notify the user agent when rotating keys, "requesting the creation of a new subscription". That seems like a good idea? Rather than waiting for the client to suddenly and unknowingly stop receiving pushes until the next time it happens to issue some API request.

It seems like the JMAP server could push one last message with the old key that's like, "hey the VAPID key changed, please refetch the session and create a new push subscription", right before destroying that push subscription.

- Phillip

> On Jul 25, 2024, at 7:17 PM, Neil Jenkins <neilj=[e-mail]> wrote:
> 
> I think Phillip is right — we don't actually need anything else in the API for key rotation, although we should write a section on how to handle it in the document.
> 
> Basically, if the JMAP server updates its application server key:
> It will update the value in the capabilities, which will cause the sessionState to change.
> The client will see this has changed on its next API request, and refetch the session object. It should then see the applicationServerKey has changed and re-register any push subscriptions for that device.
> The server should also either:
> immediately delete all existing push subscriptions when it rotates the key; or
> store the key id that was active at the time when a subscription is created, and continue to use the old key for pushes for a period of time after rotation, to allow the client time to detect the change and manually replace the push subscription. This would result in a more seamless change so the user doesn't miss pushes.
> There is of course a small window where the client could have the old applicationServerKey and create a PushSubscription with it, while the server has already rotated and tries to use the new key. This will get a 403 from the push server though, which means the client will never receive the verification code <https://www.rfc-editor.org/rfc/rfc8620.html#section-7.2.2> for that subscription. The 403 should cause the JMAP server to just destroy the push subscription immediately. Meanwhile the client should detect in the response to /set that the session has changed, leading it to re-register the subscription as per (2) above.
> 
> Cheers,
> Neil.