Re: [Webpush] Application server authentication new years edition

Martin Thomson <> Wed, 06 January 2016 09:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E45811ACDD2 for <>; Wed, 6 Jan 2016 01:16:34 -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 2Hr6jeYkNZqm for <>; Wed, 6 Jan 2016 01:16:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75B861ACDD0 for <>; Wed, 6 Jan 2016 01:16:33 -0800 (PST)
Received: by with SMTP id 1so166014344ion.1 for <>; Wed, 06 Jan 2016 01:16:33 -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=zH5puJi0ytBzTgiIT7WcLtpUVSn3OrPwh/K2i+0fkWY=; b=ZmbSWF4yxhpeuj5IbLmY0rXJ9AHY8EFGTPj7AX13N27+VmOUL+kU7nyXbQpvQeIjR0 bQRo7PkU7YaxJEoV16dooTFhqQmc68pOIzrjL3LbSUhHGmKTI5IsUJlg1ARfV7arU/HQ YHLuQzjgPUJu5VM9DBMEvGT+UwFRMYgmgjkFAGku0ma+xX5pdwAqONexIQWH5oa4JYXW iyD0YUkSKWImKS6TTCnoYCxIzT4bUhdzm/2mPgijIL/pnpoUl8y/l13Nun2zbGLr0Wrd vWnpDEKUAzJjSuCCKU/JJflhT113yQrfOT5ghjT45VUH67X81tAz0EnTF4ZvZnbDj/uQ bOnA==
MIME-Version: 1.0
X-Received: by with SMTP id f40mr80562826iod.190.1452071792910; Wed, 06 Jan 2016 01:16:32 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 01:16:32 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 6 Jan 2016 20:16:32 +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: Wed, 06 Jan 2016 09:16:35 -0000

On 6 January 2016 at 15:55, Costin Manolache <> wrote:
> It is important to define what "voluntary" means :-). My understanding is
> that it involves
> a choice made by an entity, either the app server and push service.

I hope that the draft makes it clear enough: "voluntary" refers to the
choice at the app server whether to provide this information.

> The only 'voluntary' choice an app server has is to not use
> a push service and UAs that requires authentication/authorization.

Right, and I don't think that this is a choice we want to force people
into making.  That has some fairly dire market effects.

> For authentication:  2.1(certificate) would be my preference, and is a well
> known and established
> mechanism, followed by 2.6, 2.3.

Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
connection.  Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.  JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.

> -2.4 doesn't cover authentication,
> -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know the
> outcome)

I agree.  We don't really know how to solve the signing problem, and
not from a lack of trying.

> -2.2 is what we use now, but doesn't work well with 3. - subscription
> association - if
> public keys are used.
> For authorization - or "subscription association" - big +1 :-)

Yeah, I like the subscription association feature too.  I think that
it's an important consideration in choosing a mechanism.

> For contact - each of the authentication schemes in the draft provide a way
> to include contact info, and
> the choice for senders is to include it or not, and the choice for push
> services is to throttle/reject
>  or not. The tricky part is if any additional verification will be done by
> push services.
> I guess some providers (in particular free services) may be ok with a more
> relaxed verification
> or even allow some rate-limited sending without contact info, I personally
> don't mind it - if we
> can't contact a sender in case of problems we just block it.

That's the policy that we've discussed having.  I think that it is
very important to allow requests from all comers, even without
authentication.  Of course, services should be prepared to cut off
those unauthenticated requests very quickly as load increases.