<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-jmap-webpush-vapid-10" number="9749" category="std" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" updates="" obsoletes="" symRefs="true" prepTime="2025-03-15T23:15:11" indexInclude="true" scripts="Common,Latin" sortRefs="false" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-jmap-webpush-vapid-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9749" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Use of VAPID in JMAP Web Push">Use of Voluntary Application Server Identification (VAPID) in JSON Meta Application Protocol (JMAP) Web Push</title>
    <seriesInfo name="RFC" value="9749" stream="IETF"/>
    <author initials="D." surname="Gultsch" fullname="Daniel Gultsch">
      <address>
        <email>daniel@gultsch.de</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>ART</area>
    <workgroup>jmap</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a method for JSON Meta Application Protocol (JMAP) servers to advertise their
      capability to authenticate Web Push notifications using the Voluntary
      Application Server Identification (VAPID) protocol.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9749" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discovering-support-for-vap">Discovering Support for VAPID</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuing-push-notifications">Issuing Push Notifications</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-rotation">Key Rotation</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-the-jmap-ca">Registration of the JMAP Capability for VAPID</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> specifies how clients can subscribe to events using a protocol that is compatible with Web Push <xref target="RFC8030" format="default" sectionFormat="of" derivedContent="RFC8030"/>. Some push services require that the application server authenticate all push messages using the VAPID protocol <xref target="RFC8292" format="default" sectionFormat="of" derivedContent="RFC8292"/>. To facilitate that, the client (or user agent in Web Push terminology) needs the VAPID public key of the application server to pass along to the push service when retrieving a new endpoint.</t>
    </section>
    <section anchor="conventions-used-in-this-document" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">
    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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
    </section>
    <section anchor="discovering-support-for-vapid" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-discovering-support-for-vap">Discovering Support for VAPID</name>
      <t indent="0" pn="section-3-1">The JMAP capabilities object is returned as part of the standard JMAP session object (see <xref section="2" sectionFormat="of" target="RFC8620" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-2" derivedContent="RFC8620"/>). Servers supporting this specification <bcp14>MUST</bcp14> add a property called <tt>urn:ietf:params:jmap:webpush-vapid</tt> to the capabilities object. The value of this property is an object that <bcp14>MUST</bcp14> contain the following information:</t>
      <dl spacing="compact" newline="true" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1"><tt>applicationServerKey</tt>: "String"</dt>
        <dd pn="section-3-2.2">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 Section 2.3.3 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/>) and encoded using
          base64url encoding <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>. Current systems use the
          P-256 curve <xref target="FIPS186" format="default" sectionFormat="of" derivedContent="FIPS186"/>.</dd>
      </dl>
      <aside pn="section-3-3">
        <t indent="0" pn="section-3-3.1">Informative Note: The format of the application server key was chosen to ensure compatibility with the browser API (Section 7.2 of <xref target="PUSH-API" format="default" sectionFormat="of" derivedContent="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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8292#section-3.2" derivedContent="RFC8292"/>, the X9.62 encoding (which is compatible with SEC1 encoding) simplifies key comparisons and is more compact than alternative formats.</t>
      </aside>
    </section>
    <section anchor="issuing-push-notifications" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-issuing-push-notifications">Issuing Push Notifications</name>
      <t indent="0" pn="section-4-1">Every time the server sends a push message to a <tt>PushSubscription</tt> URL, it <bcp14>MUST</bcp14> authenticate the POST request using the protocol outlined in <xref target="RFC8292" format="default" sectionFormat="of" derivedContent="RFC8292"/>. This includes both <tt>StateChange</tt> events and <tt>PushVerification</tt> notifications. To authenticate the request, the server <bcp14>MUST</bcp14> use a JSON Web Token (JWT) signed by the private key corresponding to the application server key. This application server key <bcp14>MUST</bcp14> be the one that was advertised in the capabilities object at the time the <tt>PushSubscription</tt> was created.</t>
    </section>
    <section anchor="key-rotation" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-key-rotation">Key Rotation</name>
      <t indent="0" pn="section-5-1">When a server needs to replace its VAPID key, it <bcp14>MUST</bcp14> update the <tt>sessionState</tt> per <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/>. The client <bcp14>MUST</bcp14> 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 indent="0" pn="section-5-2">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 respective push subscriptions. At the end of the transitional period (or immediately for implementations that do not have one), the server <bcp14>MUST</bcp14> destroy push subscriptions that use the old key.</t>
      <t indent="0" pn="section-5-3">When destroying push subscriptions that include the data type <tt>PushSubscription</tt>, the server <bcp14>MAY</bcp14> issue one final <tt>StateChange</tt> push notification using the old URL and application server key to notify the client of changes to the <tt>PushSubscription</tt> data type. This prompts the client to make a <tt>PushSubscription/changes</tt> method call. The response to this call will contain an updated <tt>sessionState</tt>, which refers to a session object that contains the new VAPID key.</t>
      <t indent="0" pn="section-5-4">A race condition can occur when the server updates its VAPID key after the client has refreshed the session object but before calling the <tt>PushSubscription/set</tt> method. This situation causes the server to send a <tt>PushVerification</tt> object to a push resource URL that is now associated with an outdated VAPID key. Consequently, the push service will reject the <tt>PushVerification</tt> with a 403 (Forbidden) status code, as specified in <xref section="4.2" sectionFormat="of" target="RFC8292" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8292#section-4.2" derivedContent="RFC8292"/>.</t>
      <t indent="0" pn="section-5-5">To alleviate this problem, the client <bcp14>MUST</bcp14> check if the <tt>sessionState</tt> in the response from the <tt>PushSubscription/set</tt> method points to a session object with an <tt>applicationServerKey</tt> that matches their expectations. If there is a mismatch, the client <bcp14>MAY</bcp14> retry creating the <tt>PushSubscription</tt>. Additionally, the client <bcp14>MAY</bcp14> destroy the <tt>PushSubscription</tt> from the earlier, failed attempt.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">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 <tt>PushVerification</tt> object authenticated with the newly rotated key. This mismatch leads to the push service rejecting the <tt>PushVerification</tt> request with a 403 (Forbidden) status code, as specified in <xref section="4.2" sectionFormat="of" target="RFC8292" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8292#section-4.2" derivedContent="RFC8292"/>.</t>
      <t indent="0" pn="section-6-2">Per the requirements of <xref section="7.2" sectionFormat="of" target="RFC8620" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-7.2" derivedContent="RFC8620"/>, the server <bcp14>MUST NOT</bcp14> retry the rejected <tt>PushVerification</tt> request. Consequently, the <tt>PushVerification</tt> object will not be delivered to the client.</t>
      <t indent="0" pn="section-6-3">To mitigate such issues, the client is responsible for detecting and resolving any synchronization discrepancies, as outlined in <xref target="key-rotation" format="default" sectionFormat="of" derivedContent="Section 5"/> of this document.</t>
      <t indent="0" pn="section-6-4">The inclusion of the <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 VAPID. This property does not reveal sensitive information, nor does it introduce new security or privacy risks beyond those inherent to JMAP and Web Push. The security considerations for JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> (especially Sections <xref section="8.6" sectionFormat="bare" target="RFC8620" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-8.6" derivedContent="RFC8620"/> and <xref section="8.7" sectionFormat="bare" target="RFC8620" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-8.7" derivedContent="RFC8620"/>), Web Push <xref target="RFC8030" format="default" sectionFormat="of" derivedContent="RFC8030"/>, and VAPID <xref target="RFC8292" format="default" sectionFormat="of" derivedContent="RFC8292"/> apply to this document.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="registration-of-the-jmap-capability-for-vapid" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-registration-of-the-jmap-ca">Registration of the JMAP Capability for VAPID</name>
        <t indent="0" pn="section-7.1-1">IANA has registered the following new capability in the "JMAP Capabilities" registry:</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-7.1-2">
          <dt pn="section-7.1-2.1">Capability Name:</dt>
          <dd pn="section-7.1-2.2">
            <tt>urn:ietf:params:jmap:webpush-vapid</tt></dd>
          <dt pn="section-7.1-2.3">Intended Use:</dt>
          <dd pn="section-7.1-2.4">common</dd>
          <dt pn="section-7.1-2.5">Change Controller:</dt>
          <dd pn="section-7.1-2.6">IETF</dd>
          <dt pn="section-7.1-2.7">Security and Privacy Considerations:</dt>
          <dd pn="section-7.1-2.8">RFC 9749, <xref target="security-considerations" format="default" sectionFormat="of" derivedContent="Section 6"/></dd>
          <dt pn="section-7.1-2.9">Reference:</dt>
          <dd pn="section-7.1-2.10">RFC 9749</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.186-5" quoteTitle="true" derivedAnchor="FIPS186">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <date year="2023" month="February"/>
          </front>
          <seriesInfo name="NIST FIPS" value="186-5"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
        </reference>
        <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf" quoteTitle="true" derivedAnchor="SEC1">
          <front>
            <title>SEC 1: Elliptic Curve Cryptography</title>
            <author>
              <organization showOnFrontPage="true">Standards for Efficient Cryptography Group</organization>
            </author>
            <date year="2009" month="May"/>
          </front>
          <refcontent>Version 2.0</refcontent>
        </reference>
        <reference anchor="RFC8620" target="https://www.rfc-editor.org/info/rfc8620" quoteTitle="true" derivedAnchor="RFC8620">
          <front>
            <title>The JSON Meta Application Protocol (JMAP)</title>
            <author fullname="N. Jenkins" initials="N." surname="Jenkins"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8620"/>
          <seriesInfo name="DOI" value="10.17487/RFC8620"/>
        </reference>
        <reference anchor="RFC8030" target="https://www.rfc-editor.org/info/rfc8030" quoteTitle="true" derivedAnchor="RFC8030">
          <front>
            <title>Generic Event Delivery Using HTTP Push</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="E. Damaggio" initials="E." surname="Damaggio"/>
            <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/>
            <date month="December" year="2016"/>
            <abstract>
              <t indent="0">This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8030"/>
          <seriesInfo name="DOI" value="10.17487/RFC8030"/>
        </reference>
        <reference anchor="RFC8292" target="https://www.rfc-editor.org/info/rfc8292" quoteTitle="true" derivedAnchor="RFC8292">
          <front>
            <title>Voluntary Application Server Identification (VAPID) for Web Push</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="P. Beverloo" initials="P." surname="Beverloo"/>
            <date month="November" year="2017"/>
            <abstract>
              <t indent="0">An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8292"/>
          <seriesInfo name="DOI" value="10.17487/RFC8292"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" quoteTitle="true" derivedAnchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="PUSH-API" target="https://www.w3.org/TR/push-api/" quoteTitle="true" derivedAnchor="PUSH-API">
          <front>
            <title>Push API</title>
            <author initials="P" surname="Beverloo" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Thomson" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Caceres" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2024" month="September"/>
          </front>
          <refcontent>W3C Working Draft</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="D." surname="Gultsch" fullname="Daniel Gultsch">
        <address>
          <email>daniel@gultsch.de</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
