Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

Alexey Melnikov <> Tue, 15 August 2017 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FBFE132076; Tue, 15 Aug 2017 02:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Status: No, score=-2.719 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=D2evsDSi; dkim=pass (2048-bit key) header.b=MFDNipZ8
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LeLTJV41-RXV; Tue, 15 Aug 2017 02:36:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5FDA13203D; Tue, 15 Aug 2017 02:36:56 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 12047219DE; Tue, 15 Aug 2017 05:36:56 -0400 (EDT)
Received: from web5 ([]) by compute7.internal (MEProxy); Tue, 15 Aug 2017 05:36:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HjNdWLLcZLO4PTiapYY7j37T/8PPS Br9KHoFE3HbOSY=; b=D2evsDSih3I7aIxIN+xocc3oBkmIi767aD06qz7Cn+jAe zRXD8vUMeOD3nm/C8d0bFCy6oUChiDU2+ANuEW6pzx+gkY/74rilCIIz5vmFcLRV TfctMRHQUsEFZ6Yxq4Q3ngNiw8LfmHUp6zin5maPK64RSKMd9NbOuVd8Cwl93dFB l6E8OW3laWo5hZ93O3X43HYjuuOQQyu2OcRMygjwfb8VwQk9uI6aPZy21+i8wOrF 4rYdbydnSBxo4G5NA+Ztmr8m26HIPPXN2noWxNXhnEaVhfkZJ/ZxFbimwjvUgVS8 Sh/JZWAg8RlCHPSAUCvwNRZ/QUt4/TyiWMMKz1OaQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HjNdWL LcZLO4PTiapYY7j37T/8PPSBr9KHoFE3HbOSY=; b=MFDNipZ8r/ndfl9STIpIiF 3PJsfabi2W4nCW9WrdUM5V6q2ONxPILe3KXKZh6Fh/K7n13cSKWLnqZtkQzM7UJG YCx8PiItErz/efW7Ble4qbgQirwCELHOxQwOsxaL3nec2vHX9h+KqpUAyizNiJMK D7SmOLJgQBoaMNZ46+q/BXJq/jy8aK6RSiZwIqKFRLFrsMOnSnOBd0div16ASLA3 TCs2NQv56nBS3oZq1SnIHsEdhLlayC+U9YpeaK1OeyLO5dg+43zDPyvcbMydWCp9 bE/PwEdeuV90Wxtapb5ZXgmpNNbzmzZT8l++UHAJO7kBRonrzvg+VYn1hfElRBtw ==
X-ME-Sender: <xms:uMCSWU2_aoFV5yvq48tuvlPuRWZ8hn6RrCyj3DhUbUT4QmnzPsanoA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id E53BC9E270; Tue, 15 Aug 2017 05:36:55 -0400 (EDT)
Message-Id: <>
From: Alexey Melnikov <>
To: Martin Thomson <>
Cc: The IESG <>, "draft-ietf-webpush-vapid" <>, Phil Sorber <>,,
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-ff6d44b3
References: <> <>
Date: Tue, 15 Aug 2017 10:36:55 +0100
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)
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: Tue, 15 Aug 2017 09:36:58 -0000

On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote:
> On 2 August 2017 at 05:55, Alexey Melnikov <>
> wrote:
> > Firstly, "optjons" above should be "options". Secondly, the MIME type
> > registration of application/webpush-options+json says that the MIME type has no
> > parameters, yet you use charset above. So which is it?
> As Phil notes, the first was corrected already, the second is in
> c867529 on GitHub.  I'll push a new version at Adam's instruction.

I prefer a new draft.

What is the URL for the github? I couldn't find it on a quick glance.

> > In Section 3, 3rd para:
> >
> >    This authentication scheme does not require a challenge.  Clients are
> >    able to generate the Authorization header field without any
> >    additional information from a server.  Therefore, a challenge for
> >    this authentication scheme MUST NOT be sent in a WWW-Authenticate
> >    header field.
> >
> > Does this mean that there is no way to discover whether a particular server
> > supports "vapid" HTTP authentication scheme?
> Not directly.  There was a plan to expose this via the User Agent, but
> we didn't reach a conclusion:
> Another document could override this as well, I suppose.  The "MUST
> NOT" exists primarily because we don't define a challenge.

I think all authentication schemes should be discoverable in
WWW-Authenticate, as it is a part of HTTP authentication framework.

I think it would be good to clarify whether inclusion of "vapid" in
WWW-Authenticate without a challenge is allowed. The way your MUST NOT
is worded makes me think that this is something that a server
implementor can do accidentally. As there is no challenge data, I don't
see how this can happen anyway.