webpush-wg / webpush-vapid Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For @ekr #43
For @ekr #43
Conversation
| It's not shouting, when they are capitalized, they have the special meaning | ||
| described in {{!RFC2119}}. | ||
| When they are capitalized, they have the special meaning described in | ||
| {{!RFC2119}}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just cite RFC 8174
| 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. | ||
| Additionally, the design of RFC 8030 relies on maintaining the secrecy of push |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should RFC 8030 be a reference?
| request for push message delivery MUST include proof of possession for the | ||
| associated private key that was used when creating the push subscription. | ||
| request for push message delivery MUST include a JWT signed by the private key | ||
| that was used when creating the push subscription. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it correct to refer to the private key that was used to create the subscription, when that is done using a public key that was derived from the private key?
What about:
When a push subscription has been restricted to an application server, the
request for push message delivery MUST include a valid JWT signed by the
private key paired with the public key used when creating the push subscription.
|
Merged manually after resolving conflicts. |
This doesn't address the suggested alternative design.