Re: [Webpush] User Agents should return a list of supported encryption content types

JR Conlin <> Wed, 19 April 2017 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88199127337 for <>; Wed, 19 Apr 2017 15:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GQAslhKO53Kn for <>; Wed, 19 Apr 2017 15:44:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37DF7129B63 for <>; Wed, 19 Apr 2017 15:44:33 -0700 (PDT)
Received: by with SMTP id 75so19916866lfs.2 for <>; Wed, 19 Apr 2017 15:44:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=Zdscgg/wqkN7R55ZXMbgJu7vbASgNaBfhq5E56Em1nN4fRBYqEfVF5E3NYopWA36uG h2a8p+ynuXGXisbM+uu/qrkveDGqK9HVTZe50ftzoxcdfNypJCx/wFPbWjgWULV0Nyoq hHsQssOV8djDpuWKIMBz29cwSoQR6MjiNUItA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=X7HYHt9kpK+fsnkD1zlAkBpT9OB2g8tH4UCheCFVYyCcQuT9ZwdaM7piSiwnm8UlMz DivGicaQrxQDNs1HrPrshlLH570wkBlN2dTobqrC2ah5XsU+wfhC71D6SAIIebwOMlUQ s2nemVI+OcDnm1972Bfx2EeR6XJEkefjYoD0P7ExyZ6ybHUZGSKAN0qKUqJkKHH1QaBs xFe2KUcDhbjyTypXcFHyW4UxOOgCPP2o1GWopHcRpAxfmc8nEBh2FYVogwErCItZ+k5k ejOX82unFoAKGfJQplI/1L+4qtunG08yYDlYamVBVzKiAj/uTsnqzDXeJOq5UDe0bE2Z AH+g==
X-Gm-Message-State: AN3rC/7jdhgo2qMPPXPwTFp242pUoDmndy4LsWSi42R2OJFY2xyRVENL 4KHZDcZglQ37YBkkTkNVmghOuHlLKfocCHM=
X-Received: by with SMTP id m128mr1800738lfe.1.1492641871333; Wed, 19 Apr 2017 15:44:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Apr 2017 15:44:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: JR Conlin <>
Date: Wed, 19 Apr 2017 15:44:30 -0700
Message-ID: <>
To: John Reid Conlin <>
Cc: Kit Cambridge <>, "" <>
Content-Type: multipart/alternative; boundary=001a11410b4e84a77c054d8cc4c7
Archived-At: <>
Subject: Re: [Webpush] User Agents should return a list of supported encryption content types
X-Mailman-Version: 2.1.22
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: Wed, 19 Apr 2017 22:44:36 -0000

And I've just realized that I have mislabled it as "contenttypes" instead
of "contentencodings".

On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin <> wrote:

> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <> wrote:
>> 2) it's non-authoritative. The push server either is told or must guess
>>> the state of an individual client. This means that it must track known UAs
>>> (since a message can be stored for later retrieval by the UA). Having the
>>> "source of truth" specify what's allowed and what's not at the time of
>>> subscription, ensures that the most accurate data is provided.
>> I don't follow, apologies. For Autopush, we already keep client info in
>> the router table: its UAID, last connect time, and whether it uses Web
>> Push, Simple Push, FCM, or APNs. We need to look this up regardless of
>> whether we store or immediately deliver the message. It's not clear to me
>> why we'd need to guess, or who the third party is. I think I'm missing
>> something, though. Could you please elaborate?
> ​Certainly. It's true that for our server, we do track the state of a
> previously connected UA for up to 30 days. (If a UA has not connected in 30
> days, we consider that UA to be "unavailable" and reject messages.) The
> problem is that the client would still need to inform the push server which
> content types it supported, much the same as it would need to tell the
> subscription provider. ​
> The crux of this is that the Push Service is the "third party". It doesn't
> care what the encryption format is, since it just passes the data on. The
> two parties of interest in this case are the User Agent (which is
> responsible for decoding the final message) and the Subscription Provider
> (which is responsible for encoding the message). The Push Service may do
> some minimal, superficial checks of the message it's carrying, in order to
> reduce the traffic costs to the UA, but it cannot do a full check since
> that would presumably require deciphering the message.
> That's why I feel it's best to keep the pertinent information in the
> exchange between the UA and the subscriber directly, much like how the
> public key comes from the UA and not the Push Server.