Re: [Webpush] Application server authentication new years edition

[Martin Thomson <[e-mail]>]

On 6 January 2016 at 15:55, Costin Manolache <[e-mail]> wrote:
> It is important to define what "voluntary" means :-). My understanding is
> that it involves
> a choice made by an entity, either the app server and push service.

I hope that the draft makes it clear enough: "voluntary" refers to the
choice at the app server whether to provide this information.

> The only 'voluntary' choice an app server has is to not use
> a push service and UAs that requires authentication/authorization.

Right, and I don't think that this is a choice we want to force people
into making.  That has some fairly dire market effects.

> For authentication:  2.1(certificate) would be my preference, and is a well
> known and established
> mechanism, followed by 2.6, 2.3.

Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
connection.  Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.  JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.

> -2.4 doesn't cover authentication,
> -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know the
> outcome)

I agree.  We don't really know how to solve the signing problem, and
not from a lack of trying.

> -2.2 is what we use now, but doesn't work well with 3. - subscription
> association - if
> public keys are used.
>
> For authorization - or "subscription association" - big +1 :-)

Yeah, I like the subscription association feature too.  I think that
it's an important consideration in choosing a mechanism.

> For contact - each of the authentication schemes in the draft provide a way
> to include contact info, and
> the choice for senders is to include it or not, and the choice for push
> services is to throttle/reject
>  or not. The tricky part is if any additional verification will be done by
> push services.
> I guess some providers (in particular free services) may be ok with a more
> relaxed verification
> or even allow some rate-limited sending without contact info, I personally
> don't mind it - if we
> can't contact a sender in case of problems we just block it.

That's the policy that we've discussed having.  I think that it is
very important to allow requests from all comers, even without
authentication.  Of course, services should be prepared to cut off
those unauthenticated requests very quickly as load increases.