[Webpush] Authorization to send messages

Benjamin Bangert <bbangert@mozilla.com> Thu, 05 March 2015 19:33 UTC

Return-Path: <bbangert@mozilla.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0694E1A8829 for <webpush@ietfa.amsl.com>; Thu, 5 Mar 2015 11:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5w3Q9jU0tOj3 for <webpush@ietfa.amsl.com>; Thu, 5 Mar 2015 11:33:08 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46711A87E4 for <webpush@ietf.org>; Thu, 5 Mar 2015 11:33:06 -0800 (PST)
Received: by wghl18 with SMTP id l18so8333142wgh.5 for <webpush@ietf.org>; Thu, 05 Mar 2015 11:33:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+hDZLngo01hEsfGS/64gYPth44mxKiZ3KjeLn7/JRFg=; b=bF3A5e55f1wr9kfROnrtFgO9uVFeB5ZG1o/acCzzYBYkUBlh2GE3ToGAokEuybujhZ DHqw+cGQRWv83HzYx5KqtQX4DymLMqcJ9b0zmdM6oUYSJ9aX1dpxW2poudyjZuhof9jD NXxXZk2GeMTcM3GAn/iMszNrdzahzXz40M1o5O79yOpf4PTrzl5LxhWh4Prt2h4maXrW 8jyco5E4VZYpNoWxG3XB5zePaebFWAZQ7+1xl+utWxXYVXtumnGjSUobWNvrbHrU6L7H +IvQRz1Vk0ZcEffUsyQ3A6AJV/rQvLhgnHXK5uRR/QPHYIAhwFReQatMLONhjqA0oe8D R/Pw==
X-Gm-Message-State: ALoCoQkai4SLKgw1K60EQ//wWPdAQuOMswitZZsUi+Ra3fVMVeUaIlNP0oEPOvbfKy5iLIMvRz+7
MIME-Version: 1.0
X-Received: by with SMTP id z8mr21202626wjx.45.1425583985365; Thu, 05 Mar 2015 11:33:05 -0800 (PST)
Received: by with HTTP; Thu, 5 Mar 2015 11:33:05 -0800 (PST)
Date: Thu, 05 Mar 2015 11:33:05 -0800
Message-ID: <CABp8EuLYjSwJBQS8BsRXsO2D155GyEFGzUF19VAkUJrrww9b4A@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bf0c58e0bb15205108fa3fb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/vu83ZFKv2uTPdjelcYskuyUPnQQ>
Subject: [Webpush] Authorization to send messages
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 19:33:11 -0000

In webpush http2-02, section 8.3 Authorization doesn't mention how the Push
Service should deal with authenticating an Application Server wishing to
send messages. From conversations I've heard, it does sound like all major
vendors plan on requiring Application Server's to provide some form of
authentication/token as GCM/APNS/etc already do.

It would make sense that if the PUT to the resource URL should fail with an
Authorization Required status, that there could be perhaps some way for an
AppServer developer to determine how they might go about getting
authorization. Perhaps an HTTP Header that indicates where the developer
should go to look at access policies and how to sign-up for the required

- Ben