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

Martin Thomson <> Wed, 02 August 2017 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D7981275FD; Tue, 1 Aug 2017 17:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VAHV8S2SfGRS; Tue, 1 Aug 2017 17:14:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E9BA129AAD; Tue, 1 Aug 2017 17:14:10 -0700 (PDT)
Received: by with SMTP id v127so16669984itd.0; Tue, 01 Aug 2017 17:14:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxjtZcd7tOxnhcP2gGy60pY8zRHCppO1WDfEW+FIkhA=; b=t9DzJPPmpiEJZjnaBJ2ISGQQNw3NaGd6RfdL7H4fjafYPdLyPx+4kzaf99v2RSVMHM MH6d6ZYBExAWHRlVPAS0ci4THIt8C+kMFAdC1J9kcQA4apX5mmupcniuGOGc7oRIceK3 t8MbuiuJfuCNxHIoQh29qQGzWfB0xToAE30NPtwLG+yGmWDRCWRgj/LRlVCOQvXlgwj2 TzO44xLZ9PAHX3EH8AeRYzmea1psSg/pGT861sP/nQFauzsf3/q3ABHvcGmTPmt9UAZN E+1M1mU9xO91HEerpK8ZcrGv3Qir41LXxOiWid5eWOHv5/OKu5c3N72lhgcA0N7VKiX3 KOkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxjtZcd7tOxnhcP2gGy60pY8zRHCppO1WDfEW+FIkhA=; b=CohWXHS5dzyzKOPXu7KSbE/IHOXuJH0kRY0b8jKemh9sOgBa8aSklWbWi/fV99XtAT uRCE7tgD1M0hmqX8RB5BBf1TIq9yQL6t1uCCemm1wcdgY12gzk0KgNseFmWI0If4g5AX 85DzY37hAZkS+oi3RIyov6URVjiyLSjNOtSmJ56yh/UCQzf0QNjfnGHFAHsBkN78vcsu GVrs7TJXxgflbNnqzGto2rbjvbz/v2SOiq9mjhnAtpjbpneJWSLbZLdMsMcdBzmfHS0v 066FLy0hlnHGM4X2S9IzwlqvnXec2A4asJWKWTIRqgX/kB9L/8bXrUbSv0+1M1UpqGKL zF7Q==
X-Gm-Message-State: AIVw110dovwGtBaOht4EJMJ/dt3iUQLbZ2eQJJ+7YD6ETSuITrDHnp14 14CEktrdZXRjQS9xarDd/Qqsr6KrRw==
X-Received: by with SMTP id n189mr3270044itd.79.1501632849581; Tue, 01 Aug 2017 17:14:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Aug 2017 17:14:09 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Wed, 2 Aug 2017 10:14:09 +1000
Message-ID: <>
To: Alexey Melnikov <>
Cc: The IESG <>, draft-ietf-webpush-vapid <>, Phil Sorber <>,, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 02 Aug 2017 00:14:12 -0000

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.

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