wdiff rfc9749xml2.original.xml rfc9749.xml

<?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) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC8620 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml">
<!ENTITY RFC8030 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8030.xml">
<!ENTITY RFC8292 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8292.xml">
<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7515 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-jmap-webpush-vapid-10" number="9749" category="std" consensus="true" submissionType="IETF"> submissionType="IETF" version="3" xml:lang="en" tocInclude="true" updates="" obsoletes="" 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>Use
    <title abbrev="Use of VAPID in JMAP WebPush">Use of Voluntary Application Server Identification (VAPID) in JSON Meta Application Protocol (JMAP) WebPush</title>
    <seriesInfo name="RFC" value="9749"/>
    <author initials="D." surname="Gultsch" fullname="Daniel Gultsch">
      <organization></organization>
      <address>
        <email>daniel@gultsch.de</email>
      </address>
    </author>
    <date year="2025" month="January" day="10"/>

    <area>Internet</area>
    <workgroup>JMAP</workgroup> month="March"/>
    <area>ART</area>
    <workgroup>jmap</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>

<?line 45?>
      <t>This document defines a method for JMAP 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 49?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>

<!-- [rfced] Will readers understand what "it" refers to here?

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.

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.

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

      <t>JMAP <xref target="RFC8620"/> specifies how clients can subscribe to events using a protocol that is compatible with WebPush <xref target="RFC8030"/>. Some push services require that the application server authenticates authenticate all push messages using the Voluntary Application Server Identification 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 endpoint.</t>
    </section>
    <section anchor="conventions-used-in-this-document"><name>Conventions anchor="conventions-used-in-this-document">
      <name>Conventions Used in This Document</name>

<t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
<?line -8?></t>
        </t>
    </section>
    <section anchor="discovering-support-for-vapid"><name>Discovering anchor="discovering-support-for-vapid">
      <name>Discovering Support for VAPID</name>
      <t>The JMAP capabilities object is returned as part of the standard JMAP session object (see Section 2 of <xref section="2" sectionFormat="of" target="RFC8620"/>). Servers supporting this specification MUST <bcp14>MUST</bcp14> add a property called "urn:ietf:params:jmap:webpush-vapid" to the capabilities object. The value of this property is an object that MUST <bcp14>MUST</bcp14> contain the following information:</t>

<t><list style="symbols">

      <ul spacing="normal">
        <li>
          <t>applicationServerKey: "String"  <vspace blankLines='1'/>
The ECDSA "String"</t>
          <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) public key that the push service will use to
          authenticate the application server, in its uncompressed form (as
          described in <xref target="X9.62"/> Annex A) 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>
</list></t>
        </li>
      </ul>

      <t>Informative Note: The format of the application server key was chosen to ensure compatibility with the browser API (<xref target="PUSH-API"/>, Section 7.2), (Section 7.2 of <xref target="PUSH-API"/>), allowing the key to be directly copied and used without additional transformation. Additionally, as noted in <xref section="3.2" sectionFormat="of" target="RFC8292"/>, Section 3.2, the X9.62 encoding simplifies key comparisons and is more compact than alternative formats.</t>
    </section>
    <section anchor="issuing-push-notifications"><name>Issuing anchor="issuing-push-notifications">
      <name>Issuing Push Notifications</name>
      <t>Every time the server sends a push message to a PushSubscription URL URL, it MUST <bcp14>MUST</bcp14> authenticate the POST request using the protocol outlined in <xref target="RFC8292"/>. This includes both StateChange events and PushVerification notifications. To authenticate the request, the server MUST <bcp14>MUST</bcp14> use a JWT JSON Web Token (JWT) signed by the private key corresponding to the application server key. This application server key MUST <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 anchor="key-rotation">
      <name>Key Rotation</name>
      <t>When a server needs to replace its VAPID key, it MUST <bcp14>MUST</bcp14> update the sessionState per <xref target="RFC8620"/>. The client MUST <bcp14>MUST</bcp14> monitor the JMAP session object for changes to the VAPID key and MUST <bcp14>MUST</bcp14> recreate its push subscription when it detects such a change.</t>
      <t>After key rotation, the server MAY <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 respective push subscriptions. At the end of the transitional period (or immediately for implementations that do not have one), the server MUST <bcp14>MUST</bcp14> destroy push subscriptions that use the old key.</t>
      <t>When destroying push subscriptions that include the data type <spanx style="verb">PushSubscription</spanx>, <tt>PushSubscription</tt>, the server MAY <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 <spanx style="verb">PushSubscription/changes</spanx> <tt>PushSubscription/changes</tt> 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>

<!-- [rfced] FYI - We updated these sentences as follows (pointed to Section
4.2 of [RFC8292] in both and updated phrasing relating to the status code
to be consistent). Let us know any concerns.

Original:
   Consequently, the push
   service will reject the PushVerification with a 403 (Forbidden)
   status code, as specified in [RFC8292].
   ...
   This mismatch leads to the push service rejecting the
   PushVerification request with HTTP status code 403, as specified in
   [RFC8292], Section 4.2.

Updated:
   Consequently, the push
   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>A race condition can occur when the server updates its VAPID key after the client has refreshed the session object but before calling the PushSubscription/set 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. Consequently, the push service will reject the PushVerification with a 403 (Forbidden) status code, as specified in <xref section="4.2" sectionFormat="of" target="RFC8292"/>.</t>
      <t>To alleviate this problem, the client MUST <bcp14>MUST</bcp14> check if the sessionState in the response from the PushSubscription/set method points to a session object with an applicationServerKey that matches their expectations. If there is a mismatch, the client MAY <bcp14>MAY</bcp14> retry creating the PushSubscription. Additionally, the client MAY <bcp14>MAY</bcp14> destroy the PushSubscription from the earlier, failed attempt.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>During the key rotation process, synchronization issues between the client and server may arise. Specifically, a client might restrict a push subscription with the push service to an outdated key, while the server sends the PushVerification object authenticated with the newly rotated key. This mismatch leads to the push service rejecting the PushVerification request with HTTP a 403 (Forbidden) status code 403, code, as specified in <xref target="RFC8292"/>, Section 4.2.</t> section="4.2" sectionFormat="of" target="RFC8292"/>.</t>
      <t>Per the requirements of <xref section="7.2" sectionFormat="of" target="RFC8620"/>, Section 7.2, the server MUST NOT <bcp14>MUST NOT</bcp14> retry the rejected PushVerification request. Consequently, the PushVerification object will not be delivered to the client.</t>
      <t>To mitigate such issues, the client is responsible for detecting and resolving any synchronization discrepancies, as outlined in the 'Key Rotation' section <xref target="key-rotation"/> of this document.</t>
      <t>The inclusion of the <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</spanx> <tt>urn:ietf:params:jmap:webpush-vapid</tt> property in the JMAP capabilities object is limited to providing information about the server's support for Voluntary Application Server Identification (VAPID). VAPID. This property does not reveal sensitive information, nor does it introduce new security or privacy risks beyond those inherent to JMAP and WebPush. The security considerations for JMAP (<xref target="RFC8620"/>, especially Section 8.6 <xref target="RFC8620"/> (especially Sections <xref section="8.6" sectionFormat="bare" target="RFC8620"/> and Section 8.7 of that document), <xref section="8.7" sectionFormat="bare" target="RFC8620"/>), WebPush (<xref target="RFC8030"/>) <xref target="RFC8030"/>, and VAPID (<xref target="RFC8292"/>) <xref target="RFC8292"/> apply to this document.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="registration-of-the-jmap-capability-for-vapid"><name>Registration anchor="registration-of-the-jmap-capability-for-vapid">
        <name>Registration of the JMAP Capability for VAPID</name>

<t>This specification requests IANA to register a
        <t>IANA has registered the following new capability in the JMAP Capabilities registry with the following data:</t>

<t>Capability Name: <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</spanx></t>

<t>Specification document: this document</t>

<t>Intended use: common</t>

<t>Change Controller: IETF</t>

<t>Security "JMAP Capabilities" registry:</t>

	<dl spacing="compact" newline="false">
          <dt>Capability Name:</dt><dd><tt>urn:ietf:params:jmap:webpush-vapid</tt></dd>
          <dt>Intended Use:</dt><dd>common</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Security and privacy considerations: this document, Section 6</t> Privacy Considerations:</dt><dd>RFC 9749, <xref target="security-considerations"/></dd>
          <dt>Reference:</dt><dd>RFC 9749</dd>
	</dl>
      </section>
    </section>
  </middle>
  <back>
    <references title='References' anchor="sec-combined-references">
      <name>References</name>

<!-- [rfced] Would you like the references to be alphabetized or left in their
current order?
-->

      <references title='Normative References' anchor="sec-normative-references">
        <name>Normative References</name>

<!-- [rfced] The following reference has been withdrawn. See
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf. Would you
like to cite the latest version (i.e., FIPS 186-5)?

Original:
   [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>.

Perhaps:
   [FIPS186]  NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
              February 2023, <https://doi.org/10.6028/NIST.FIPS.186-5>.
-->
        <reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.186-4">
          <front>
            <title>Digital Signature Standard (DSS)</title>
    <author >
      <organization>National Institute of Standards and Technology (NIST)</organization>
            <author>
              <organization>NIST</organization>
            </author>
            <date year="2013" month="July"/>
          </front>
          <seriesInfo name="FIPS" name="NIST FIPS" value="186-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>

<!-- [rfced] The following reference has been replaced by ANSI X9.142 (and X9.62
seems to no longer be available on the ANSI webstore).

See:
https://x9.org/asc-x9-issues-new-standard-for-public-key-cryptography-ecdsa/
https://webstore.ansi.org/standards/ascx9/ansix91422020

Would you like to cite X9.142-2020 in this document?

Original:
   [X9.62]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry: The
              Elliptic Curve Digital Signature Algorithm (ECDSA)",
              ANSI X9.62-2005, November 2005.

Perhaps:
   [X9.142]   American National Standards Institute, "Financial services - Public
              Key Cryptography for the Financial Services Industry - The Elliptic
              Curve Digital Signature Algorithm - ECDSA", ANSI X9.142-2020, September 2020.

If this change is made, please confirm that Annex A appears in X9.142-2020
with the information in the following sentence. We are unable to access the
full document to verify (it is behind a paywall).

Original:
      The ECDSA public key that the push service will use to
      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" > anchor="X9.62">
          <front>
            <title>Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
    <author >
            <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;

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8030.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8292.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
      </references>
      <references title='Informative 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="" surname="Peter Beverloo">
      <organization></organization> initials="P" surname="Beverloo" role="editor">
              <organization/>
            </author>
            <author initials="" surname="Martin Thomson">
      <organization></organization> initials="M" surname="Thomson" role="editor">
              <organization/>
            </author>
            <author initials="" surname="Marcos Caceres">
      <organization></organization> initials="M" surname="Caceres" role="editor">
              <organization/>
            </author>
            <date year="2024" month="September"/>
          </front>
          <refcontent>W3C Working Draft</refcontent>
        </reference>
      </references>
    </references>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA6VZ0XbbuBF951dMlYe1eyxZVhwn0enpVms7jXYTR43k3e5b
IHIkYgMCLABKq/r4X/ot/bKeGYAUacm77WleIlEkOLhz587FuN/vJ156hWPo
3TsEs4IfJ7PpDUgN33+czOAnXM4ql/eSzKR3oqD7MitWvi/Rr/q/FKLsb3FZ
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] Should the following in Section 3 be tagged as <dl> rather than
<ul> with a single bullet? To see what <dl> looks like, please see these test
files:

https://www.rfc-editor.org/authors/rfc9749-TEST.txt
https://www.rfc-editor.org/authors/rfc9749-TEST.html

Original:
   *  applicationServerKey: "String"

      The ECDSA public key that the push service will use to
      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].
-->

<!-- [rfced] Should the Informative Note in Section 3 be in the <aside>
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).
-->

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

a) This term appears with twice with <tt> and once with quotation marks:

<tt>urn:ietf:params:jmap:webpush-vapid</tt>
"urn:ietf:params:jmap:webpush-vapid"

b) This term appears once with <tt> and six times without <tt>:

<tt>PushSubscription</tt>
PushSubscription

Also, consider if the following should be handled in the same way as
PushSubscription; currently, these do not have <tt>.

PushVerification
StateChange
sessionState
applicationServerKey

c) These terms have a similar structure, but one appears with <tt> and one
without (one instance of each). We recommend consistent handling.

<tt>PushSubscription/changes</tt>

PushSubscription/set
-->

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

RFC 8030 - uses two-word form in title of "Web Push Identifiers" registry, but
also uses one-word form in a couple of instances (i.e., "WebPush scenarios"
and "WebPush Architecture").

RFC 8291 - uses both forms (seems the two-word form is used in prose and the
one-word form is used in code).

RFC 8292 - uses the two-word form in document title and in the context of "Web
Push protocol".

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

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

Voluntary Application Server Identification (VAPID)
JSON Meta Application Protocol (JMAP)
JSON Web Token (JWT)
Elliptic Curve Digital Signature Algorithm (ECDSA)
-->

<!-- [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>