Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Wed, Jan 6, 2016 at 1:16 AM, Martin Thomson <[e-mail]>
wrote:

> 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.
>

At the same time you can't force push service providers to accept
 unauthenticated/unauthorized sending either. Or require them to
provide unlimited (and free) service to everyone regardless of how much
they're abusing/hurting users or networks.



> > 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.
>

How about 2.1 AND 2.3 ? Push servers should support both, clients should
use what they can.

I think there are some benefits in 2.1.



>
> > -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.
>

And it may be the way to allow the choice on app server side - either by
having an 'isAuthorizationRequired()' or an error code when attempting to
subscribe without a public key.

If they subscribe without the sender id, than on some push services send
will fail - and they can't do anything about it.



>
> > 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.
>

Of course, you have the choice and I'm very curious to know how it works,
but based on our experience we are not ready to make the same choice :-)

I'm personally ok to not require contact info ( with understanding that if
it is missing
the sender accepts some limitations ). Unfortunately it's not my choice,
people who
support the service may have a different opinion, and each service provider
may
make a choice or another.

However authorization and authentication are a different story than contact
info.

Costin