Re: [w3c/push-api] What type of equality checking is being performed for options. (#275)

The `options` attribute is an instance of [`PushSubcriptionsOptionsInit`](https://www.w3.org/TR/push-api/#idl-def-pushsubscriptionoptionsinit), which has the `applicationServerKey` member that you're referring to. Our intent with the phrasing of 8.10.4. is to avoid repeating the individual members of `PushSubscriptionOptions`.

When the developer passes a `DOMString`, step 8.4.1. converts it to a `BufferSource`, but we don't write it back to `options`. That means that step 8.10.4. would still use the `DOMString`, and would thus fail.

I'm not sure what the cleanest way of fixing this is. Changing 8.4. to the following may work?

> 1. If the `applicationServerKey` is provided as a `DOMString`, set its value to a `BufferSource` containing the sequence of octets that result from decoding `applicationServerKey` using the base64url encoding [RFC7515]. If decoding fails, reject `promise` with a `DOMException` whose name is "InvalidCharacterError" and terminate these steps.
> 2. Ensure that the `applicationServerKey` describes a valid point on the P-256 curve. If the `applicationServerKey` value is invalid, reject promise with a `DOMException` whose name is "InvalidAccessError" and terminate these steps.

What do you think, @martinthomson?

-- 
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/275#issuecomment-323790801