Re: [Webpush] Application server authentication new years edition

Costin Manolache <> Thu, 07 January 2016 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D50591A930A for <>; Thu, 7 Jan 2016 10:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PgFXDP-J6l-v for <>; Thu, 7 Jan 2016 10:59:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12AE61A92FD for <>; Thu, 7 Jan 2016 10:59:49 -0800 (PST)
Received: by with SMTP id y66so319901146oig.0 for <>; Thu, 07 Jan 2016 10:59:49 -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=gyMy+iOsi9IsBGFt2jcqy0iCoT60HSmQVdSBjlZEbKI=; b=M7YzaGfscurjtqPHVh/fJNKdto0BnIPEGUo0VFgaH1GEKLTlubfuyczLtuRAkn0M8t j/d5QU834WbMSIpBEC2sZmt1jpxERLiNWLhxmUs5s02IrySmFUAB61Ik2ZeUeBAXOeMq LKwYH4PfvvErakUZAWZ2+RadX5P+2RstItADegXCSxrRnTBZLT8VR3ow/sNhpvLLTefg HdishBnyC8ujtwGIueN6mGe73DCMjt5GdEnl2HQ1mOiDx56BFph82ZXkRUXA+hK88Q2j jR5tPPpRrlinLrNB1P4lyrtGDPu6UY0QwgusV4Aw2i+LesaPQmBukM2kX19EvGM8q23y p6dw==
MIME-Version: 1.0
X-Received: by with SMTP id z74mr75337587oif.24.1452193188465; Thu, 07 Jan 2016 10:59:48 -0800 (PST)
Received: by with HTTP; Thu, 7 Jan 2016 10:59:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 7 Jan 2016 10:59:48 -0800
Message-ID: <>
From: Costin Manolache <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary=001a1134f92024d3b10528c313ac
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 18:59:51 -0000

On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <>

> On 7 January 2016 at 16:43, Costin Manolache <> 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
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