Note: This ballot was opened for revision 03 and is now closed.
Thanks for addressing my DISCUSS and COMMENT points.
*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.
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.
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?
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?
UPDATED: I still think this is the wrong design but I'm persuaded that it's not worth sending it back to the WG. Abstract 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 convention. 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.