Subject: [Webpush] Authenticating senders

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jun 2015 12:39:51 -0700

On 30 May 2015 at 14:48, Costin Manolache <[email-masked]> wrote:
> Some metadata is needed for operating the service.
>
> Authenticating the sender doesn't need to expose more than absolutely
> needed.

Let's talk about what properties we are looking to provide here.

Are we simply looking for a way for a server to track individual
senders?  Building up a reputation associated with a particular sender
is important in detecting abnormal patterns of requests.

An asymmetric key pair certainly accomplishes that goal.  But so does
a cookie, at a much lower cost.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 1 Jun 2015 18:09:14 -0700

> Let's talk about what properties we are looking to provide here.

- a stable identity for each sender
- a secure way to authenticate the sender ( otherwise anyone can
impersonate a sender ).
- some way to contact the sender - it can be the domain name/origin ( and
use Whois info to contact ), or
an email. If it is valid - the sender may be contacted in case of problems
that can be fixed, it happens
quite often we detect some bugs and usually they get fixed in hours/days
when we contact the sender.
If it is not valid  or missing - the only recourse is to block the sender,
and we may allow only low QPS.

Nice to have:
- a way to associate or register the same identity with multiple push
providers

> a cookie, at a much lower cost.

As long as the push service gets an "Authorization:" header that it can use
to
verify the sender - it doesn't matter if you call it a 'cookie' or token.
What matters is how does the sender gets this cookie, and how does the push
service uses the cookie.

The reason I'm proposing a key pair is simple: we already define this for
app.
In order to send a message, you need a 'subscription URL' and the public
key generated by the UA.
So each 'receiving' side has a key pair.

I don't see generating another key pair for the sending side as a major
problem. Servers need to generate one for https
and than go trough a much harder process to get a cert for https, which is
required by webpush.

Having a single key pair - and registering it with different push providers
- seems cleaner than getting
a different Oauth (or cookie) from each server.

I'm ok with a token/cookie too - but the process to register with the push
provider needs to be specified.

Costin

---

From: Costin Manolache <[email-masked]>
Date: Mon, 1 Jun 2015 18:45:10 -0700

I should also mention that GCM (and other providers) may provide additional
features -
for example 'upstream' or 'device to device' - when the app running in the
UA may send a message
to its server using the existing webpush TCP connection. The benefit is
lower latency - the app
can obviously contact the server by making a http connection, but that
involves TCP and TLS roundtrips.
The case of device to device is even more interesting.

Assuming other providers may have those features, and there is a chance
future versions of webpush will
add some of them - it would be good if both sides are symmetrical - in
particular for end-to-end
encryption purpose, which is the trickiest part of webpush.

In this model either end has a key pair, and uses the same process to
register with the push provider,
and can use the public key as an identifier across multiple push services.

For example, server S talking to to it's app. It is possible that instances
of
app will run on different devices and UA, using different services - for
example app A1
using UA1 and WP1, and A2 using UA2 and WP2. It is also possible that
same UA may use different webpush providers.

S will generate a key pair, and use it to 'subscribe' to WP1 and WP2,
including some contact info -
like the domain name or email.

UA1 and UA2 will generate key pairs for A1 and A2, and 'subscribe' to WP1
and WP2.

This can be optional - if a webpush providers doen't need to worry about
misbehaving apps it
can just not include the public key and information about the apps. In case
of GCM, a UA
running on android will need to provide some way to identify the app (like
origin)- or use the UA's own
package name, but in the second case any misbehaving app may result in
blocking the entire
UA.

If there is a problem ( bug ) - the webpush provider can use the domain to
locate some contact
the app developer. In case of abuse - it may completely block that
particular app.

>From app developer perspective - everything has a key pair, and they may
use same libraries
to end-to-end encrypt messages between any endpoints ( S to A1, A1 to S or
A1 to A2 ). It may
even be possible for A1 to change push providers - getting a different
subscription, but using same
key pair.

Costin

On Mon, Jun 1, 2015 at 6:09 PM, Costin Manolache <[email-masked]> wrote:

> As long as the push service gets an "Authorization:" header that it can
> use to
> Having a single key pair - and registering it with different push
> providers - seems cleaner than getting

---

From: JR Conlin <[email-masked]>
Date: Wed, 3 Jun 2015 10:34:07 -0700

On 6/1/2015 6:09 PM, Costin Manolache wrote:
>
>
> On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 30 May 2015 at 14:48, Costin Manolache <[email-masked]
>     <mailto:[email-masked]>> wrote:
I'll note that this may be a bit difficult. As the current SourceForge
ruckus is showing, trusted parties may not always remain trusted. It
would be very nice to ensure that messages delivered to a user from an
app server, and not from whatever system may be holding the credentials
of the app server when talking to a bridge.

For instance, If Costin wants to send a message to Martin via my
service, that I cannot use Costin's credentials to try and send Martin
ads for my new fish based cologne service. (Feel free to add as many
other possible fishy scented parties as you like between Costin and
Martin when it comes to bridges, because they absolutely complicate things.)

> - some way to contact the sender - it can be the domain name/origin (
> and use Whois info to contact ), or
> an email. If it is valid - the sender may be contacted in case of
> problems that can be fixed, it happens
> quite often we detect some bugs and usually they get fixed in
> hours/days when we contact the sender.
> If it is not valid  or missing - the only recourse is to block the
> sender, and we may allow only low QPS.
>
> Nice to have:
> As long as the push service gets an "Authorization:" header that it
> can use to 
> The reason I'm proposing a key pair is simple: we already define this
> for app.
> In order to send a message, you need a 'subscription URL' and the
> public key generated by the UA.
> I don't see generating another key pair for the sending side as a
> major problem. Servers need to generate one for https
> and than go trough a much harder process to get a cert for https,
> which is required by webpush.
>
> I'm ok with a token/cookie too - but the process to register with the
> push provider needs to be specified.
>
> Costin
>
>
>
>
>
>
>
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush

---

From: Costin Manolache <[email-masked]>
Date: Wed, 3 Jun 2015 19:37:45 -0700

On Wed, Jun 3, 2015 at 10:34 AM, JR Conlin <[email-masked]> wrote:

> On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson <
> <[email-masked]>[email-masked]> wrote:
>
>> On 30 May 2015 at 14:48, Costin Manolache < <[email-masked]>
>> [email-masked]> wrote:
> ruckus is showing, trusted parties may not always remain trusted. It would
> be very nice to ensure that messages delivered to a user from an app
> server, and not from whatever system may be holding the credentials of the
> app server when talking to a bridge.
>

>
> For instance, If Costin wants to send a message to Martin via my service,
> that I cannot use Costin's credentials to try and send Martin ads for my
> new fish based cologne service. (Feel free to add as many other possible
> fishy scented parties as you like between Costin and Martin when it comes
> to bridges, because they absolutely complicate things.)
>

Intermediaries do complicate things - and obviously it is best if the
sender of a message is using directly the webpush service.

We're not trying to solve multi-party authentication - all we need is to
know that the message originated from a specific sender.
In email this is done by sender adding a signature header to the message,
and receiver checking it with the public key from DNS (
or something similar, I haven't looked at recent changes ). XMPP has a
different scheme, but also insures that when the final
user receives the message, the 'from' can be trusted.

I am ok with using an auth scheme where the payload is signed by the sender
key ( it already has to be encrypted using the
public key of the receiver - adding signing is not too much extra burden ).

But the end goal is for both final webpush service and for the recipient to
know for sure who originated the message.
If your webpush subscription is leaked and gets in the hand of a spammer -
it should be possible to block it.
Same if the service gets compromised.

I personally thing that a simpler scheme, using just regular JWT tokens (
with few hours expiry ) would be enough and we don't need
to sign the payload. GCM uses apikeys - similar with a cookie, but can be
changed/rotated by sender when they need to, and
seems to work well enough. The problem is that it requires the sender to
get keys(cookies) from each webpush service they may
use. What I'm proposing instead is to rely on a single key pair for sender,
and than just generate tokens and register the public key
with any webpush server that may be used. This avoids the custom sign-up to
each webpush service.

Costin

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Jun 2015 22:07:01 -0700

> know that the message originated from a specific sender.

I'm fairly sure that you don't want this, but I'd like to restate that
I'm not looking to invent a global authentication system.

> know for sure who originated the message.

I don't think that "for sure" is necessary here.  And I think that we
have to balance the confidentiality needs of the sender as well.  What
you are proposing doesn't do that, which is good.

> seems to work well enough. The problem is that it requires the sender to get
> keys(cookies) from each webpush service they may
> use.

I think that different details per origin is a positive property.
What you are describing, if it were a browser that was doing the
sending, would be called a supercookie.  That allows correlation of
sender behaviour across different origins.

Sure, this would all be under the control of a sender, and you might
argue that senders have a lesser need for this sort of privacy and you
might even be right.

But lesser isn't the same as none and I'd like to avoid situations
where we specify encouragement to do things that potentially undermine
privacy in this fashion.

I'd like to hold this design to the same sorts of standards we hold
the rest of the web to.  Or better yet, our aspirational goals for the
web.  Particularly when it comes to privacy.

I have no fundamental objection to having a sender volunteer extra
information, like a support email address, but that needs to be at
their discretion.

I keep coming back to a simple cookie.  I'd also be OK with the push
service sending back a full-blown web page with a registration form to
newcomers where additional information might be volunteered.  Though
maybe that should be limited to those senders that include HTML in
their Accept header fields.

> What I'm proposing instead is to rely on a single key pair for sender,

I certainly agree with the general idea, but cutting this down to
something that might deploy is my main concern.  JWT is nice, but it's
more complex than I think we need.

(Also, if we use cookies, there's this nice anti-cookie-stealing
technology being developed in the tokbind WG.  If we use cookies, we
would need to generate good guidance about scope, because cookies are
a bit of a mess.)

---

From: Costin Manolache <[email-masked]>
Date: Thu, 4 Jun 2015 11:57:48 -0700

> I'm not looking to invent a global authentication system.

Nobody is looking to invent authentication systems - just use or adapt what
is already
well known, and learn/reuse from other messaging systems.

> you are proposing doesn't do that, which is good.

We may need to break things down:

- a receiver should know for sure who sent the message, and there is zero
confidentiality
expectation here - if someone sends you a message, you should know who sent
it
and be sure that it is verified. ( at least in the case of UA that use
webpush services that
use sender authentication ).

- each webpush service can decide what policies it needs. There are still
'open relay' SMTP
servers, but it is also common for SMTP servers to reject messages where
the source can't be
verified.

Pretty much all I'm discussing should be considered in perspective of SMTP
experience, which
IMHO has many things in common with webpush.

> get

Going back to your comment about inventing things :-), I don't think we
should focus on
inventing a new privacy model.

The web is starting to insist on verifying the domain name of the origin (
i.e. who sends data to
your app ) - the same should be true on webpush.

> information, like a support email address, but that needs to be at

Just like it is at the discretion of a webpush service to accept or not to
forward messages, or
what policy to apply. As is the case in SMTP.

We may allow messages from un-identifiable senders, but at  low QPS and
with additional
restrictions.

> their Accept header fields.

I'm not sure what you mean by 'cookie' in this context - but as I mentioned
we have used a token
without major problems.

However the registration form doesn't scale - and it is considered painful.

Why would it be a problem to standardize the fields and registration - we
can use the same
kind of info that is  typically present in a HTTPS certificate, or JWT
token, or whois record.

It would be ok for webpush providers to include additional URL for extra
signup if needed, but
for the common case it will be better to automate the process.

There is also the option to adapt what SMTP or XMPP are doing - and
identify the sender
using the domain name, but I think it's too complicated.

> more complex than I think we need.

How about:
- first time you talk with a webpush ( identified by the domain in the
capability subscription URL ), you need
to grab an opaque string ( cookie/token), and use it in subsequent requests
- to grab the opaque string, you need to call the subscribe URL, and
include a set of optional
information.
- the initial request will use the private key of the sender to sign the
request - and the public key of the
sender will be included.

If you go with HTML form - it will still eventually need to result in some
way to prevent a sender impersonating
another one.

I suspect any webpush service that uses sender authentication will want to
provide the authenticated
identity of the sender to the UA and client app - so whatever identifier is
seen by the client must be
trusted. I'm proposing the public key of the sender because there are many
ways to verify it without
manual work. If you use a form - than it gets into verifying domain or
email ownership, and can get as hard
as getting a https cert.

> would need to generate good guidance about scope, because cookies are

If you have any more detailed description on what cookie means in this
context - please include it, I see it
as an opaque string with some rules about origin - but the rules are only
enforced in the context of a browser
AFAIK.

Costin

---

From: Paul Em <[email-masked]>
Date: Sun, 7 Jun 2015 18:08:51 +0200

So if we are not inventing some global system, then we cannot have a common
generic authentication.
Correct me if I am wrong, but I can't think of a system where you have a
token, no manual work and no global system.

I would also leave the possibility open for the push server to reject
pushes after a certain quota (or even at first one?) and include a link to
authenticate in the error description. You would have to register and get a
token you can include in the requests for this endpoint.

2015-06-04 20:57 GMT+02:00 Costin Manolache <[email-masked]>:

> Nobody is looking to invent authentication systems - just use or adapt
> what is already

> expectation here - if someone sends you a message, you should know who
> sent it
> I'm not sure what you mean by 'cookie' in this context - but as I
> mentioned we have used a token
> without major problems.
>
> identity of the sender to the UA and client app - so whatever identifier
> is seen by the client must be

---

From: Costin Manolache <[email-masked]>
Date: Sun, 7 Jun 2015 13:44:37 -0700

On Sun, Jun 7, 2015 at 9:08 AM, Paul Em <[email-masked]> wrote:

> So if we are not inventing some global system, then we cannot have a
> common generic authentication.
>

Not inventing a global authentication system - maybe adapting existing ones
a bit :-)

But we are defining a 'subscribe' or registration protocol - one is
required for apps and UAs to register with the push
service. I'm just suggesting to extend it a bit, and use it symmetrically
for all entities - i.e. including senders.

We also require use of asymmetric keys for receivers - we can use them on
the senders as well, for the purpose
of signing/identification.

> token, no manual work and no global system.

I'm trying to avoid manual work, where each sender has to register (fill
forms) for each push provider.

The system is global in the sense that a sender can work with any push
service that requires sender authentication
and is free or has some free quota.

There are few systems that allow registration of public keys with key
servers - as well as systems that use private keys
for authentication. Or as result of registration we can return regular
tokens/cookies.

The main point of my proposal is to use the public key of the sender as
'identifier' that is verified at each send ( using
either the private key or some tokens/cookies returned after verifying the
private key ).

Any other alternative I know would require some manual work to prove that
the identity is the same to different
push providers. For example - domain name / origin would require either
some certificate ( I hope nobody wants to
go there ), or other proof of ownership, plus some forms to fill manually,
since this is hard to automate.

> token you can include in the requests for this endpoint.

Agreed - result of subscribe should include an optional link. But I think
we should add this for both registering senders and
registering UAs. The current draft assumes that the UA can just register
automatically, with no extra user intervention.

Costin

>> On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson <[email-masked]
>> > wrote:
>>
>> Pretty much all I'm discussing should be considered in perspective of
>> SMTP experience, which
>> The web is starting to insist on verifying the domain name of the origin
>> ( i.e. who sends data to
>> Just like it is at the discretion of a webpush service to accept or not
>> to forward messages, or
>> If you go with HTML form - it will still eventually need to result in
>> some way to prevent a sender impersonating
>> another one.
>>
>> I suspect any webpush service that uses sender authentication will want
>> to provide the authenticated
>> trusted. I'm proposing the public key of the sender because there are
>> many ways to verify it without

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jun 2015 11:56:54 -0700

Trimming aggressively.  Let me know if I missed something.

> use sender authentication ).

This is a guarantee that the web does not provide, because it has
negative privacy consequences.  So I guess I'm challenging your
assertion about confidentiality.

Think about it this way: If I send you a message, I might want my
identity to remain hidden from the service that you use.  That way I
am at least partially insulated to some extent from the choices that
you have made.

This is not the same as your email server authenticating your MTA,
it's more correctly analogous to Google being able to authenticate
every email sent to a gmail account.  As I understand it,
authentication is an important part of anti-spam, but not the only
criterion.

> We may allow messages from un-identifiable senders, but at  low QPS and with
> additional restrictions.

As I would expect :)

> for the common case it will be better to automate the process.

I have no fundamental objection to automating the provision of extra
information, but automation requires standardizing and I'm leery of
doing more standardizing than necessary, at least initially.  I'd
rather remove as much as possible from the critical path.

> - to grab the opaque string, you need to call the subscribe URL, and include
> a set of optional
> information.

I was thinking that you sent a push, received a cookie in return and a
link to a registration resource, or - if you like - links to automated
and/or manual forms.  You could replay the cookie to receive whatever
benefits might be accrued to that cookie, either by establishing a
reputation as a good actor over time, or by providing extra
information.

> identity of the sender to the UA and client app

It would be better for the sender to authenticate themselves with the
application/UA directly.

> context -

RFC 6265.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 8 Jun 2015 13:07:32 -0700

On Mon, Jun 8, 2015 at 11:56 AM, Martin Thomson <[email-masked]>
wrote:

> sent

Not sure what you mean - https on the web
1. doesn't provide any confidentiality on the origin ( at least if SNI is
used - domain is visible to
transport provider and anyone in between).
2. requires that UA will verify the origin of the content it shows to the
user.

And the current internet does provide this kind of verification in a lot of
messaging cases.
The reason I keep mentioning SMTP is that it's the only one I know where
the origin of
the content can be easily forged ( with well-known consequence ), I don't
have
other good examples.

The choice to get content only from verified sources is present on the web
as well: some services
only support https  for example ( which does verify the origin ).

In my view webpush originated content is as important as site-originated
content in the page, having
parts of the page from unverified sources (mixed content) is not ideal.

> am at least partially insulated to some extent from the choices that

As I mentioned - accepting untrusted content is a choice, as it is in SMTP.

> authentication is an important part of anti-spam, but not the only

Yes, because SMTP was designed like current webpush :-) - without
consideration
for verifying the identity of the sender of a message, instead assuming
that the
'capability URL' that allows sending ( email address in case of SMTP ) will
be
kept confidential and only provided to trusted senders.

> with
We may do this in a separate document - the only alternative is developers
having
to manually register to each push provider that requires verification.

If it turns out that only very few push services have this requirement - it
may not be a huge problem, and
maybe the automated registration can be just a way to improve developer
experience
for those providers.

> include

But the UA and app on the client will still have no way to know who sent
the message.

Just that the sender has some good reputation - like it's done now in SMTP
( based on
IP / etc ).

Using a key pair - and the equivalent of a CSR - would allow the webpush
provider
to identify the public key of the sender to the UA and app, and that would
work consistently
for an app - regardless of which webpush provider is used.
Of course - if a webpush provider choses 'open relay / anonymous sender' -
there would be
no 'from' field provided.

> It would be better for the sender to authenticate themselves with the

That may be possible - for example by signing the content - but still
doesn't
address the issue of webpush providers managing their network, and adds
more complexity on the send side.

What would be the benefit of using different ways to authenticate the
sender - one
to client app, a different one to webpush provider ?

> > If you have any more detailed description on what cookie means in this

AFAIK this is for a UA like browsers, not for distributed senders (100s of
machines in different
zones making API requests on behalf of a sender). Typically Authorization
is used for that, I'm not
aware of many server side APIs using regular cookies for auth.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jun 2015 13:21:32 -0700

> 2. requires that UA will verify the origin of the content it shows to the

You are talking about authenticating servers.  I was thinking about
clients.  Thinking of the sender/application server as a client of the
push service, that is.

> parts of the page from unverified sources (mixed content) is not ideal.

The current model treats it no differently to data that comes across a
WebRTC data channel.  That might be a mistake, and I'm certainly happy
to talk about better authentication.  I had hoped to add that at a
later stage.

Either way, I wouldn't want the push service having access to origin
information without the origin choosing to add that information.

> But the UA and app on the client will still have no way to know who sent the
> message.

That's a separate - and separable - problem.

> What would be the benefit of using different ways to authenticate the sender
> - one

Privacy for one.

> zones making API requests on behalf of a sender). Typically Authorization is
> used for that, I'm not

A shared cookie jar isn't unheard of.  Though people do like to invent
new authentication schemes.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 8 Jun 2015 23:09:10 -0700

> clients.  Thinking of the sender/application server as a client of the

I'm talking about the 'application server' - typically the same with the
https origin, where apps running in the UA send their subscription.
I wouldn't call it 'client'.

> to talk about better authentication.  I had hoped to add that at a

I'm not very familiar with WebRTC - does it now include any part where you
would get rings or messages from unidentified sources ?

> information without the origin choosing to add that information.

I don't think it is feasible to run a service where servers generating
1000s of QPS
of messages are unidentifiable to the network operator.

> the

> sender

I think inventing a mechanism that provides privacy for servers is very
hard - a webpush
service can still use the IP address (which typically is registered for
large senders).
Many protocols require contact information for the server operator ( domain
registration,
certificates ).

> new authentication schemes.

Actually - I never heard of any shared cookie jar that would operate well
in a distributed
server environment. How would Set-Cookie be implemented if you have senders
in different continents, with high latency between them ?

RFC 6265 defines 'distributed state management' - it is not actually
defining authentication or
identity schemes. HTTP defines "Authorization" header for authentication,
but I would agree
people like to invent new authentication schemes.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Jun 2015 10:18:50 -0700

> I wouldn't call it 'client'.

I too was talking about the application server.  And it is absolutely
a client in this context.

> would get rings or messages from unidentified sources ?

Yes.  Unless you are able to use the extra authentication piece (which
only Firefox currently implements).

> I don't think it is feasible to run a service where servers generating 1000s
> of QPS

Make no mistake, I have no illusions about that sort of case needing
authentication.  And at higher numbers, exceptions have to be made.  I
was expecting that to be exceptional though.

> I think inventing a mechanism that provides privacy for servers is very hard

I always imagined that pushes could come from anywhere, not just the
machine that serves the front-end for a site. The opposite in fact, I
would expect that pushes will come from elsewhere, like the back-end
that is reacting to the event as it happens. If pushes are originating
from (for example) somewhere in Amazon's cloud, that's going to give
the server pretty good anonymity. At least without asking Amazon to
trace the IP, anyway.

> Actually - I never heard of any shared cookie jar that would operate well in
> a distributed

Like any other piece of shared state.  I wouldn't imagine that it
would be any harder than sharing a key, or any other common
authentication information.

---

From: Costin Manolache <[email-masked]>
Date: Tue, 9 Jun 2015 11:43:35 -0700

> a client in this context.

Then let's avoid using 'client' and 'server'.

How about 'origin' or "machine operated by application developer' (the app
server can be operated by
another organization - but it is the decision of the app developer on where
he will send/share the capability
URL)

To be clear: if the message is sent by a user - in case of 'device to
device' for example, which webpush
doesn't cover - I wouldn't expect any identifiable information about the
user. We'll still need to
identify the sender ( so a response can be sent for example ) - and we
still need this to be verified, to avoid
abuse. This is a separate issue, no point talking too much about it.

While both regular users and web site developer initiate client http
connections to webpush service -
there are still some differences between a company/organization and an end
user.

> only Firefox currently implements).

I'll read about it - do you have any pointers ? I see they have a section
on identity - and it
doesn't seem to require that UA/apps accepts un-identified messages.

I can't find any definition of a new signaling mechanism - which would be
the equivalent of
webpush, what I found still references SIP or XMPP - which both identity
and check the sender.

> 1000s

I don't know what other webpush operators will do - my strong requirement
is to have a verifiable identity for the sender - can be a random number.
I would also like to see a definition of optional contact elements (email
or domain)
- but I think we may accept at least low QPS without contact info.
Current GCM requires an dev account which requires an email - so far in the
cases
we had to contact the developers we didn't run into problems finding them.

For very high numbers it's probably less important - there are more
channels of communication with large developers, and they're more likely
to contact the webpush service first. Which reminds me that we should also
define some link to a webpush contact info.

> hard

See above - pushes could come from any machine operated or delegated
by the organization controlling the 'origin', not only the frontend.

Requests 'coming from anywhere' are the root problem I'm trying to solve
:-),
if the capability URL gets out of machines operated by the developer, like
it
happens to email addresses.

> authentication information.

In many authentication schemes each machine ( or region ) can get or
generate it's own
tokens - without requiring consistency or synchronization with other
regions.
And since you mentioned we don't want to invent new authentication -
cookies are not
typically an authentication mechanism ( they are just used to track
sessions that are used by
various auth schemes ).

Costin