Subject: [Webpush] Delivery receipt question

From: Costin Manolache <[email-masked]>
Date: Mon, 15 Jun 2015 12:05:15 -0700

As result to subscribe, the webpush service is required to return a link
with rel=urn:ietf:params:push:receipt (section 3)

In section 4, the URL returned is exchanged for another URL - and the text
is a bit confusing on "application may reuse the same receipt resource".
Also not clear how the push service would return the same "receipt
subscribe URI to user agents".

There are 2 problems, the smallest is that for each subscription it
requires an extra HTTP request to exchange 2 URLs - it would be more
efficient for the push service to directly return the "receipt subscription
resource", and save 1/2 QPS on the subscription service. This may seem
small - but there are additional savings on reducing the consistency
requirements if nosql storage is used. In most cases the subscribe from UA
and the "subscribe to receipts" happen in different zones, and in short
time.

The bigger issue is that it's not clear how it would be possible to
implement this in an efficient way - I can see how it can be done if the
app would issue a GET for each subscription, but that's practically
impossible ( some apps run close to 1B subscriptions ).

The only way to have working receipts is to have the app get a single
resource where it'll get receipts for all the subscriptions. This is
currently impossible since the webpush service doesn't have any information
to associate subscriptions to an app sender.

My proposal is to define that if "sender authentication" is required by a
webpush service, the sender ID should be included in the /subscribe
request, and the webpush service should return a unique receipt subscribe
URI for each sender ID.

Alternatively, the subscribe should include the 'origin' of the app, and an
unique
receipt resource would be created for each app. This will be harder to
implement -
the webpush service will need to authenticate the request for receiving
receipts, and only send the receipts for messages sent by the same sender.

I'm not aware of any scalable solution for the webpush providers that will
not require sender authentication - there is simply not enough information
to know that 2 push:receipt URLs correspond to same app or sender ( or
maybe I'm missing something obvious ? ).

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 14:08:34 -0700

On 15 June 2015 at 12:05, Costin Manolache <[email-masked]> wrote:
> Also not clear how the push service would return the same "receipt subscribe
> URI to user agents".

I think that I can see how this might be confusing, but I might need
your help so that we can make it clearer in the document.

Maybe if we can take it in reverse.

Each application server needs to have a unique URI that it subscribes
to for receipts.  Or, at best, a very small number of URIs, maybe one
for each push service that it has talked to.  1B would be ludicrous, I
agree.

The way that the application server gets those URIs is by
registering/subscribing.  But it doesn't know, a priori, where to do
that.  So the UA provides it with the identity of a resource that can
be used to register.  Currently, the application server registration
results in a "receipt subscription" resource being provided.

The text in question notes that the way that an application server
learns about whether this is a new push service, or one that it
already knows about is by performing a comparison between the URIs
handed to clients.  Perhaps putting a different way would help.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 15 Jun 2015 14:27:06 -0700

> handed to clients.  Perhaps putting a different way would help.

Yes, this is similar with what I was proposing - the application server
needs
one URI per webpush service, and the way to get it is via a one-time
subscription of the 'app server' with the webpush service.

In this case I don't think we need the complexity of a separate
urn:ietf:params:push:receipt - the /subscribe URI would work as well
for app servers as it does for UA. But I'm ok with having a separate
URI or returning it as push:receipt link.

The main question remains: even if you have one URI per app server,
how do we associate each message or app subscription to the URI
of the app server. For authenticated sender - it can be done by matching
the authenticated ID on the message send and on receipt request.
I don't know any good way for un-authenticated sender.

Costin

---

From: Darshak Thakore <[email-masked]>
Date: Fri, 19 Jun 2015 23:14:22 +0000

On 6/15/15, 3:27 PM, "Costin Manolache" <[email-masked]<mailto:[email-masked]>> wrote:

Costin

Isn’t the Push-Receipt header supposed to associate each message with the receipt subscription URI of the sender (application server) ?

As I understand it, each push message request is supposed to look as follows

———————————————
POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1
Host: push.example.net
Content-Type: text/plain;charset=utf8
Content-Length: 36
TTL: 5
Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
———————————————

That’s my understanding but it would be good if someone else can confirm it :-)

Darshak

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jun 2015 17:20:58 -0700

On 19 June 2015 at 16:14, Darshak Thakore <[email-masked]> wrote:
> Isn’t the Push-Receipt header supposed to associate each message with the
> receipt subscription URI of the sender (application server) ?

Yes, that header field can serve to correlate pushes from the same
application server.

---

From: Costin Manolache <[email-masked]>
Date: Fri, 19 Jun 2015 23:50:19 -0700

On Fri, Jun 19, 2015 at 4:14 PM, Darshak Thakore <[email-masked]>
wrote:

>
>   On 6/15/15, 3:27 PM, "Costin Manolache" <[email-masked]> wrote:
>
>
>  Isn’t the Push-Receipt header supposed to associate each message with
> the receipt subscription URI of the sender (application server) ?
>

Again - this is very similar with what I am proposing - the important thing
missing is that in the current draft, there is no
such thing as " receipt subscription URI of the sender (application
server)". Only apps in UA subscribe - and
the Push-Receipt returned is unique per app - since there is no way for
anyone to determine that 2 app instances
actually want to talk with the same app server.

The sender is not identified, and it doesn't subscribe in the current spec.
My proposal is to define that senders
also subscribe - and get back some identifier ( subscription URL can act as
an identifier ).

In GCM - subscribe takes the sender ID as a parameter in subscribe, and
sending has the sender ID in the authorization
header, so it's clear where delivery receipts should be sent.

Costin