search

bitfireAT / webdav-push

WebDAV Push: Draft
43 stars 0 forks source link

Support for VAPID Subscription Restriction #31

Open mar-v-in opened 4 weeks ago

mar-v-in commented 4 weeks ago

The current spec says "VAPID (RFC 8292) is recommended". A part of RFC 8292, section 4, describes how to do restricted subscriptions.

VAPID makes most sense when used with subscription restriction. When doing so, the public key of the application server (that's the WebDAV server in this case) is registered when requesting the push endpoint from the push server. The exact protocol for this is implementation specific, however it is defined how to tell the browser the vapid public key. Some browsers and push systems require the use of vapid subscription restriction.

As far as I can see, the current proposal is not compatible with VAPID Subscription Restriction. To do this, the client needs to know the server's public key before registering with the push service. The current flow registers with the push service before interacting with the WebDAV server. If I'm wrong (which could well be) it would be great if there was an example on how to do this.

rfc2822 commented 4 weeks ago

There were no deeper thoughts on how to use or integrate VAPID yet.

As I understand your posting, it should be possible to

  1. query the server's public key when doing WebDAV-Push Service detection (public key would be in <transports><web-push>public key here</web-push>),
  2. then connect to the push service with that key,
  3. then register the subscription at the WebDAV-Push server?

Or would you have other suggestions? Or do you think it's impossible by design?

As far as I can see, the current proposal is not compatible with VAPID Subscription Restriction.

Yes, it's work in progress. VAPID is not integrated yet. Suggestions welcome :) I hope it's not impossible.

mar-v-in commented 4 weeks ago

Yes, adding the public key to the web-push transport element should be sufficient.

I would suggest to specify that the vapid public key should be transferred as base64url-encoded string containing a point on the P-256 elliptic curve encoded in the uncompressed form - which is exactly the format accepted by the PushManager.subscribe method in the browser WebPush API.

AFAIK, Chrome requires the applicationServerKey to be specified and valid for push registration, so for testing purposes you can probably set app some small browser test app based on simple-push-demo, which allows to easily put the vapid public key in a constant: https://github.com/gauntface/simple-push-demo/blob/main/frontend/scripts/constants.js#L5