Subject: [Webpush] Voluntary application server identification

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 15:43:57 -0800

I did a little write up of the options that I think are most likely
solutions for issue #44:
  https://martinthomson.github.io/webpush-vapid/

(Submission as an I-D is imminent.)

All the relevant considerations are covered in the draft.  I started
out by describing a single option, but realized that addressing the
alternatives was probably wise.  In doing so, I think that some
combination of alternatives might not be as crazy as I first thought.

Some are clearly less good.  In particular, request signing has been
proposed, but I think that putting a signature validation on the
critical path is not a great idea.  The other options are much better
in this regard.

---

From: Peter Beverloo <[email-masked]>
Date: Tue, 24 Nov 2015 16:45:04 +0000

Hi Martin,

Thank you for writing this up.

Something that server identification would enable is the ability for
subscriptions to be associated with a given application server, i.e.
not only relying on endpoint secrecy.

The proposed solution, having a TLS client certificate, has the benefit
that the certificate's public key could serve as a token for this
association. Not all alternative solutions have similar shareable tokens.

Both server identification and subscription association are important for
us, and, at least initially, mechanisms that we will mandate use of. If
this proposal works for everybody, we may have to consider a status code
through which the push service can indicate this.

(I realize that this, unfortunately, stands in contrast to your statement
that requiring authentication is unwanted. I personally believe that the
benefits of authentication outweigh the privacy implications - self
signed certificates w/o data fields only act as a persistent token. I see
no problem with other push services not mandating this, of course.)

Let me produce a similar proposal, building on yours, to further explore
subscription association.

Thanks,
Peter

On Mon, Nov 23, 2015 at 11:43 PM, Martin Thomson <[email-masked]>
wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Nov 2015 09:03:11 -0800

> association. Not all alternative solutions have similar shareable tokens.

All the signature-based options have this property (though the -cavage
option would need to be enhanced a little, unless you require the
additional step below).

> through which the push service can indicate this.

This is a good point.  The idea being that you could have an
application feed the public key it's application server will use to
the .subscribe() method on the API.  That would propagate up to the
push service and the push service would drop push messages that
weren't signed with the corresponding private key.

I didn't want to introduce too many new concepts at once, but this is
a good idea.  I'd like to keep it optional, of course.