Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

On Tue, Aug 15, 2017, at 04:40 PM, Phil Sorber wrote:
> On Tue, Aug 15, 2017 at 3:37 AM Alexey Melnikov
> <[e-mail]> wrote:>> On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote:
>>  > On 2 August 2017 at 05:55, Alexey Melnikov
>>  > <[e-mail]>>>  > wrote:
>>  > > Firstly, "optjons" above should be "options". Secondly, the MIME
>>  > > type>>  > > registration of application/webpush-options+json says that the
>>  > > MIME type has no>>  > > parameters, yet you use charset above. So which is it?
>>  >
>>  > As Phil notes, the first was corrected already, the second is in
>>  > c867529 on GitHub.  I'll push a new version at Adam's instruction.>> 
>>  I prefer a new draft.
> 
> Understood. The plan is to do that right after the telechat.
>  
>>  
>> What is the URL for the github? I couldn't find it on a quick glance.>> 
> 
> This is the repo:
> https://github.com/webpush-wg/webpush-vapid
> 
> This is a diff of the last draft to current master:
> https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master
I can clear my DISCUSS based on these changes.

>  
>> > > In Section 3, 3rd para:
>>  > >
>>  > >    This authentication scheme does not require a challenge.
>>  > >    Clients are>>  > >    able to generate the Authorization header field without any
>>  > >    additional information from a server.  Therefore, a challenge
>>  > >    for>>  > >    this authentication scheme MUST NOT be sent in a WWW-
>>  > >    Authenticate>>  > >    header field.
>>  > >
>>  > > Does this mean that there is no way to discover whether a
>>  > > particular server>>  > > supports "vapid" HTTP authentication scheme?
>>  >
>>  > Not directly.  There was a plan to expose this via the User
>>  > Agent, but>>  > we didn't reach a conclusion:
>>  > https://github.com/w3c/push-api/pull/262>>  >
>>  > Another document could override this as well, I suppose.  The
>>  > "MUST>>  > NOT" exists primarily because we don't define a challenge.
>> 
>>  I think all authentication schemes should be discoverable in
>>  WWW-Authenticate, as it is a part of HTTP authentication framework.>> 
>>  I think it would be good to clarify whether inclusion of "vapid" in>>  WWW-Authenticate without a challenge is allowed. The way your
>>  MUST NOT>>  is worded makes me think that this is something that a server
>>  implementor can do accidentally. As there is no challenge data,
>>  I don't>>  see how this can happen anyway.