Re: [Webpush] Application server authentication new years edition

[Martin Thomson <[e-mail]>]

On 8 January 2016 at 05:59, Costin Manolache <[e-mail]> wrote:
> 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.

The push service is going to need the public key, so that means
including a JWK in the message, I think.  Knowing a hash of the public
key isn't enough.

I think that we can avoid using key identifiers.  We could include one
and use that to reference another header field, but it is easier to
say that there is exactly one JWT and exactly one JWK and that one
depends on the other.

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

I specified URL at the suggestion of Chris, but I had the same thought
you did.  Maybe we can trim it to origin.  That reduces portability
considerably and also shortens the token somewhat.

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

The protocol won't absolutely require it, though it will strongly
recommend it.  (I'd prefer to require it, but there you have it.)  The
W3C API will require encryption.  Does that make sense?

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

I agree.  Making the JWT mandatory on the subscription would introduce
some operational problems for the cases where one endpoint has to be
used by several different application servers too.

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

I don't know of any way to do that without also massively inflating
the size of the payload.  There is a mapping to JWE already in the
encryption draft for those who would prefer to reuse their library.
The tricky part is key derivation, but I think that's largely
unavoidable in this case.