Provide support for subscription association

[martinthomson]

I think that this is better than #180 on balance. It's a little simpler.

[beverloo]

nit: https

[beverloo]

LGTM

I prefer using a BufferSource because (a) the UA generally won't have to do anything with the key, and (b) there is no ubiquitous support for uncompressed EC points across Web Crypto implementations.

I'm guessing that the common case will become something like:

const APPLICATION_SERVER_KEY = new Uint8Array([
    0x04, 0x00, 0x00, 0x00, ...
]);

Which is much more developer friendly than loading a CryptoKey object (which, in Chrome, requires converting to a JWK object prior to importing :-/).

Thank you! :)

[beverloo]

One question that came to mind - developers tend to call subscribe() multiple times, also as a means to get an existing subscription, since the API only supports once.

What happens when calling subscribe() with an applicationServerKey that differs from the subscription that's currently stored by the UA? Should we throw an error? InvalidAccessError sounds most appropriate, but NoModificationAllowedError (less common) might also work. Happy to address this in a follow-up.

[martinthomson]

Ahh, good point. I'll add a commit for that. Another question that occurs, similar to the above, do we want the value to be available for inspection? That seems relatively harmless, but it means that it will be serialized, which I'm not sure about.

[beverloo]

How would we confirm that the applicationServerKeys match without storing it? (Or a hash of the value.) It feels like a bit of a footgun if we don't throw an error for this situation.

Regarding exposing it again - it could be added to PushSubscription, but then it might be best to just expose the entire PushSubscriptionOptions object. This won't be very straightforward to implement this in Chrome and has some overhead, but we can do it.

I could live with not exposing it for a v1 as well, but I suspect that we'll get use-cases for it pretty quickly (e.g. "do I have to cycle my subscription").

[martinthomson]

There's an alternative design that this suggests: subscribe with different options creates a new subscription.

I think that exposing the options would be good. We can probably exclude them from the serializer. I'll open an issue to track both the change in options (throw an error) and the exposing of the current options. Might as well incrementally improve, and allow you time to work out how to expose stuff.