Subject: [Webpush] Subscription split

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Mar 2015 10:00:46 -0700

Subscriptions are currently identified by a single URI.  That URI is
used to identify the subscription to the user agent and is also used
by the application server to request delivery of messages.

I discovered this when Brian Raymor noted that the text on
subscription removal was a little weak.  In attempting to fix it, I
found that the current structure is awkward. You need some unspecified
authentication of clients if you want to authorize a request to remove
a subscription.

I see a few options, and I'd like some input:

1. This is OK.  It's relatively straightforward to determine that the
DELETE request is being made by the same client that created the
subscription.  Trivially, you could set a cookie.

2. Split the subscription.  Subscriptions would be identified
privately with one identifier that the client sees and uses, and a
"public" identifier that is distributed to the application server.
That makes authorization for removal a simple matter because only the
private identifier is needed.

3. Don't specify subscription removal.

Both 1 and 2 have roughly equivalent security properties (in the
absence of token binding), though stronger authentication is possible
either way.

Option 3 has the worrying characteristic whereby a user agent is
unable to selectively revoke push access if it discovered that a
particular application is behaving badly.  On the other hand, these
events are rare enough that perhaps deleting the registration is
acceptable.

The cost of option 2 is a modest increase in complexity, a new link
relation type and some less visible effects on the HTTP side of
things.  The two resources would have linked state that would not be
visible at the HTTP layer; a single resource potentially allows
generic HTTP-layer processing, whereas a split would require more
specific logic.

On the other hand option 2 makes it marginally easier to do what
Microsoft have proposed and remove the concept of a registration.  (I
don't personally think that is a good idea, but I'm not violently
opposed to it either.)

---

From: Elio Damaggio <[email-masked]>
Date: Thu, 12 Mar 2015 22:06:55 +0000

+1  for #2.

Brian Raymor and I were thinking about using two identifiers for subscriptions, one with send rights (for the AS, or "public") and one with monitor/delete rights (for the UA or "private").
The main idea is that those identifiers can be tokens signed by the Push Server. Each token contains the unique subscription id plus the claims that they enable (send vs monitor+delete).

In general, having two identifiers increases security by distributing only the rights that are required to be distributed (i.e. send rights to the AS), and it just seems a good security practice.

Elio

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, March 12, 2015 10:01 AM
To: [email-masked]
Subject: [Webpush] Subscription split

Subscriptions are currently identified by a single URI.  That URI is used to identify the subscription to the user agent and is also used by the application server to request delivery of messages.

I discovered this when Brian Raymor noted that the text on subscription removal was a little weak.  In attempting to fix it, I found that the current structure is awkward. You need some unspecified authentication of clients if you want to authorize a request to remove a subscription.

1. This is OK.  It's relatively straightforward to determine that the DELETE request is being made by the same client that created the subscription.  Trivially, you could set a cookie.

2. Split the subscription.  Subscriptions would be identified privately with one identifier that the client sees and uses, and a "public" identifier that is distributed to the application server.
That makes authorization for removal a simple matter because only the private identifier is needed.

Both 1 and 2 have roughly equivalent security properties (in the absence of token binding), though stronger authentication is possible either way.

Option 3 has the worrying characteristic whereby a user agent is unable to selectively revoke push access if it discovered that a particular application is behaving badly.  On the other hand, these events are rare enough that perhaps deleting the registration is acceptable.

The cost of option 2 is a modest increase in complexity, a new link relation type and some less visible effects on the HTTP side of things.  The two resources would have linked state that would not be visible at the HTTP layer; a single resource potentially allows generic HTTP-layer processing, whereas a split would require more specific logic.

On the other hand option 2 makes it marginally easier to do what Microsoft have proposed and remove the concept of a registration.  (I don't personally think that is a good idea, but I'm not violently opposed to it either.)

_______________________________________________
Webpush mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webpush

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Mar 2015 11:27:59 -0700

On 12 March 2015 at 15:45, SULLIVAN, BRYAN L <[email-masked]> wrote:
> If the client (web app running on the user's device) has sole rights to subscription management, how do you handle the case in which the client loses the subscription identifier/token (e.g. UA is reset, loses cookies, etc) and the client can't then stop the server from sending messages?

The UA has to explicitly request message delivery.  So, if it loses a
subscription, it can choose to drop the registration and try again.
Or, as Elio would have it, you need to ask for messages for each
subscription independently, so you can't get messages delivered for
contexts you have forgotten about.

---

From: Costin Manolache <[email-masked]>
Date: Fri, 13 Mar 2015 23:05:38 -0700

I like option 2 - the subscription will need at least a key pair for
encryption, with the private key only on the UA. The private key can be
used to sign removal requests, or any other request that would authenticate
the client as owning the subscription.

Costin