Re: [Webpush] Vapid public key

[jr conlin <[e-mail]>]

FWIW, I'm really not a fan of having an extra data path for things like
this. More paths mean more things that folks can screw up or not be able
to implement for various reasons.

I think it's HIGHLY reasonable to ask that for a given restricted
update, the Application that is making the request include a public key
for the VAPID spec. The application could pull it from where ever, hard
code it, or whatever makes most sense to the Application developer team
(and the corresponding Subscription Update service provider).

Things aren't exactly easy now, making them harder just means that less
folks will be able to do it.

On 11/20/2016 8:01 PM, Costin Manolache wrote:
>
>
> On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 20 November 2016 at 02:53, Costin Manolache <[e-mail]
>     <mailto:[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 itI"m a 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

I'm a bit confused here. If you use most key generation tools like
$ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
$ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
$ grep -v "^-" vapid_public.pe
that dumps a b64 string the user can easily work with. Is the suggestion
that we ask users to convert to binary themselves? That may reduce the
need for base64 in the UA, but means that developers will need to add
one. Considering the fun that happened with "lpad" not too long ago, I'm
a bit concerned about the frustration that may come with that.

>  
>
>
>     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.
... So the subscription provider will have to be able to create and
maintain a discrete path, the UA will need to make an extra successful
data call, just to provide a string that is for public consumption?
>
> If client calls subscribe( Uint8Array ) - UA will use the explicit key.
Again, bit confused here. Granted, the UA's subscribe() function can do
whatever it wants once it has the public key. How the server actually
enacts the subscription restriction is irrelevant to both the UA and the
Subscription provider.

The UA can also accept a key in several different formats by doing
simple tests. Likewise, how the Application acquires the key is really
up to the Application.

I'm seeing this more as "suggested practices" and "platform features"
rather than part of the specification.
> 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.
Huh, I'd argue that it may not always be possible. Some small vendor
platforms may not offer access to directories like "/.well-known" (e.g.
if you're working with classical Apache, you may be forced to root under
"/username/...", or some platforms may prohibit the use of leading "."
because of poor path management. I've had to deal with both in the past.

Hopefully, I'm must misunderstanding the proposal again.

>  
> 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