Re: [Webpush] Vapid public key

[Costin Manolache <[e-mail]>]

IMHO the main problem with JWK is not size, but the inconsistency - would
be good for the
exact string used in subscribe() to also show in Authenticate.

Any problem with using auth-param:

Authorization: webpush JWTTOKEN, id=PUBKEY

Costin

On Tue, Nov 1, 2016 at 10:59 PM Martin Thomson <[e-mail]>
wrote:

> On 2 November 2016 at 16:10, Costin Manolache <[e-mail]> wrote:
> > Authorization: webpush PUBLICKEY:JWT_TOKEN
>
> The grammar (RFC 7235) is:
>
>      credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
>      token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
>
> With JWT, we've opted to use the "token68" form (also shown here).
> Given that base64url takes '-', '_', and '.', we could separate on
> '/'.  '/' is a valid base64 (the non-url-safe variant) character, but
> we could split on that.
>
> For existing implementations, you would have to accept that you are
> going to have to sniff for this, or we could use a new auth-scheme.  I
> think that sniffing should be workable given that you won't have a
> Crypto-Key header field.
>
> And before I forget, the ugliest option of all is to use JWK inside
> the JWT.  Here's an example of a JWK:
>
>
> {"crv":"P-256","ext":true,"key_ops":["verify"],"kty":"EC","x":"20zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyistS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"}
>
> The ext and key_ops fields can be omitted safely - I just pulled this
> straight out of webcrypto - though it's still even bigger than you
> might like.
>