[Webpush] Broadcast (was Re: webpush for http2 -02)

Martin Thomson <martin.thomson@gmail.com> Fri, 13 February 2015 04:41 UTC

Return-Path: <martin.thomson@gmail.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 643D91A0081 for <webpush@ietfa.amsl.com>; Thu, 12 Feb 2015 20:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yC6cwQTrjoTs for <webpush@ietfa.amsl.com>; Thu, 12 Feb 2015 20:41:08 -0800 (PST)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 57AD81A007A for <webpush@ietf.org>; Thu, 12 Feb 2015 20:41:08 -0800 (PST)
Received: by mail-ob0-f173.google.com with SMTP id uy5so16161902obc.4 for <webpush@ietf.org>; Thu, 12 Feb 2015 20:41:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oV7GQ8Bdg1tsm7XvakBzWhiBXIJmaU/Fuxwf+v1CRwM=; b=Fziy6EfjMRnPFr0+i0ndzCjmY2gXzTKxTQUNpayRCHYEz4gx5T/CSPk22ltOQcXtkS UORqEVUt1jR5hRULIs8HJNhBmkHkhcpZuvuj7wpWxQd+URBqG45qs7cptOFa37G5JwLb vDWifIxHRnKyIUWCliflVBwXKOgvcEdvKJdjtB/3xtYZ50+pDJEv86YH7S/Oz+LuqoPo XMDJjXaY+NW6b9L58WSgEKlpWnuj+2UTnc7WUoNpEsYBg6gUgHFTN+H4yrCIQby1eu8w vrKMckI3pLDlWTcJfR8MHp/grUdKGWO1dW41mt/PiPGDsl/4vnolXx56cJ0VEQczQhxh 5chw==
MIME-Version: 1.0
X-Received: by with SMTP id y8mr4927964oia.12.1423802467693; Thu, 12 Feb 2015 20:41:07 -0800 (PST)
Received: by with HTTP; Thu, 12 Feb 2015 20:41:07 -0800 (PST)
Date: Fri, 13 Feb 2015 15:41:07 +1100
Message-ID: <CABkgnnX29V6bLS2VneZWrRt8RJuAPhnyb3-TDBpoOYZ_JS6+mQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Benjamin Bangert <bbangert@mozilla.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/erUv8VCy1c9xheQdF7rGZY-65hg>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: [Webpush] Broadcast (was Re: webpush for http2 -02)
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: Fri, 13 Feb 2015 04:41:11 -0000

On 13 February 2015 at 12:23, Benjamin Bangert <bbangert@mozilla.com> wrote:
> Section 2:
> - The diagram is good, but I think adding one variant for broadcast messages
> would be good. I could see a crypto secured broadcast working like so:
>   - Broadcast Subscribe (In contrast to normal subscribe)
>   - Browser Agent makes Provide Subscription request to Application,
> including request (flag) to be issued the broadcast key
>   - Browser stores the broadcast key with the new subscription (rather than
> generating its own key)

I have proposed a separate document with a different model for
broadcast.  In that, clients/browsers/UAs don't drive the subscription
to a broadcast, that broadcast is managed by the application sender.
I got the sense that there wasn't a whole lot of interest in a
broadcast system in the initial stages.

The advantage there is that you don't have to worry about clients
having to be able to connect to push services that they might not have
a pre-existing relationship with (and therefore federate
authorization).  The disadvantage is that it drives more of the
responsibility for push fanout onto the application server.

In your proposal here, how do you see the broadcast subscription being
identified and managed?  Would an application request the creation of
one and then distribute it to its clients to subscribe to?