Re: [w3c/push-api] Some questions about VAPID and encrypted messages (#278)

Hi @floatingstone, thank you for the questions! Please do note that there is a repository for VAPID (https://github.com/webpush-wg/webpush-vapid) as well, but it's relevant enough so I'll answer your questions in this issue.

> 1. Should all of the subscribe requests's applicationServerKey be stored in the push service database?

The _application server_ definitely has to remember which key was used, if it has several, as it will need to proof possession of the associated private key by signing the JWT token.

The _push service_ needs to store this key if it decides to support Subscription Restrictions (see [section 4](https://webpush-wg.github.io/webpush-vapid/draft-ietf-webpush-vapid.html#rfc.section.4)). Otherwise the `k` parameter in the `Authorization` header will do.

Note that, to my knowledge, all public push services that support VAPID also support Subscription Restrictions.

> 2. VAPID replay attacks.

Indeed: this is detailed in [section 5](https://webpush-wg.github.io/webpush-vapid/draft-ietf-webpush-vapid.html#rfc.section.5). Using near-immediate, say a couple of seconds if your server accurately keeps time, expiration times is the best way to counter this.

> 3. When application server wants to push encrypted messages:
> a) Does the push service need to check whether the request body has been replaced or not?
> b) Or just pass the encrypted messages to target subscriber?

The push service doesn't have the ability to decrypt the message, so the intention is for it to pass on the entire payload, unmodified, to the client.

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