Voluntary Application Server Identification (VAPID) for Web Push
RFC 8292

Note: This ballot was opened for revision 03 and is now closed.

(Ben Campbell) (was Discuss) Yes

Comment (2017-08-16 for -03)
No email
send info
Thanks for addressing my DISCUSS and COMMENT points.

(Adam Roach) Yes

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-08-15 for -03)
No email
send info
*Very* minor nits:

1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of which have Martin Thomson as an author) -- these use different capitalizations for many terms, for example "user agent" vs "User Agent" -- this document references RFC8030, which has  these lower-case, and so I suspect that it is draft-ietf-webpush-encryption which should change, but I figured I'm mention it here as well.

2: Section 7. Acknowledgements
"This document would have been much worse than it currently is if not for the contributions ..."
Once published as an RFC, it is cast in stone. I support your the above, but think you should remove "currently", so perhaps:
"This document would have been much worse if not for the contributions ..."

Again, these are tiny nits, I don't have enough knowledge of the topic to make more useful comments :-P

Edited: Sorry, managed to click submit before thanking Stefan Winter for his OpsDir review, and the authors for addressing them.

(Mirja Kühlewind) No Objection

Comment (2017-08-15 for -03)
No email
send info
Wondering if the new registry in section 6.2 is really needed. Is it expected that new parameters show up any time soon? For me this doc reads like that's the only two parameter you actually need.

(Alexey Melnikov) (was Discuss) No Objection

Comment (2017-08-15 for -03)
No email
send info
I have cleared my DISCUSS based on changes in git.

I am looking forward to continuing discussion about advertising support for the "vapid" authentication scheme in WWW-Authenticate:

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?

(Kathleen Moriarty) No Objection

Comment (2017-08-15 for -03)
No email
send info
Thanks for your work on this draft.

In section 3, it seems that you are just signing the JWK and that seems fine from the text and the purpose listed - origin server authentication.

Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, "An application server MUST select a different
   private key for the key exchange".  This makes me think that encryption is used as well, but I think it would be helpful to see the point made more clear here or in the security considerations section.  Is confidentiality provided/required or just integrity for this draft?

(Eric Rescorla) (was Discuss) No Objection

Comment (2017-10-11)
No email
send info
UPDATED: I still think this is the wrong design but I'm persuaded that it's
not worth sending it back to the WG.

   This identification information can be used to restrict the use of a
   push subscription a single application server.

to a single

S 1.
   Additionally, this design also relies on endpoint secrecy as any
   application server in possession of the endpoint is able to send
   messages, albeit without payloads.  In situations where usage of a
   subscription can be limited to a single application server, the
   ability to associate a subscription with the application server could
   reduce the impact of a data leak.

I don't understand this text.

S 1.2
   The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
   document.  It’s not shouting, when they are capitalized, they have
   the special meaning described in [RFC2119].

This seems over-cute. We now have a document that describes this

S 2.
   This JWT is included in an Authorization header field, using an auth-
   scheme of "vapid".  A push service MAY reject a request with a 403
   (Forbidden) status code [RFC7235] if the JWT signature or its claims
   are invalid.

Given that "vapid" is tied to "P-256" it seems like it would be better
to rename this "vapid-p256"

S 4.2.
   When a push subscription has been associated with an application
   server, the request for push message delivery MUST include proof of
   possession for the associated private key that was used when creating
   the push subscription.

This really isn't a proof of possession, as the Security Considerations
makes clear.

S 5.
You should call out that the email address is just a bare assertion.