Re: [Webpush] Mirja Kühlewind's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT)

[Martin Thomson <[e-mail]>]

On 13 October 2016 at 02:38, Mirja Kuehlewind <[e-mail]> wrote:
> 1) Would it be possible for a user agent to use the same push service
> with multiple application servers? Or is this the case where a
> subscription set should be used? What happens in this case? Also, is
> there a possibility for different user agents to use the same push
> service if they would need to receive the same message from the same
> server...? Just thinking...

A UA can use the same push service for multiple subscriptions.
Subscription sets help with that by aggregating push messages (you
only have to make one request to retrieve messages for multiple
subscriptions).

Different user agents cannot get the same message from the service
unless it is sent to them separately.  Every message is encrypted
toward a specific recipient and the push service treats different
clients as completely independent.

This is in contrast to a centralized pub-sub system where a "channel"
might be read from by multiple subscribers. This would be a feature
some proprietary push services have more or less, but the privacy and
security properties of that feature - frankly - stink.

> 2) section 8.4 says:
> "To address this case, the W3C Push API [API] has adopted Voluntary
>    Application Server Identification [I-D.ietf-webpush-vapid], which
>    allows a user agent to restrict a subscription to a specific
>    application server. "
> How does the user agent signal to the push service which application
> servers should be accepted? Did I miss that?

All the details are in the referenced draft.

> Nit?:
> - In the Figure at the beginning of section 2 (which doesn't have a
> caption btw.) I guess you should use "application server" instead of
> "application" otherwise the previous definition is confusing...
>
> Also here in section 8 (s/application/application server):
> "This includes any communications
>    between user agent and push service, plus communications between the
>    application and the push service. "

Thanks for picking these out, we try to be consistent, but often fail:
https://github.com/webpush-wg/webpush-protocol/pull/137