Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <[e-mail]>
wrote:

> On 7 January 2016 at 16:43, Costin Manolache <[e-mail]> wrote:
> > That leaves 2.3 only.
>
> It looks like we're mostly in agreement for something like 2.3.
> Should I take some time and flesh out the details?  Does anyone
> disagree?
>

Sounds good, but I have few questions/comments on the details.

1. Key identifiers ('kid') - for normal JWT, the key is known from the
issuer or
'sub'. Since in our case we'll have self-generated keys, and we want to
avoid
having each key registered with all providers - all that a push service
will know
when seeing a JWT token the first time will be the content of the token.
So we need a way to find the public key needed to verify the content - and
the only one I know is to use something like the SHA of the public key.
On subscribe - the provider can store the public key, with the kid as
lookup key, than
on send it can verify. For example kid == (SHA1 or SHA256 truncated to
64bits) would work.

2. 'aud' field - not sure what would be the right value, maybe the domain
of the push provider ?

3. Going back to the 'voluntary'/optional part: I'm not sure if encryption
is going to be required or
optional in the final version ?

4. I think we can have the sender key optional in the subscribe operation,
in particular for cases
like low end IOT - not including it would give permission to anyone with
the URL and pubkey
of the device to send messages. There is another case where it helps -
pairing, in cases of D2D -
but with restrictions ( either time, or binding the subscription to the
sender at first use ).
In other words: I'm not opposed to having 'optional' on the subscribe (and
on contact info).

5. This may be a bit controversial :-), if we require the developers to use
a JOSE library to
generate JWT tokens, signed with a ES256 - wouldn't make sense to also
allow them to use
the same library to encrypt the payload for the e2e ? There is already a
content type defined, so easy to
differentiate.


Costin