Re: [Webpush] Application server authentication new years edition

Martin Thomson <> Thu, 07 January 2016 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D62001A01A3 for <>; Thu, 7 Jan 2016 13:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zSBVA6uRxCld for <>; Thu, 7 Jan 2016 13:57:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24D061A01A2 for <>; Thu, 7 Jan 2016 13:57:08 -0800 (PST)
Received: by with SMTP id g73so69713796ioe.3 for <>; Thu, 07 Jan 2016 13:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/4ULt0dQcubTG2WuHUnc2yasyOnQbg6NxEW0XwpSv8Q=; b=q8HPWJtjoySGpWXH5T4FnXo0q3bkHRfDkfSe0tgT2h0b3i2Bmj1YiwKlc9sU468mYF +2bdCwZNuUYf9U0xWac8aMYAl2t8N/sOTeLJX1j5nP0gzdCmrrcKgdpjOgpAW6WeO91V x0nhyDpXVdIKsKJ11hbjQsoxqRjukT8yvpFjOnxZEk4KwXqpr3HMMT5LHUi+cXynvFit R8xB8MpXh4hhN7XRUEMxvXn3mQ600GAXNlQSg8aeXi3hqWbrVBF9h5eOngELwYih9lqB 3fkwszItBiA4+lzIhzgQnwaUDF20v5OA1qWW2rcCK6ziASTgqIpH1FoGDLlVnENqlSLj 9bDw==
MIME-Version: 1.0
X-Received: by with SMTP id f40mr90651008iod.190.1452203827429; Thu, 07 Jan 2016 13:57:07 -0800 (PST)
Received: by with HTTP; Thu, 7 Jan 2016 13:57:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Fri, 8 Jan 2016 08:57:07 +1100
Message-ID: <>
From: Martin Thomson <>
To: Costin Manolache <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Ben Bangert <>, Costin Manolache <>, "" <>
Subject: Re: [Webpush] Application server authentication new years edition
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2016 21:57:10 -0000

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