Subject: Re: [Webpush] webpush for http2 -02

From: Benjamin Bangert <[email-masked]>
Date: Thu, 12 Feb 2015 17:23:08 -0800

A few comments:

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)

Section 5:
- The examples show plain-text notification content while 8.1 indicates
subscriptions include a crypto key, so they should be an opaque encrypted
blob
- The Push Server should return an appropriate Bad Auth HTTP status code
when authorization is required of the Application Server.

Section 6:
- Should also show an encrypted blob

Section 7.2:
- It would be useful to have some minimum storage period

Section 7.3:
- It says the push service can expire it anytime, what happens if a client
is disconnected during this time? Or are push services only allowed to
expire subscriptions while the client is connected?

Section 8.3/8.4:
- It seems reasonable that Push Service providers will want to require an
App-Server developer to register their app and get an Oauth token or some
other scheme to indicate that they are allowed to push notifications (and
for Push Service providers to restrict maximum messages/throughput on a
per-app basis). Should this be mentioned here?

Cheers,
Ben

On Fri, Dec 12, 2014 at 4:01 PM, Martin Thomson <[email-masked]>
wrote:

> I've revised the protocol proposal for web push.
>
> https://datatracker.ietf.org/doc/draft-thomson-webpush-http2/
>
> A more readable HTML version is here, though this will be updated as I
> make changes:
>
> https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html
>
> This includes some fairly significant changes to incorporate the
> feedback I've received from various corners.  I haven't prepared a
> change log, but I believe that this covers at least the high points of
> what was discussed at the meeting:
>
>  - names of everything have changed
>  - I've added examples and expanded the explanatory text throughout
>  - removed use of 202 due to a privacy concern (thanks to Robert
> Sparks for sharing his experience with this)
>  - significantly expanded the operational considerations regarding
> load distribution and message retention
>  - minimum message size of 4k added
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Benjamin Bangert <[email-masked]>
Date: Thu, 12 Feb 2015 17:29:56 -0800

One other thought that comes to mind, is that the crypto for the encryption
needs to be included in the standard for consistency across browsers.
Alternatively, if the crypto is up to the browser (Maybe the standard just
specifies several appropriate secure methods), than the Subscription
request should indicate the required encryption/HMAC to use for the push
notifications to the Application Server knows how to appropriately encrypt
the notification with the provided key.

This way as crypto requirements change the browser can indicate the new
desired scheme to the Application Server without being stuck at a specific
now-obsolete method. Perhaps a crypto string similar to the SSL cipher
strings.

Cheers,
Ben

On Thu, Feb 12, 2015 at 5:23 PM, Benjamin Bangert <[email-masked]>
wrote:

>   - Browser stores the broadcast key with the new subscription (rather
> than generating its own key)
>
> Section 5: