Re: [Webpush] Vapid public key

[Costin Manolache <[e-mail]>]

On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson <[e-mail]>
wrote:

> On 20 November 2016 at 02:53, Costin Manolache <[e-mail]> wrote:
> > One more small suggestion: one of the pain points ( for me ) is the W3C
> > subscribe taking the
> > vapid pubkey as bytes instead of a string, and having to include the key
> in
> > .js files as a constant.
>
> Your suggestion being that we define a base64url parser.  You can
> include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);  It's
> bigger and you have to work it out once, but it saves shipping a
> converter.
>

Not really - the UA will need to take the uint8[] and convert it to b64 -
since that's what
the push service expects. AFAIK the UA has no use with the vapid public key
in current
protocol (except pass it along in subscribe) - we do not pass the
Authorization header
from push service to UA




>
> Either way, this is probably something to take here:
> https://github.com/w3c/push-api/issues
>
> > Would it be possible to define a .well-known/vapid/... file where the
> public
> > key can be saved ?
> > This may simplify tools, testing ( test env may use test sender keys),
> etc.
> > One problem is that
> > .well-known is at root - so either have
> > /.well-known/vapid/ENCODED_SW_URL.pub or
> > have a less standard .well-known/ in the same directory with the SW.
>
> Now that we are considering removal of Crypto-Key (I'm about to send
> out drafts with that change), I need to work out how to push the keys
> along with the registration.  I don't think that using .well-known
> will give us the right binding to the subscription request though.
>
> Maybe I don't understand the proposal, though.  Can you walk through
> how a client would use this?
>

If client calls subscribe() - the UA will look for .well-known/vapid.pub
and pass it
in the /subscribe request to the push service.

If client calls subscribe( Uint8Array ) - UA will use the explicit key.

It is a bit simpler to just copy the key in a defined location - in
particular if you have
multiple environments. It is possible to do it in code too ( using the URL
to decide
which key to use ). Some people may also like the more declarative
approach.

Not a big deal - but I think it would be nice.

Re. Crypto-Key: my understanding was that there are use cases for it, as a
way to
distribute keys, as discussed in the other thread. Subscribe needs some
header
( or query param ?) to pass the authorized entity to the push service. We
just
don't need it for authorization or encrypted body.

Costin