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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Aug 2017 12:55:24 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-webpush-vapid-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The following is a nit, but I think it is important that it gets fixed:

In Section 4.1:

   The example in Figure 3 shows a restriction to the key used in
   Figure 1.  Extra whitespace is added to meet formatting constraints.

   POST /subscribe/ HTTP/1.1
   Host: push.example.net
   Content-Type: application/webpush-optjons+json;charset=utf-8

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?

   Content-Length: 104

   { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
               F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Phil Sorber <[email-masked]>
Date: Tue, 01 Aug 2017 20:34:31 +0000

For sure the first discuss item has already been addressed in the git repo
[1], and there is also a statement that the JSON is UTF-8 encoded now as
well. I'm not sure that really resolves the second point though. I'll let
the authors address that directly.

Martin, Peter, perhaps this is a good opportunity to push a new draft
before the telechat?

[1]
https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Aug 2017 10:14:09 +1000

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

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

---

From: Phil Sorber <[email-masked]>
Date: Mon, 14 Aug 2017 21:40:41 +0000

Alexey,

It appears that two of the three issues were addressed with changes to the
spec. Do you find those changes as well as Martin's explanation of the
third point satisfactory? If not, is there some more concrete changes that
you would like to see?

Thanks.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Aug 2017 10:36:55 +0100

> c867529 on GitHub.  I'll push a new version at Adam's instruction.

I prefer a new draft.

What is the URL for the github? I couldn't find it on a quick glance.

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

---

From: Phil Sorber <[email-masked]>
Date: Tue, 15 Aug 2017 15:40:59 +0000

> > c867529 on GitHub.  I'll push a new version at Adam's instruction.

Understood. The plan is to do that right after the telechat.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Aug 2017 18:10:28 +0100

On Tue, Aug 15, 2017, at 04:40 PM, Phil Sorber wrote:
> On Tue, Aug 15, 2017 at 3:37 AM Alexey Melnikov
> <[email-masked]> wrote:>> On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote:
>>  > On 2 August 2017 at 05:55, Alexey Melnikov
>>  > <[email-masked]>>>  > 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?
>>  >
>>  > c867529 on GitHub.  I'll push a new version at Adam's instruction.>> 
>>  I prefer a new draft.
> 
>> What is the URL for the github? I couldn't find it on a quick glance.>> 
> 
> This is the repo:
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.
>> 
>>  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.