rfc9749xml2.original.xml   rfc9749.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.
3.6) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY RFC8620 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
20.xml">
<!ENTITY RFC8030 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
30.xml">
<!ENTITY RFC8292 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
92.xml">
<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml">
<!ENTITY RFC7515 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
15.xml">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-jmap-webpush-vapid-10" category="std" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
consensus="true" submissionType="IETF"> -ietf-jmap-webpush-vapid-10" number="9749" category="std" consensus="true" submi
<front> ssionType="IETF" version="3" xml:lang="en" tocInclude="true" updates="" obsolete
<title>Use of VAPID in JMAP WebPush</title> s="" symRefs="true">
<!-- [rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.
Original:
Use of VAPID in JMAP WebPush
Current:
Use of Voluntary Application Server Identification (VAPID) in JSON Meta
Application Protocol (JMAP) WebPush
-->
<front>
<title abbrev="Use of VAPID in JMAP WebPush">Use of Voluntary Application Se
rver Identification (VAPID) in JSON Meta Application Protocol (JMAP) WebPush</ti
tle>
<seriesInfo name="RFC" value="9749"/>
<author initials="D." surname="Gultsch" fullname="Daniel Gultsch"> <author initials="D." surname="Gultsch" fullname="Daniel Gultsch">
<organization></organization>
<address> <address>
<email>daniel@gultsch.de</email> <email>daniel@gultsch.de</email>
</address> </address>
</author> </author>
<date year="2025" month="March"/>
<area>ART</area>
<workgroup>jmap</workgroup>
<date year="2025" month="January" day="10"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>Internet</area> <keyword>example</keyword>
<workgroup>JMAP</workgroup>
<abstract> <abstract>
<t>This document defines a method for JSON Meta Application Protocol (JMAP
) servers to advertise their
capability to authenticate WebPush notifications using the Voluntary
Application Server Identification (VAPID) protocol.</t>
</abstract>
</front>
<middle>
<?line 45?> <section anchor="introduction">
<name>Introduction</name>
<t>This document defines a method for JMAP servers to advertise their capability to authenticate WebPush notifications using the Voluntary Application Server Id entification protocol.</t> <!-- [rfced] Will readers understand what "it" refers to here?
</abstract> Original:
To facilitate that, the
client (or user agent in WebPush terminology) needs the VAPID public
key of the application server to pass it along to the push service
when retrieving a new endpoint.
</front> Perhaps (remove "it"):
To facilitate that, the
client (or user agent in WebPush terminology) needs the VAPID public
key of the application server to pass along to the push service
when retrieving a new endpoint.
<middle> Or (recast sentence):
To facilitate that, the
client (or user agent in WebPush terminology) needs to pass along
the VAPID public key of the application server to the push service
when retrieving a new endpoint.
-->
<?line 49?> <t>JMAP <xref target="RFC8620"/> specifies how clients can subscribe to ev
ents using a protocol that is compatible with WebPush <xref target="RFC8030"/>.
Some push services require that the application server authenticate all push mes
sages using the VAPID protocol <xref target="RFC8292"/>. To facilitate that, the
client (or user agent in WebPush terminology) needs the VAPID public key of the
application server to pass it along to the push service when retrieving a new e
ndpoint.</t>
</section>
<section anchor="conventions-used-in-this-document">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section anchor="discovering-support-for-vapid">
<name>Discovering Support for VAPID</name>
<t>The JMAP capabilities object is returned as part of the standard JMAP s
ession object (see <xref section="2" sectionFormat="of" target="RFC8620"/>). Ser
vers supporting this specification <bcp14>MUST</bcp14> add a property called "ur
n:ietf:params:jmap:webpush-vapid" to the capabilities object. The value of this
property is an object that <bcp14>MUST</bcp14> contain the following information
:</t>
<section anchor="introduction"><name>Introduction</name> <ul spacing="normal">
<li>
<t>applicationServerKey: "String"</t>
<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) public key t
hat the push service will use to
authenticate the application server, in its uncompressed form (as
described in Annex A of <xref target="X9.62"/>) and encoded using
base64url encoding <xref target="RFC7515"/>. Current systems use the
P-256 curve <xref target="FIPS186"/>.</t>
</li>
</ul>
<t>JMAP <xref target="RFC8620"/> specifies how clients can subscribe to events u <t>Informative Note: The format of the application server key was chosen t
sing a protocol that is compatible with WebPush <xref target="RFC8030"/>. Some p o ensure compatibility with the browser API (Section 7.2 of <xref target="PUSH-A
ush services require that the application server authenticates all push messages PI"/>), allowing the key to be directly copied and used without additional trans
using the Voluntary Application Server Identification protocol <xref target="RF formation. Additionally, as noted in <xref section="3.2" sectionFormat="of" targ
C8292"/>. To facilitate that, the client (or user agent in WebPush terminology) et="RFC8292"/>, the X9.62 encoding simplifies key comparisons and is more compac
needs the VAPID public key of the application server to pass it along to the pus t than alternative formats.</t>
h service when retrieving a new endpoint.</t> </section>
<section anchor="issuing-push-notifications">
<name>Issuing Push Notifications</name>
<t>Every time the server sends a push message to a PushSubscription URL, i
t <bcp14>MUST</bcp14> authenticate the POST request using the protocol outlined
in <xref target="RFC8292"/>. This includes both StateChange events and PushVerif
ication notifications. To authenticate the request, the server <bcp14>MUST</bcp1
4> use a JSON Web Token (JWT) signed by the private key corresponding to the app
lication server key. This application server key <bcp14>MUST</bcp14> be the one
that was advertised in the capabilities object at the time the PushSubscription
was created.</t>
</section>
<section anchor="key-rotation">
<name>Key Rotation</name>
<t>When a server needs to replace its VAPID key, it <bcp14>MUST</bcp14> up
date the sessionState per <xref target="RFC8620"/>. The client <bcp14>MUST</bcp1
4> monitor the JMAP session object for changes to the VAPID key and <bcp14>MUST<
/bcp14> recreate its push subscription when it detects such a change.</t>
<t>After key rotation, the server <bcp14>MAY</bcp14> continue to send push
notifications for existing push subscriptions using the old application server
key for a transitional period. This allows clients time to recreate their respec
tive push subscriptions. At the end of the transitional period (or immediately f
or implementations that do not have one), the server <bcp14>MUST</bcp14> destroy
push subscriptions that use the old key.</t>
<t>When destroying push subscriptions that include the data type <tt>PushS
ubscription</tt>, the server <bcp14>MAY</bcp14> issue one final StateChange push
notification using the old URL and application server key to notify the client
of changes to the PushSubscription data type. This prompts the client to make a
<tt>PushSubscription/changes</tt> method call. The response to this call will co
ntain an updated sessionState, which refers to a session object that contains th
e new VAPID key.</t>
</section> <!-- [rfced] FYI - We updated these sentences as follows (pointed to Section
<section anchor="conventions-used-in-this-document"><name>Conventions Used in Th 4.2 of [RFC8292] in both and updated phrasing relating to the status code
is Document</name> to be consistent). Let us know any concerns.
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL Original:
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", Consequently, the push
"MAY", and "OPTIONAL" in this document are to be interpreted as service will reject the PushVerification with a 403 (Forbidden)
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and status code, as specified in [RFC8292].
only when, they ...
appear in all capitals, as shown here. This mismatch leads to the push service rejecting the
These words may also appear in this document in PushVerification request with HTTP status code 403, as specified in
lower case as plain English words, absent their normative meanings. [RFC8292], Section 4.2.
<?line -8?></t>
</section> Updated:
<section anchor="discovering-support-for-vapid"><name>Discovering Support for VA Consequently, the push
PID</name> service will reject the PushVerification with a 403 (Forbidden)
status code, as specified in Section 4.2 of [RFC8292].
...
This mismatch leads to the push service rejecting the
PushVerification request with a 403 (Forbidden) status code, as specified in
Section 4.2 of [RFC8292].
-->
<t>The JMAP capabilities object is returned as part of the standard JMAP session <t>A race condition can occur when the server updates its VAPID key after
object (see Section 2 of <xref target="RFC8620"/>). Servers supporting this spe the client has refreshed the session object but before calling the PushSubscript
cification MUST add a property called "urn:ietf:params:jmap:webpush-vapid" to th ion/set method. This situation causes the server to send a PushVerification obje
e capabilities object. The value of this property is an object that MUST contain ct to a push resource URL that is now associated with an outdated VAPID key. Con
the following information:</t> sequently, the push service will reject the PushVerification with a 403 (Forbidd
en) status code, as specified in <xref section="4.2" sectionFormat="of" target="
RFC8292"/>.</t>
<t>To alleviate this problem, the client <bcp14>MUST</bcp14> check if the
sessionState in the response from the PushSubscription/set method points to a se
ssion object with an applicationServerKey that matches their expectations. If th
ere is a mismatch, the client <bcp14>MAY</bcp14> retry creating the PushSubscrip
tion. Additionally, the client <bcp14>MAY</bcp14> destroy the PushSubscription f
rom the earlier, failed attempt.</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>During the key rotation process, synchronization issues between the cli
ent and server may arise. Specifically, a client might restrict a push subscript
ion with the push service to an outdated key, while the server sends the PushVer
ification object authenticated with the newly rotated key. This mismatch leads t
o the push service rejecting the PushVerification request with a 403 (Forbidden)
status code, as specified in <xref section="4.2" sectionFormat="of" target="RFC
8292"/>.</t>
<t>Per the requirements of <xref section="7.2" sectionFormat="of" target="
RFC8620"/>, the server <bcp14>MUST NOT</bcp14> retry the rejected PushVerificati
on request. Consequently, the PushVerification object will not be delivered to t
he client.</t>
<t>To mitigate such issues, the client is responsible for detecting and re
solving any synchronization discrepancies, as outlined in <xref target="key-rota
tion"/> of this document.</t>
<t>The inclusion of the <tt>urn:ietf:params:jmap:webpush-vapid</tt> proper
ty in the JMAP capabilities object is limited to providing information about the
server's support for VAPID. This property does not reveal sensitive information
, nor does it introduce new security or privacy risks beyond those inherent to J
MAP and WebPush. The security considerations for JMAP <xref target="RFC8620"/> (
especially Sections <xref section="8.6" sectionFormat="bare" target="RFC8620"/>
and <xref section="8.7" sectionFormat="bare" target="RFC8620"/>), WebPush <xref
target="RFC8030"/>, and VAPID <xref target="RFC8292"/> apply to this document.</
t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<section anchor="registration-of-the-jmap-capability-for-vapid">
<name>Registration of the JMAP Capability for VAPID</name>
<t>IANA has registered the following new capability in the "JMAP Capabil
ities" registry:</t>
<t><list style="symbols"> <dl spacing="compact" newline="false">
<t>applicationServerKey: "String" <vspace blankLines='1'/> <dt>Capability Name:</dt><dd><tt>urn:ietf:params:jmap:webpush-vapid</t
The ECDSA public key that the push service will use to authenticate the applicat t></dd>
ion server, in its uncompressed form (as described in <xref target="X9.62"/> Ann <dt>Intended Use:</dt><dd>common</dd>
ex A) and encoded using base64url encoding <xref target="RFC7515"/>. Current sys <dt>Change Controller:</dt><dd>IETF</dd>
tems use the P-256 curve <xref target="FIPS186"/>.</t> <dt>Security and Privacy Considerations:</dt><dd>RFC 9749, <xref targe
</list></t> t="security-considerations"/></dd>
<dt>Reference:</dt><dd>RFC 9749</dd>
</dl>
</section>
</section>
</middle>
<back>
<references anchor="sec-combined-references">
<name>References</name>
<t>Informative Note: The format of the application server key was chosen to ensu <!-- [rfced] Would you like the references to be alphabetized or left in their
re compatibility with the browser API (<xref target="PUSH-API"/>, Section 7.2), current order?
allowing the key to be directly copied and used without additional transformatio -->
n. Additionally, as noted in <xref target="RFC8292"/>, Section 3.2, the X9.62 en
coding simplifies key comparisons and is more compact than alternative formats.<
/t>
</section> <references anchor="sec-normative-references">
<section anchor="issuing-push-notifications"><name>Issuing Push Notifications</n <name>Normative References</name>
ame>
<t>Every time the server sends a push message to a PushSubscription URL it MUST <!-- [rfced] The following reference has been withdrawn. See
authenticate the POST request using the protocol outlined in <xref target="RFC82 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf. Would you
92"/>. This includes both StateChange events and PushVerification notifications. like to cite the latest version (i.e., FIPS 186-5)?
To authenticate the request, the server MUST use a JWT signed by the private ke
y corresponding to the application server key. This application server key MUST
be the one that was advertised in the capabilities object at the time the PushSu
bscription was created.</t>
</section> Original:
<section anchor="key-rotation"><name>Key Rotation</name> [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS 186-4, July 2013,
<https://doi.org/10.6028/NIST.FIPS.186-4>.
<t>When a server needs to replace its VAPID key, it MUST update the sessionState Perhaps:
per <xref target="RFC8620"/>. The client MUST monitor the JMAP session object f [FIPS186] NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
or changes to the VAPID key and MUST recreate its push subscription when it dete February 2023, <https://doi.org/10.6028/NIST.FIPS.186-5>.
cts such a change.</t> -->
<reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.18
6-4">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>NIST</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="NIST FIPS" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<t>After key rotation, the server MAY continue to send push notifications for ex <!-- [rfced] The following reference has been replaced by ANSI X9.142 (and X9.62
isting push subscriptions using the old application server key for a transitiona seems to no longer be available on the ANSI webstore).
l period. This allows clients time to recreate their respective push subscriptio
ns. At the end of the transitional period (or immediately for implementations th
at do not have one), the server MUST destroy push subscriptions that use the old
key.</t>
<t>When destroying push subscriptions that include the data type <spanx style="v See:
erb">PushSubscription</spanx>, the server MAY issue one final StateChange push n https://x9.org/asc-x9-issues-new-standard-for-public-key-cryptography-ecdsa/
otification using the old URL and application server key to notify the client of https://webstore.ansi.org/standards/ascx9/ansix91422020
changes to the PushSubscription data type. This prompts the client to make a <s
panx style="verb">PushSubscription/changes</spanx> method call. The response to
this call will contain an updated sessionState, which refers to a session object
that contains the new VAPID key.</t>
<t>A race condition can occur when the server updates its VAPID key after the cl ient has refreshed the session object but before calling the PushSubscription/se t method. This situation causes the server to send a PushVerification object to a push resource URL that is now associated with an outdated VAPID key. Consequen tly, the push service will reject the PushVerification with a 403 (Forbidden) st atus code, as specified in <xref target="RFC8292"/>.</t> Would you like to cite X9.142-2020 in this document?
<t>To alleviate this problem, the client MUST check if the sessionState in the r Original:
esponse from the PushSubscription/set method points to a session object with an [X9.62] American National Standards Institute, "Public Key
applicationServerKey that matches their expectations. If there is a mismatch, th Cryptography for the Financial Services Industry: The
e client MAY retry creating the PushSubscription. Additionally, the client MAY d Elliptic Curve Digital Signature Algorithm (ECDSA)",
estroy the PushSubscription from the earlier, failed attempt.</t> ANSI X9.62-2005, November 2005.
</section> Perhaps:
<section anchor="security-considerations"><name>Security Considerations</name> [X9.142] American National Standards Institute, "Financial services - Publi
c
Key Cryptography for the Financial Services Industry - The Ellipti
c
Curve Digital Signature Algorithm - ECDSA", ANSI X9.142-2020, Sept
ember 2020.
<t>During the key rotation process, synchronization issues between the client an If this change is made, please confirm that Annex A appears in X9.142-2020
d server may arise. Specifically, a client might restrict a push subscription wi with the information in the following sentence. We are unable to access the
th the push service to an outdated key, while the server sends the PushVerificat full document to verify (it is behind a paywall).
ion object authenticated with the newly rotated key. This mismatch leads to the
push service rejecting the PushVerification request with HTTP status code 403, a
s specified in <xref target="RFC8292"/>, Section 4.2.</t>
<t>Per the requirements of <xref target="RFC8620"/>, Section 7.2, the server MUS Original:
T NOT retry the rejected PushVerification request. Consequently, the PushVerific The ECDSA public key that the push service will use to
ation object will not be delivered to the client.</t> authenticate the application server, in its uncompressed form (as
described in [X9.62] Annex A) and encoded using base64url encoding
[RFC7515].
-->
<reference anchor="X9.62">
<front>
<title>Public Key Cryptography for the Financial Services Industry:
The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author>
<organization>American National Standards Institute</organization>
</author>
<date year="2005" month="November"/>
</front>
<seriesInfo name="ANSI" value="X9.62-2005"/>
</reference>
<t>To mitigate such issues, the client is responsible for detecting and resolvin <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
g any synchronization discrepancies, as outlined in the 'Key Rotation' section o 620.xml"/>
f this document.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
292.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
515.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<reference anchor="PUSH-API" target="https://www.w3.org/TR/push-api/">
<front>
<title>Push API</title>
<author initials="P" surname="Beverloo" role="editor">
<organization/>
</author>
<author initials="M" surname="Thomson" role="editor">
<organization/>
</author>
<author initials="M" surname="Caceres" role="editor">
<organization/>
</author>
<date year="2024" month="September"/>
</front>
<refcontent>W3C Working Draft</refcontent>
</reference>
</references>
</references>
</back>
<t>The inclusion of the <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</ <!-- [rfced] Should the following in Section 3 be tagged as <dl> rather than
spanx> property in the JMAP capabilities object is limited to providing informat <ul> with a single bullet? To see what <dl> looks like, please see these test
ion about the server's support for Voluntary Application Server Identification ( files:
VAPID). This property does not reveal sensitive information, nor does it introdu
ce new security or privacy risks beyond those inherent to JMAP and WebPush. The
security considerations for JMAP (<xref target="RFC8620"/>, especially Section 8
.6 and Section 8.7 of that document), WebPush (<xref target="RFC8030"/>) and VAP
ID (<xref target="RFC8292"/>) apply to this document.</t>
</section> https://www.rfc-editor.org/authors/rfc9749-TEST.txt
<section anchor="iana-considerations"><name>IANA Considerations</name> https://www.rfc-editor.org/authors/rfc9749-TEST.html
<section anchor="registration-of-the-jmap-capability-for-vapid"><name>Registrati Original:
on of the JMAP Capability for VAPID</name> * applicationServerKey: "String"
<t>This specification requests IANA to register a new capability in the JMAP Cap The ECDSA public key that the push service will use to
abilities registry with the following data:</t> authenticate the application server, in its uncompressed form (as
described in [X9.62] Annex A) and encoded using base64url encoding
[RFC7515]. Current systems use the P-256 curve [FIPS186].
-->
<t>Capability Name: <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</span <!-- [rfced] Should the Informative Note in Section 3 be in the <aside>
x></t> element? The aside element is defined as "a container for content that is
semantically less important or tangential to the content that surrounds
it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<t>Specification document: this document</t> <!-- [rfced] We see inconsistent use of <tt> in this document. Please review
the notes below and let us know how to update for consistency. In the
html and pdf outputs, the text enclosed in <tt> is output in fixed-width
font; in the txt output, there are no changes to the font.
<t>Intended use: common</t> a) This term appears with twice with <tt> and once with quotation marks:
<t>Change Controller: IETF</t> <tt>urn:ietf:params:jmap:webpush-vapid</tt>
"urn:ietf:params:jmap:webpush-vapid"
<t>Security and privacy considerations: this document, Section 6</t> b) This term appears once with <tt> and six times without <tt>:
</section> <tt>PushSubscription</tt>
</section> PushSubscription
</middle> Also, consider if the following should be handled in the same way as
PushSubscription; currently, these do not have <tt>.
<back> PushVerification
StateChange
sessionState
applicationServerKey
<references title='References' anchor="sec-combined-references"> c) These terms have a similar structure, but one appears with <tt> and one
without (one instance of each). We recommend consistent handling.
<references title='Normative References' anchor="sec-normative-references"> <tt>PushSubscription/changes</tt>
<reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.186-4"> PushSubscription/set
<front> -->
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organ
ization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="FIPS" value="186-4"/>
</reference>
<reference anchor="X9.62" >
<front>
<title>Public Key Cryptography for the Financial Services Industry: The Elli
ptic Curve Digital Signature Algorithm (ECDSA)</title>
<author >
<organization>American National Standards Institute</organization>
</author>
<date year="2005" month="November"/>
</front>
<seriesInfo name="ANSI" value="X9.62-2005"/>
</reference>
&RFC8620;
&RFC8030;
&RFC8292;
&RFC2119;
&RFC8174;
&RFC7515;
</references> <!-- [rfced] This document consistently uses "WebPush" (single word with no
space). We see use of both "WebPush" (single word) and "Web Push" (two
words) in past RFCs. See the notes below and let us know if you would
like to leave the single-word form in this document or make a change.
<references title='Informative References' anchor="sec-informative-reference RFC 8030 - uses two-word form in title of "Web Push Identifiers" registry, but
s"> also uses one-word form in a couple of instances (i.e., "WebPush scenarios"
and "WebPush Architecture").
<reference anchor="PUSH-API" target="https://www.w3.org/TR/push-api/"> RFC 8291 - uses both forms (seems the two-word form is used in prose and the
<front> one-word form is used in code).
<title>Push API</title>
<author initials="" surname="Peter Beverloo">
<organization></organization>
</author>
<author initials="" surname="Martin Thomson">
<organization></organization>
</author>
<author initials="" surname="Marcos Caceres">
<organization></organization>
</author>
<date year="2024" month="September"/>
</front>
</reference>
</references> RFC 8292 - uses the two-word form in document title and in the context of "Web
Push protocol".
</references> The only RFCs with this term in the document title are RFCs 8291 and 8292, and
both use "Web Push" (two words). See https://www.rfc-editor.org/rfc-index.txt.
-->
</back> <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
<!-- ##markdown-source: Voluntary Application Server Identification (VAPID)
H4sIAAAAAAAAA6VZ0XbbuBF951dMlYe1eyxZVhwn0enpVms7jXYTR43k3e5b JSON Meta Application Protocol (JMAP)
IHIkYgMCLABKq/r4X/ot/bKeGYAUacm77WleIlEkOLhz587FuN/vJ156hWPo JSON Web Token (JWT)
3TsEs4IfJ7PpDUgN33+czOAnXM4ql/eSzKR3oqD7MitWvi/Rr/q/FKLsb3FZ Elliptic Curve Digital Signature Algorithm (ECDSA)
Vi7vb0Qps/7FsJdkwuMYRsPRq/7won8xTBJhUYxhqj1ajT7Zrse8fOKqZSGd -->
k0b7XYljmN4u3iWp8GNwPktkacfQ87ZyfjQcvh2OekkiKp8bO06gnwBojuhG
aIkK/lop79I8AcBCSDWGjK//ZR2uDzJMEm1sIbzc4DgBeDedzS/eXNFHgBqF
G7mWXiiYy7UWvrIIcy90JmwGJzfz+WmP726i4H99MHY9ht6d8NJooWCqnZe+
8gxo/bwDoTNYYJpro8x6Byd30/kiLlhDdvGyP3wdAhJ2jX4Mvdz70o3PzzMj
B8auzy+Gg6vh6M05PT2gPQwu3lz1L8M6Dq1EJ/XK1MHRHWPoNff8/e3gatTd
86xaKpnCD7iDa7srvVlbUeY7WBkLPkd4J7XQqSRU0G5kig6mOquct7sxLHKE
W6Vk6WUK15XdIBxiOFFrY6XPCzi5vb6ZT34TxkmBVqZCQ4PnHsIG2S5sw1f9
i4tnAJjczadj6PG++3RrL0no9xYTZvfz9/3JbPoUFpfDZDY9HqvUju5Bjxa+
ww1aZUzvya8fhfVSwyI3hTP6yK+pcXAtUrTouhsaXfaHb4/zYLvdDrYvmQqL
z+dceqKU570kSfr9Poil81akPkkWuXSQmbQqUHvIcCU1OhBQoM9NxtnlGndo
N2gdeAMi26D10iHlXVpIRSmWUkm/418rn6P2MhUea2UAbbxc0SVptIPKSb1m
0vxoVKW9sDuYlKWKNzCB0MI0o3Xqx6C0xpvUqEHYQiGzTGGSvCDFsCarUror
STjah4c/fH53/eZqNHx8BFdiKlcSHeRmC6mSqL0D4o6rli61cokUOG74eghO
NK8DnwsP0kFqilJ4uVQIW+nzZm/xXcOXw8fHAcxNgUB4M2JcBhb/UUmLYSHa
tWjtNeDaQc2BUCqsUaBzYo3/L2R1jKO3I4pxYWAlUsoY5YjCOuOlAzRwYixU
joJa01epm616tIUMwnQKGjFzISTuBmUQiK+4I0F7Zp/eQCmcA+lBKENbMnxr
GzHY5qjBorcSNyEZGreAOiuN1H4AlPRroylfzKd7hxlwCUkHN5HLRG3kaLaG
RKH38X6+6J2F/+HuE3/+fPu3++nn2xv6PH8/+fCh+ZDEO+bvP91/uNl/2j95
/enjx9u7m/Dw3acFdC4lvY+Tn3tnLOe9T7PF9NPd5EOPovSdihOWybdEkNT4
SoseMxAuyTBQk3f23fXs3/+6uIx5HF1cvH18rJN68fry8ZExC28zWu3iV5/j
LhFlicLSKkSrVJQku+4MhAOXm62GHC0OCC2HEatC7EAoZ2D/bDdqqRNltki1
75BWKpWQGm71WkmXh1XOSGXo5qASTVeFAoWWeu0GyZ++VVIj9N98++eEknoj
XWo2aCnp86osjfWsQEywkFAu70ZxqKjN8hdMuUIt+spqhg9KYX3NQ1c356hk
7CXq504cIsyR1QNG9EhbPE4HsbQcuBBQqEPpalmJ/GZWiSwLylGi9TtIhVKY
Qa+yekxWaFwKKwo3Jkc07jiiXl0HR3Y24O65EarCsCHp9q+QZBjqrbDAcCCp
0V5w1hBWRimzpbCbhmb0OEn+2K7PsMkfcDeG3txTAnpJAqFvUy9uV3ejY92i
lUqRbBz0gONKcEakkqS3moTVoqMipvjgRDjosP/hgfvy4yNMtMZfYXLKREed
mgyzqI1L4fDqsrIqXKdLIZGvX128ItW7rqwlOrqd81i4EGuOMOuPXl1Byqbk
4SH6vcfHQZJM9wYA7gz13AXjSdd+Q+NYc4SDNDcONbcW7cjg1B0k9EpuIrTE
0potye1kNoWTh4faZzw+njW8fD0YnZ5R/YZE+qhsQTgyaTH1agepKSWxXxMm
mPEbTOWJljKaJG+Fdg0LBjBpflI7lgRtfA36vmXsA3k5GIVewRnZQ+1kUarQ
ZCkw3qmVjtSZwpEOClMjEJhKckROP8AbQnID7ufOVbQmt5y7tnNIktsN2h14
WYTcRcQdanLOnZ7JPOQ15qHLl7yB+88fqPmEcn1K09mn+YLbNTrfarlNGzWV
J8E6wGcQWo/UqaoydLA0Pic/6vE6F3qNtbcgKCiiH9HulaPjjbg5H8QVQzpr
75l3QBwW8P1PC3ByTYEtdzFiuaGHQy6sRVcazYmKOnOctnEfz3Ca37gMERkd
/QwRvTGEGUTNOSbQUTSa3B2khmvGovCYMQ/oqPHZeBF83U9kCkQdTzQfBiyW
SqTIUhJ8yFfcnTUprsqsBjHqPqcFSrQdnQ8iGw0QP1kYLX082xzrG9SXUs6u
q0Ft3s+J5lUshh1xfEEvO1umTUny3R5TTz0mzUHEdQdJMln5CL6NQHQ5MPmZ
pV7qivlOdRDe0jXcFCv+Kh03r4Mo2u7SqOy59NMiIghIrSYlWmmymjWkTq7x
1yHPZo9AsAFERdKSDR4JZACTQBLaRxTYIy9khyqLAjMpPKoQGgkQkjmJe2Z2
ZoaQgFxsmLKnhxWUofPW7I6hwivUXYKAoQqJRIyPPYNnODIENeCnM+EF0PQC
vjyl/ZeDjErnqlBhKxkPto2QHCT3Se5I3oh8z+TQm/Dwru33zeopkQ9Ks4k/
5rq0pii9a6/iDRTiK8nRwRbP4/Jf6lMlGaNQcUGZgmtgZ0M/BS9RexihYxVn
nRI+g20u0xwsrupz6dMS5TTEZUKsdI5oqpTqCyyJR0riyBulU6FJ08qG0mxl
JsTgukIDggu0BUMuyIeuLLocs7bu1EEtKw9LXHE3FErVyTvAzKGPcEXMnfSV
iEFWDl07uLr2xWF7qbEwdX+06ExlU2Su1IdbbbYgnDOpZKDZmxAUlQ/I70Gj
k5ejfqQ9WYbjPtBiTAAeBhTWhsvhSzh5Z+xSZhnqUzLpvqJTdobhbBJP7YfN
NkmoRyqFGxl0JRByqbDonGODE84x/QpyddgCYqtqGLiypvi9VACfQI+zrcbs
mKsOOBfCp3lInCRBJiGs2/6UI7TIjh4K6fjm7n4mP/OpeBe65HPMeWrqnqxQ
C97ROm8wQGGVJJe+EpLOMMJ7LErPfXmOaWXJwRITZIa2Nmc3lW2707plUXJS
dO4M3E6nuTVa/jP8wErnYIl+i7HaYqSkYZHbfBi10uEA5vWRK7jV+uZCrnNP
ifRWktE41mhrs93hKqWxRXJ2DttcqiPm8iiVa2fT8mvZ/lUatyqiEBaPhVwn
FxSKzB2dgIT6aWe4897aovKr3i8Ws3b1UGX9dgXt7fzlYDRIklmUsDioKrh/
PzkId84ih22U5h+Bm2EhCh+PmN0Y+TEVeQ5dFhTq4nTUQSU3aElZTYsuQRIK
6eWaKptdVOBWh/48IuBq5ykeuYZgvHjIpDOWRhVGTnp3wNZMutRiSVNuDPOT
9nmA3vNN27J+Ay4iVp/a6/HJIIwy2CC45gaEL78/KPjSOvrrvTd9ZiCiZCF9
AKu0ZiOzJ1MAEEs6H+6T+U0z5ghzl/9h1njCLeJ0bxBClJlBPlSCxQ0KRdVE
bm6D7TjOaDoUbpVknMI8N7RrV6uNseFYk+7ASveVZGNnNPVY42g1Us/gQxgS
ymecWwar0SyUdmRrP+I+6fKdjaokqWmo/2Zwxevuv78OuWOrGZJ7etaMS0/a
o+Ewswh99KRdjafcMXaNA2qx5AVMJ3eTA5198QI+41rSCN+36MObuN4P4zuT
s4OBVaxEF17BRp2WpLEv496a6reZdt1mWnjEtmYZ+2ETWcZxkrTiCX8a/G9I
niTzTqw1JOMuQjSh8ajDDAjHNF0o6KgYvfK1ISIphTb+zTBpOheloiZTlw5P
XrGXvavkP85ys2AIHQAA
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style
Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 59 change blocks. 
265 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.48.