Diff: rfc9749v1.txt - rfc9749.txt

	rfc9749v1.txt	rfc9749.txt

	Internet Engineering Task Force (IETF) D. Gultsch	Internet Engineering Task Force (IETF) D. Gultsch
	Request for Comments: 9749 March 2025	Request for Comments: 9749 March 2025
	Category: Standards Track	Category: Standards Track
	ISSN: 2070-1721	ISSN: 2070-1721

	Use of Voluntary Application Server Identification (VAPID) in JSON Meta	Use of Voluntary Application Server Identification (VAPID) in JSON Meta

	Application Protocol (JMAP) WebPush	Application Protocol (JMAP) Web Push

	Abstract	Abstract

	This document defines a method for JSON Meta Application Protocol	This document defines a method for JSON Meta Application Protocol

	(JMAP) servers to advertise their capability to authenticate WebPush	(JMAP) servers to advertise their capability to authenticate Web Push
	notifications using the Voluntary Application Server Identification	notifications using the Voluntary Application Server Identification
	(VAPID) protocol.	(VAPID) protocol.

	Status of This Memo	Status of This Memo

	This is an Internet Standards Track document.	This is an Internet Standards Track document.

	This document is a product of the Internet Engineering Task Force	This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has	(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the	received public review and has been approved for publication by the

	skipping to change at line 64 ¶	skipping to change at line 64 ¶
	7. IANA Considerations	7. IANA Considerations
	7.1. Registration of the JMAP Capability for VAPID	7.1. Registration of the JMAP Capability for VAPID
	8. References	8. References
	8.1. Normative References	8.1. Normative References
	8.2. Informative References	8.2. Informative References
	Author's Address	Author's Address

	1. Introduction	1. Introduction

	JMAP [RFC8620] specifies how clients can subscribe to events using a	JMAP [RFC8620] specifies how clients can subscribe to events using a

	protocol that is compatible with WebPush [RFC8030]. Some push	protocol that is compatible with Web Push [RFC8030]. Some push
	services require that the application server authenticate all push	services require that the application server authenticate all push
	messages using the VAPID protocol [RFC8292]. To facilitate that, the	messages using the VAPID protocol [RFC8292]. To facilitate that, the

	client (or user agent in WebPush terminology) needs the VAPID public	client (or user agent in Web Push terminology) needs the VAPID public
	key of the application server to pass it along to the push service	key of the application server to pass along to the push service when
	when retrieving a new endpoint.	retrieving a new endpoint.

	2. Conventions Used in This Document	2. Conventions Used in This Document

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	3. Discovering Support for VAPID	3. Discovering Support for VAPID

	The JMAP capabilities object is returned as part of the standard JMAP	The JMAP capabilities object is returned as part of the standard JMAP
	session object (see Section 2 of [RFC8620]). Servers supporting this	session object (see Section 2 of [RFC8620]). Servers supporting this
	specification MUST add a property called	specification MUST add a property called

	"urn:ietf:params:jmap:webpush-vapid" to the capabilities object. The	urn:ietf:params:jmap:webpush-vapid to the capabilities object. The
	value of this property is an object that MUST contain the following	value of this property is an object that MUST contain the following
	information:	information:


	* applicationServerKey: "String"	applicationServerKey: "String"

	The Elliptic Curve Digital Signature Algorithm (ECDSA) public key	The Elliptic Curve Digital Signature Algorithm (ECDSA) public key
	that the push service will use to authenticate the application	that the push service will use to authenticate the application

	server, in its uncompressed form (as described in Annex A of	server, in its uncompressed form (as described in Section 2.3.3 of
	[X9.62]) and encoded using base64url encoding [RFC7515]. Current	[SEC1]) and encoded using base64url encoding [RFC7515]. Current
	systems use the P-256 curve [FIPS186].	systems use the P-256 curve [FIPS186].


	Informative Note: The format of the application server key was chosen	\| Informative Note: The format of the application server key was
	to ensure compatibility with the browser API (Section 7.2 of	\| chosen to ensure compatibility with the browser API
	[PUSH-API]), allowing the key to be directly copied and used without	\| (Section 7.2 of [PUSH-API]), allowing the key to be directly
	additional transformation. Additionally, as noted in Section 3.2 of	\| copied and used without additional transformation.
	[RFC8292], the X9.62 encoding simplifies key comparisons and is more	\| Additionally, as noted in Section 3.2 of [RFC8292], the X9.62
	compact than alternative formats.	\| encoding (which is compatible with SEC1 encoding) simplifies
		\| key comparisons and is more compact than alternative formats.

	4. Issuing Push Notifications	4. Issuing Push Notifications

	Every time the server sends a push message to a PushSubscription URL,	Every time the server sends a push message to a PushSubscription URL,
	it MUST authenticate the POST request using the protocol outlined in	it MUST authenticate the POST request using the protocol outlined in
	[RFC8292]. This includes both StateChange events and	[RFC8292]. This includes both StateChange events and
	PushVerification notifications. To authenticate the request, the	PushVerification notifications. To authenticate the request, the
	server MUST use a JSON Web Token (JWT) signed by the private key	server MUST use a JSON Web Token (JWT) signed by the private key
	corresponding to the application server key. This application server	corresponding to the application server key. This application server
	key MUST be the one that was advertised in the capabilities object at	key MUST be the one that was advertised in the capabilities object at

	skipping to change at line 174 ¶	skipping to change at line 174 ¶
	PushVerification object will not be delivered to the client.	PushVerification object will not be delivered to the client.

	To mitigate such issues, the client is responsible for detecting and	To mitigate such issues, the client is responsible for detecting and
	resolving any synchronization discrepancies, as outlined in Section 5	resolving any synchronization discrepancies, as outlined in Section 5
	of this document.	of this document.

	The inclusion of the urn:ietf:params:jmap:webpush-vapid property in	The inclusion of the urn:ietf:params:jmap:webpush-vapid property in
	the JMAP capabilities object is limited to providing information	the JMAP capabilities object is limited to providing information
	about the server's support for VAPID. This property does not reveal	about the server's support for VAPID. This property does not reveal
	sensitive information, nor does it introduce new security or privacy	sensitive information, nor does it introduce new security or privacy

	risks beyond those inherent to JMAP and WebPush. The security	risks beyond those inherent to JMAP and Web Push. The security
	considerations for JMAP [RFC8620] (especially Sections 8.6 and 8.7),	considerations for JMAP [RFC8620] (especially Sections 8.6 and 8.7),

	WebPush [RFC8030], and VAPID [RFC8292] apply to this document.	Web Push [RFC8030], and VAPID [RFC8292] apply to this document.

	7. IANA Considerations	7. IANA Considerations

	7.1. Registration of the JMAP Capability for VAPID	7.1. Registration of the JMAP Capability for VAPID

	IANA has registered the following new capability in the "JMAP	IANA has registered the following new capability in the "JMAP
	Capabilities" registry:	Capabilities" registry:

	Capability Name: urn:ietf:params:jmap:webpush-vapid	Capability Name: urn:ietf:params:jmap:webpush-vapid
	Intended Use: common	Intended Use: common
	Change Controller: IETF	Change Controller: IETF
	Security and Privacy Considerations: RFC 9749, Section 6	Security and Privacy Considerations: RFC 9749, Section 6
	Reference: RFC 9749	Reference: RFC 9749

	8. References	8. References

	8.1. Normative References	8.1. Normative References


	[FIPS186] NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-4,	[FIPS186] NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
	DOI 10.6028/NIST.FIPS.186-4, July 2013,	DOI 10.6028/NIST.FIPS.186-5, February 2023,
	<https://doi.org/10.6028/NIST.FIPS.186-4>.	<https://doi.org/10.6028/NIST.FIPS.186-5>.


	[X9.62] American National Standards Institute, "Public Key	[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
	Cryptography for the Financial Services Industry: The	Elliptic Curve Cryptography", Version 2.0, May 2009,
	Elliptic Curve Digital Signature Algorithm (ECDSA)",	<http://www.secg.org/sec1-v2.pdf>.
	ANSI X9.62-2005, November 2005.

	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
	2019, <https://www.rfc-editor.org/info/rfc8620>.	2019, <https://www.rfc-editor.org/info/rfc8620>.

	[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic	[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
	Event Delivery Using HTTP Push", RFC 8030,	Event Delivery Using HTTP Push", RFC 8030,
	DOI 10.17487/RFC8030, December 2016,	DOI 10.17487/RFC8030, December 2016,
	<https://www.rfc-editor.org/info/rfc8030>.	<https://www.rfc-editor.org/info/rfc8030>.


End of changes. 12 change blocks.
	26 lines changed or deleted	25 lines changed or added
This html diff was produced by rfcdiff 1.48.