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