idnits 2.17.1 draft-ietf-webpush-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 15, 2015) is 3116 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP-URI' == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-07 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBPUSH M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track E. Damaggio 5 Expires: April 17, 2016 B. Raymor, Ed. 6 Microsoft 7 October 15, 2015 9 Generic Event Delivery Using HTTP Push 10 draft-ietf-webpush-protocol-01 12 Abstract 14 A simple protocol for the delivery of realtime events to user agents 15 is described. This scheme uses HTTP/2 server push. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 17, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 5 55 3. Subscribing for Push Messages . . . . . . . . . . . . . . . . 6 56 4. Subscribing for Push Message Receipts . . . . . . . . . . . . 7 57 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 7 58 5.1. Requesting Push Message Receipts . . . . . . . . . . . . 8 59 5.2. Push Message Time-To-Live . . . . . . . . . . . . . . . . 8 60 6. Receiving Push Messages . . . . . . . . . . . . . . . . . . . 10 61 6.1. Acknowledging Push Messages . . . . . . . . . . . . . . . 11 62 6.2. Receiving Push Message Receipts . . . . . . . . . . . . . 11 63 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 64 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 12 65 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 13 66 7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 13 67 7.4. Implications for Application Reliability . . . . . . . . 14 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 8.1. Confidentiality from Push Service Access . . . . . . . . 14 70 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 15 71 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 72 8.4. Denial of Service Considerations . . . . . . . . . . . . 17 73 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 17 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 9.1. Header Field Registrations . . . . . . . . . . . . . . . 18 76 9.2. Link Relation URNs . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 11.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 82 A.1. Since draft-ietf-webpush-protocol-00 . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 85 1. Introduction 87 Many applications on mobile and embedded devices require continuous 88 access to network communications so that real-time events - such as 89 incoming calls or messages - can be delivered (or "pushed") in a 90 timely fashion. These devices typically have limited power reserves, 91 so finding more efficient ways to serve application requirements 92 greatly benefits the application ecosystem. 94 One significant contributor to power usage is the radio. Radio 95 communications consume a significant portion of the energy budget on 96 a wireless device. 98 Uncoordinated use of persistent connections or sessions from multiple 99 applications can contribute to unnecessary use of the device radio, 100 since each independent session independently incurs overheads. In 101 particular, keep alive traffic used to ensure that middleboxes do not 102 prematurely time out sessions, can result in significant waste. 103 Maintenance traffic tends to dominate over the long term, since 104 events are relatively rare. 106 Consolidating all real-time events into a single session ensures more 107 efficient use of network and radio resources. A single service 108 consolidates all events, distributing those events to applications as 109 they arrive. This requires just one session, avoiding duplicated 110 overhead costs. 112 The W3C Web Push API [API] describes an API that enables the use of a 113 consolidated push service from web applications. This expands on 114 that work by describing a protocol that can be used to: 116 o request the delivery of a push message to a user agent, 118 o create new push message delivery subscriptions, and 120 o monitor for new push messages. 122 Requesting the delivery of events is particularly important for the 123 Web Push API. The subscription, management and monitoring functions 124 are currently fulfilled by proprietary protocols; these are adequate, 125 but do not offer any of the advantages that standardization affords. 127 This document intentionally does not describe how a push service is 128 discovered. Discovery of push services is left for future efforts, 129 if it turns out to be necessary at all. User agents are expected to 130 be configured with a URL for a push service. 132 1.1. Conventions and Terminology 134 In cases where normative language needs to be emphasized, this 135 document falls back on established shorthands for expressing 136 interoperability requirements on implementations: the capitalized 137 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 138 is described in [RFC2119]. 140 This document defines the following terms: 142 application: Both the sender and ultimate consumer of push messages. 143 Many applications have components that are run on a user agent and 144 other components that run on servers. 146 application server: The component of an application that runs on a 147 server and requests the delivery of a push message. 149 push message subscription: A message delivery context that is 150 established between the user agent and the push service and shared 151 with the application server. All push messages are associated 152 with a push message subscription. 154 push message: A message sent from an application server to a user 155 agent via a push service. 157 push message receipt: A message delivery confirmation sent from the 158 push service to the application server. 160 push service: A service that delivers push messages to user agents. 162 user agent: A device and software that is the recipient of push 163 messages. 165 Examples in this document use the HTTP/1.1 message format [RFC7230]. 166 Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 167 is necessary, the more verbose frame format from [RFC7540] is used. 169 2. Overview 171 A general model for push services includes three basic actors: a user 172 agent, a push service, and an application (server). 174 +-------+ +--------------+ +-------------+ 175 | UA | | Push Service | | Application | 176 +-------+ +--------------+ +-------------+ 177 | | | 178 | Subscribe | | 179 |--------------------->| | 180 | Monitor | | 181 |<====================>| | 182 | | | 183 | Distribute Push Resource | 184 |-------------------------------------------->| 185 | | | 186 : : : 187 | | Push Message | 188 | Push Message |<---------------------| 189 |<---------------------| | 190 | | | 192 At the very beginning of the process, a new message subscription is 193 created by the user agent and then distributed to its application 194 server. This subscription is the basis of all future interactions 195 between the actors. 197 To offer more control for authorization, a message subscription is 198 modeled as two resources with different capabilities: 200 o A subscription resource is used to receive messages from a 201 subscription and to delete a subscription. It is private to the 202 user agent. 204 o A push resource is used to send messages to a subscription. It is 205 public and shared by the user agent with its application server. 207 It is expected that a unique subscription will be distributed to each 208 application; however, there are no inherent cardinality constraints 209 in the protocol. Multiple subscriptions might be created for the 210 same application, or multiple applications could use the same 211 subscription. Note however that sharing subscriptions has security 212 and privacy implications. 214 Subscriptions have a limited lifetime. They can also be terminated 215 by either the push service or user agent at any time. User agents 216 and application servers must be prepared to manage changes in 217 subscription state. 219 2.1. HTTP Resources 221 This protocol uses HTTP resources [RFC7230] and link relations 222 [RFC5988]. The following resources are defined: 224 push service: This resource is used to create push message 225 subscriptions (see Section 3). A URL for the push service is 226 configured into user agents. 228 push message subscription: This resource provides read and delete 229 access for a message subscription. A user agent receives push 230 messages (Section 6) using a push message subscription. Every 231 push message subscription has exactly one push resource associated 232 with it. 234 push: A push resource is used by the application server to request 235 the delivery of a push message (see Section 5). A link relation 236 of type "urn:ietf:params:push" is used to identify a push 237 resource. 239 push message: A push message resource is created to identify push 240 messages that have been accepted by the push service. The push 241 message resource is also used to acknowledge receipt of a push 242 message. 244 receipt subscribe: A receipt subscribe resource is used by an 245 application server to create a receipt subscription (see 246 Section 4). A link relation of type 247 "urn:ietf:params:push:receipt" is used to identity a receipt 248 subscribe resource. 250 receipt subscription: An application server receives delivery 251 confirmations (Section 5.1) for push messages using a receipt 252 subscription. 254 3. Subscribing for Push Messages 256 A user agent sends a POST request to its configured push service 257 resource to create a new subscription. 259 POST /subscribe/ HTTP/1.1 260 Host: push.example.net 262 A response with a 201 (Created) status code includes a URI for a new 263 push message subscription resource in the Location header field. 265 The push service MUST provide a URI for the push resource 266 corresponding to the push message subscription using a link relation 267 of type "urn:ietf:params:push". 269 The push service MUST provide a URI for a receipt subscribe resource 270 in a link relation of type "urn:ietf:params:push:receipt". 272 An application-specific method is used to distribute the push and 273 receipt subscribe URIs to the application server. Confidentiality 274 protection and application server authentication MUST be used to 275 ensure that these URIs are not disclosed to unauthorized recipients 276 (see Section 8.3). 278 HTTP/1.1 201 Created 279 Date: Thu, 11 Dec 2014 23:56:52 GMT 280 Link:

; 281 rel="urn:ietf:params:push" 282 Link: ; 283 rel="urn:ietf:params:push:receipt" 284 Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 286 4. Subscribing for Push Message Receipts 288 An application server requests the creation of a receipt subscription 289 by sending a HTTP POST request to the receipt subscribe resource 290 distributed to the application server by a user agent. 292 POST /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ HTTP/1.1 293 Host: push.example.net 295 A successful response with a 201 (Created) status code includes a URI 296 for the receipt subscription resource in the Location header field. 298 HTTP/1.1 201 Created 299 Date: Thu, 11 Dec 2014 23:56:52 GMT 300 Location: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN 302 An application server that sends push messages to a large population 303 of user agents incurs a significant load if it has to monitor a 304 receipt subscription for each user agent. Reuse of receipt 305 subscriptions is critical in reducing load on application servers. A 306 receipt subscription can be used for all resources that have the same 307 receipt subscribe URI. 309 A push service SHOULD provide the same receipt subscribe URI to all 310 user agents. Application servers SHOULD reuse receipt subscription 311 URIs if the receipt subscribe URI provided with the push resource is 312 identical to the one used to create the receipt subscription. 313 Checking that the receipt subscribe URI is identical allows the 314 application server to avoid creating unnecessary receipt 315 subscriptions. 317 5. Requesting Push Message Delivery 319 An application server requests the delivery of a push message by 320 sending a HTTP request to a push resource distributed to the 321 application server by a user agent. The push message is included in 322 the body of the request. 324 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 325 Host: push.example.net 326 Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN 327 Content-Type: text/plain;charset=utf8 328 Content-Length: 36 330 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 332 A 201 (Created) response indicates that the push message was 333 accepted. A URI for the push message resource that was created in 334 response to the request is included in the Location header field. 335 This does not indicate that the message was delivered to the user 336 agent. 338 HTTP/1.1 201 Created 339 Date: Thu, 11 Dec 2014 23:56:55 GMT 340 Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 342 A push service MAY generate a 413 (Payload Too Large) status code in 343 response to requests that include an entity body that is too large. 344 Push services MUST NOT generate a 413 status code in responses to an 345 entity body that is 4k (4096 bytes) or less in size. 347 5.1. Requesting Push Message Receipts 349 An application server can use the Push-Receipt header field to 350 request a confirmation from the push service when a push message is 351 delivered and acknowledged by the user agent. The Push-Receipt 352 header field is a URI-Reference as defined in Section 2.7 of 353 [RFC7230]. 355 Push-Receipt = URI-reference 357 The application sets the Push-Receipt header field value to a receipt 358 subscription URI. This receipt subscription resource MUST be created 359 from the same receipt subscribe resource which was returned with the 360 push message subscription response (see Section 3). 362 5.2. Push Message Time-To-Live 364 A push service can improve the reliability of push message delivery 365 considerably by storing push messages for a period. User agents are 366 often only intermittently connected, and so benefit from having short 367 term message storage at the push service. 369 Delaying delivery might also be used to batch communication with the 370 user agent, thereby conserving radio resources. 372 Some push messages are not useful once a certain period of time 373 elapses. Delivery of messages after they have ceased to be relevant 374 is wasteful. For example, if the push message contains a call 375 notification, receiving a message after the caller has abandoned the 376 call is of no value; the application at the user agent is forced to 377 suppress the message so that it does not generate a useless alert. 379 An application server can use the TTL header field to limit the time 380 that a push message is retained by a push service. The TTL header 381 field contains a value in seconds that describes how long a push 382 message is retained by the push service. 384 TTL = 1*DIGIT 386 Once the Time-To-Live (TTL) period elapses, the push service MUST NOT 387 attempt to deliver the push message to the user agent. A push 388 service might adjust the TTL value to account for time accounting 389 errors in processing. For instance, distributing a push message 390 within a server cluster might accrue errors due to clock skew or 391 propagation delays. 393 A push service is not obligated to account for time spent by the 394 application server in sending a push message to the push service, or 395 delays incurred while sending a push message to the user agent. An 396 application server needs to account for transit delays in selecting a 397 TTL header field value. 399 Absence of the TTL header field is interpreted as equivalent to a 400 zero value. A Push message with a zero TTL is immediately delivered 401 if the user agent is available to receive the message. After 402 delivery, the push service is permitted to immediately remove a push 403 message with a zero TTL. This might occur before the user agent 404 acknowledges receipt of the message by performing a HTTP DELETE on 405 the push message resource. Consequently, an application server 406 cannot rely on receiving acknowledgement receipts for zero TTL push 407 messages. 409 If the user agent is unavailable, a push message with a zero TTL 410 expires and is never delivered. 412 A push service MAY choose to retain a push message for a shorter 413 duration than that requested. It indicates this by including a TTL 414 header field in the response that includes the actual TTL. This TTL 415 value MUST be less than or equal to the value provided by the 416 application server. 418 6. Receiving Push Messages 420 A user agent requests the delivery of new push messages by making a 421 GET request to a push message subscription resource. The push 422 service does not respond to this request, it instead uses HTTP/2 423 server push [RFC7540] to send the contents of push messages as they 424 are sent by application servers. 426 Each push message is pushed in response to a synthesized GET request. 427 The GET request is made to the push message resource that was created 428 by the push service when the application server requested message 429 delivery. The response body is the entity body from the most recent 430 request sent to the push resource. 432 The following example request is made over HTTP/2. 434 HEADERS [stream 7] +END_STREAM +END_HEADERS 435 :method = GET 436 :path = /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 437 :authority = push.example.net 439 The push service permits the request to remain outstanding. When a 440 push message is sent by an application server, a server push is 441 associated with the initial request. The response includes the push 442 message. 444 PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS 445 :method = GET 446 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 447 :authority = push.example.net 449 HEADERS [stream 4] +END_HEADERS 450 :status = 200 451 date = Thu, 11 Dec 2014 23:56:56 GMT 452 last-modified = Thu, 11 Dec 2014 23:56:55 GMT 453 cache-control = private 454 content-type = text/plain;charset=utf8 455 content-length = 36 457 DATA [stream 4] +END_STREAM 458 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 460 In response to this request, the push service MUST generate a server 461 push for all push messages that have not yet been delivered. In 462 addition, the push service SHOULD return link references to the push 463 and receipt subscribe resources. 465 A user agent can request the contents of the push message 466 subscription resource immediately by including a Prefer header field 467 [RFC7240] with a "wait" parameter set to "0". 469 A 204 (No Content) status code with no associated server pushes 470 indicates that no messages are presently available. This could be 471 because push messages have expired. 473 6.1. Acknowledging Push Messages 475 To ensure that a push message is properly delivered to the user agent 476 at least once, the user agent MUST acknowledge receipt of the message 477 by performing a HTTP DELETE on the push message resource. 479 DELETE /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk HTTP/1.1 480 Host: push.example.net 482 If the push service receives the acknowledgement and the application 483 has requested a delivery receipt, the push service MUST deliver a 484 success response to the application server monitoring the receipt 485 subscription resource. 487 If the push service does not receive the acknowledgement within a 488 reasonable amount of time, then the message is considered to be not 489 yet delivered. The push service SHOULD continue to retry delivery of 490 the message until its advertised expiration. 492 The push service MAY cease to retry delivery of the message prior to 493 its advertised expiration due to scenarios such as an unresponsive 494 user agent or operational constraints. If the application has 495 requested a delivery receipt, then the push service MUST deliver a 496 failure response to the application server monitoring the receipt 497 subscription resource. 499 6.2. Receiving Push Message Receipts 501 The application server requests the delivery of receipts from the 502 push service by making a HTTP GET request to the receipt subscription 503 resource. The push service does not respond to this request, it 504 instead uses HTTP/2 server push [RFC7540] to send push receipts when 505 messages are acknowledged (Section 6.1) by the user agent. 507 Each receipt is pushed in response to a synthesized GET request. The 508 GET request is made to the same push message resource that was 509 created by the push service when the application server requested 510 message delivery. A successful response includes a 410 (GONE) status 511 code with no data. 513 The following example request is made over HTTP/2. 515 HEADERS [stream 13] +END_STREAM +END_HEADERS 516 :method = GET 517 :path = /r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN 518 :authority = push.example.net 520 The push service permits the request to remain outstanding. When the 521 user agent acknowledges the message, the push service pushes a 522 delivery receipt to the application server. A 410 (Gone) status code 523 confirms that the message was delivered and acknowledged. 525 PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS 526 :method = GET 527 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 528 :authority = push.example.net 530 HEADERS [stream 4] +END_STREAM 531 +END_HEADERS 532 :status = 410 533 date = Thu, 11 Dec 2014 23:56:56 GMT 535 If the user agent fails to acknowledge the receipt of the push 536 message and the push service ceases to retry delivery of the message 537 prior to its advertised expiration, then the push service MUST push a 538 failure response with a status code of 5XX (TBD). 540 7. Operational Considerations 542 A push service is likely to have to maintain a very large number of 543 open TCP connections. Effective management of those connections can 544 depend on being able to move connections between server instances. 546 7.1. Load Management 548 A user agent MUST support the 307 (Temporary Redirect) status code 549 [RFC7231], which can be used by a push service to redistribute load 550 at the time that a new subscription is requested. 552 A server that wishes to redistribute load can do so using alternative 553 services [I-D.ietf-httpbis-alt-svc]. Alternative services allows for 554 redistribution of load whilst maintaining the same URIs for various 555 resources. User agents can ensure a graceful transition by using the 556 GOAWAY frame once it has established a replacement connection. 558 7.2. Push Message Expiration 560 Storage of push messages based on the TTL header field comprises a 561 potentially significant amount of storage for a push service. A push 562 service is not obligated to store messages indefinitely. A push 563 service is able to indicate how long it intends to retain a message 564 to an application server using the TTL header field (see 565 Section 5.2). 567 A user agent that does not actively monitor for push messages will 568 not receive messages that expire during that interval. 570 Push messages that are stored and not delivered to a user agent are 571 delivered when the user agent recommences monitoring. Stored push 572 messages SHOULD include a Last-Modified header field (see Section 2.2 573 of [RFC7232]) indicating when delivery was requested by an 574 application server. 576 A GET request to a push message subscription resource that has only 577 expired messages results in response as though no push message were 578 ever sent. 580 Push services might need to limit the size and number of stored push 581 messages to avoid overloading. To limit the size of messages, the 582 push service MAY return the 413 (Payload Too Large) status code for 583 messages that are too large. To limit the number of stored push 584 messages, the push service MAY either expire messages prior to their 585 advertised Time-To-Live or reduce their advertised Time-To-Live. 587 7.3. Subscription Expiration 589 In some cases, it may be necessary to terminate subscriptions so that 590 they can be refreshed. This applies to both push message 591 subscriptions and receipt subscriptions. 593 A push service can remove a subscription at any time. If a user 594 agent or application server has an outstanding request to a 595 subscription resource (see Section 6), this can be signaled by 596 returning a 400-series status code, such as 410 (Gone). 598 A user agent or application server can request that a subscription be 599 removed by sending a DELETE request to the push message subscription 600 or receipt subscription URI. 602 A push service MUST return a 400-series status code, such as 404 (Not 603 Found) or 410 (Gone) if an application server attempts to send a push 604 message to a removed or expired push message subscription. 606 7.4. Implications for Application Reliability 608 A push service that does not support reliable delivery over 609 intermittent network connections or failing applications on devices, 610 forces the device to acknowledge receipt directly to the application 611 server, incurring additional power drain in order to establish 612 (usually secure) connections to the individual application servers. 614 Push message reliability can be important if messages contain 615 information critical to the state of an application. Repairing state 616 can be costly, particularly for devices with limited communications 617 capacity. Knowing that a push message has been correctly received 618 avoids costly retransmissions, polling and state resynchronization. 620 The availability of push message delivery receipts ensures that the 621 application developer is not tempted to create alternative mechanisms 622 for message delivery in case the push service fails to deliver a 623 critical message. Setting up a polling mechanism or a backup 624 messaging channel in order to compensate for these shortcomings 625 negates almost all of the advantages a push service provides. 627 However, reliability might not be necessary for messages that are 628 transient (e.g. an incoming call) or messages that are quickly 629 superceded (e.g. the current number of unread emails). 631 8. Security Considerations 633 This protocol MUST use HTTP over TLS [RFC2818]. This includes any 634 communications between user agent and push service, plus 635 communications between the application and the push service. All 636 URIs therefore use the "https" scheme. This provides confidentiality 637 and integrity protection for subscriptions and push messages from 638 external parties. 640 8.1. Confidentiality from Push Service Access 642 The protection afforded by TLS does not protect content from the push 643 service. Without additional safeguards, a push service is able to 644 see and modify the content of the messages. 646 Applications are able to provide additional confidentiality, 647 integrity or authentication mechanisms within the push message 648 itself. The application server sending the push message and the 649 application on the user agent that receives it are frequently just 650 different instances of the same application, so no standardized 651 protocol is needed to establish a proper security context. The 652 process of providing the application server with subscription 653 information provides a convenient medium for key agreement. 655 The Web Push API codifies this practice by requiring that each push 656 subscription created by the browser be bound to a browser generated 657 encryption key. Pushed messages are authenticated and decrypted by 658 the browser before delivery to applications. This scheme ensures 659 that the push service is unable to examine the contents of push 660 messages. 662 The public key for a subscription ensures that applications using 663 that subscription can identify messages from unknown sources and 664 discard them. This depends on the public key only being disclosed to 665 entities that are authorized to send messages on the channel. The 666 push service does not require access to this public key. 668 8.2. Privacy Considerations 670 Push message confidentiality does not ensure that the identity of who 671 is communicating and when they are communicating is protected. 672 However, the amount of information that is exposed can be limited. 674 The URIs provided for push resources MUST NOT provide any basis to 675 correlate communications for a given user agent. It MUST NOT be 676 possible to correlate any two push resource URIs based solely on 677 their contents. This allows a user agent to control correlation 678 across different applications, or over time. 680 Similarly, the URIs provided by the push service to identify a push 681 message MUST NOT provide any information that allows for correlation 682 across subscriptions. Push message URIs for the same subscription 683 MAY contain information that would allow correlation with the 684 associated subscription or other push messages for that subscription. 686 User and device information MUST NOT be exposed through a push or 687 push message URI. 689 In addition, push URIs established by the same user agent or push 690 message URIs for the same subscription MUST NOT include any 691 information that allows them to be correlated with the user agent. 693 Note: This need not be perfect as long as the resulting anonymity 694 set (see [RFC6973], Section 6.1.1) is sufficiently large. A push 695 URI necessarily identifies a push service or a single server 696 instance. It is also possible that traffic analysis could be used 697 to correlate subscriptions. 699 A user agent MUST be able to create new subscriptions with new 700 identifiers at any time. 702 8.3. Authorization 704 This protocol does not define how a push service establishes whether 705 a user agent is permitted to create a subscription, or whether push 706 messages can be delivered to the user agent. A push service MAY 707 choose to authorize requests based on any HTTP-compatible 708 authorization method available, of which there are numerous options. 709 The authorization process and any associated credentials are expected 710 to be configured in the user agent along with the URI for the push 711 service. 713 Authorization is managed using capability URLs for the push message 714 subscription, push, and receipt subscription resources (see 715 [CAP-URI]). A capability URL grants access to a resource based 716 solely on knowledge of the URL. 718 Capability URLs are used for their "easy onward sharing" and "easy 719 client API" properties. These make it possible to avoid relying on 720 relationships between push services and application servers, with the 721 protocols necessary to build and support those relationships. 723 Capability URLs act as bearer tokens. Knowledge of a push message 724 subscription URI implies authorization to either receive push 725 messages or delete the subscription. Knowledge of a push URI implies 726 authorization to send push messages. Knowledge of a push message URI 727 allows for reading and acknowledging that specific message. 728 Knowledge of a receipt subscription URI implies authorization to 729 receive push receipts. Knowledge of a receipt subscribe URI implies 730 authorization to create subscriptions for receipts. 732 Note that the same receipt subscribe URI could be returned for 733 multiple push message subscriptions. Using the same value for a 734 large number of subscriptions allows application servers to reuse 735 receipt subscriptions, which can provide a significant efficiency 736 advantage. A push service that uses a common receipt subscribe URI 737 loses control over the creation of receipt subscriptions. This can 738 result in a potential exposure to denial of service; stateless 739 resource creation can be used to mitigate the effects of this 740 exposure. 742 Encoding a large amount of random entropy (at least 120 bits) in the 743 path component ensures that it is difficult to successfully guess a 744 valid capability URL. 746 8.4. Denial of Service Considerations 748 Discarding unwanted messages at the user agent based on message 749 authentication doesn't protect against a denial of service attack on 750 the user agent. Even a relatively small volume of push messages can 751 cause battery-powered devices to exhaust power reserves. 753 An application can limit where valid push messages can originate by 754 limiting the distribution of push URIs to authorized entities. 755 Ensuring that push URIs are hard to guess ensures that only 756 application servers that have been given a push URI can use it. 758 A malicious application with a valid push URI could use the greater 759 resources of a push service to mount a denial of service attack on a 760 user agent. Push services SHOULD limit the rate at which push 761 messages are sent to individual user agents. A push service or user 762 agent MAY terminate subscriptions (Section 7.3) that receive too many 763 push messages. 765 End-to-end confidentiality mechanisms, such as those in [API], 766 prevent an entity with a valid push message subscription URI from 767 learning the contents of push messages. Push messages that are not 768 successfully authenticated will not be delivered by the API, but this 769 can present a denial of service risk. 771 Conversely, a push service is also able to deny service to user 772 agents. Intentional failure to deliver messages is difficult to 773 distinguish from faults, which might occur due to transient network 774 errors, interruptions in user agent availability, or genuine service 775 outages. 777 8.5. Logging Risks 779 Server request logs can reveal subscription-related URIs. Acquiring 780 a push message subscription URI enables the receipt of messages or 781 deletion of the subscription. Acquiring a push URI permits the 782 sending of push messages. Logging could also reveal relationships 783 between different subscription-related URIs for the same user agent. 784 Encrypted message contents are not revealed to the push service. 786 Limitations on log retention and strong access control mechanisms can 787 ensure that URIs are not learned by unauthorized entities. 789 9. IANA Considerations 791 This protocol defines new HTTP header fields in Section 9.1. New 792 link relation types are identified using the URNs defined in 793 Section 9.2. 795 9.1. Header Field Registrations 797 HTTP header fields are registered within the "Message Headers" 798 registry maintained at . 801 This document defines the following HTTP header fields, so their 802 associated registry entries shall be added according to the permanent 803 registrations below (see [RFC3864]): 805 +-------------------+----------+----------+--------------+ 806 | Header Field Name | Protocol | Status | Reference | 807 +-------------------+----------+----------+--------------+ 808 | TTL | http | standard | Section 5.2 | 809 | Push-Receipt | http | standard | Section 5.1 | 810 +-------------------+----------+----------+--------------+ 812 The change controller is: "IETF (iesg@ietf.org) - Internet 813 Engineering Task Force". 815 9.2. Link Relation URNs 817 This document registers URNs for use in identifying link relation 818 types. These are added to a new "Web Push Identifiers" registry 819 according to the procedures in Section 4 of [RFC3553]; the 820 corresponding "push" sub-namespace is entered in the "IETF URN Sub- 821 namespace for Registered Protocol Parameter Identifiers" registry. 823 The "Web Push Identifiers" registry operates under the IETF Review 824 policy [RFC5226]. 826 Registry name: Web Push Identifiers 828 URN Prefix: urn:ietf:params:push 830 Specification: (this document) 832 Repository: [Editor/IANA note: please include a link to the final 833 registry location.] 835 Index value: Values in this registry are URNs or URN prefixes that 836 start with the prefix "urn:ietf:params:push". Each is registered 837 independently. 839 New registrations in the "Web Push Identifiers" are encouraged to 840 include the following information: 842 URN: A complete URN or URN prefix. 844 Description: A summary description. 846 Specification: A reference to a specification describing the 847 semantics of the URN or URN prefix. 849 Contact: Email for the person or group making the registration. 851 Index value: As described in [RFC3553], URN prefixes that are 852 registered include a description of how the URN is constructed. 853 This is not applicable for specific URNs. 855 These values are entered as the initial content of the "Web Push 856 Identifiers" registry. 858 URN: urn:ietf:params:push 860 Description: This link relation type is used to identify a resource 861 for sending push messages. 863 Specification: (this document) 865 Contact: The Web Push WG (webpush@ietf.org) 867 URN: urn:ietf:params:push:receipt 869 Description: This link relation type is used to identify a resource 870 for creating new push message receipt subscriptions. 872 Specification: (this document) 874 Contact: The Web Push WG (webpush@ietf.org) 876 10. Acknowledgements 878 Significant technical input to this document has been provided by 879 Costin Manolache, Robert Sparks, Mark Nottingham, Matthew Kaufman and 880 many others. 882 11. References 884 11.1. Normative References 886 [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD 887 capability-urls, February 2014, 888 . 890 [I-D.ietf-httpbis-alt-svc] 891 Nottingham, M., McManus, P., and J. Reschke, "HTTP 892 Alternative Services", draft-ietf-httpbis-alt-svc-07 (work 893 in progress), May 2015. 895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 896 Requirement Levels", BCP 14, RFC 2119, March 1997. 898 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 900 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 901 IETF URN Sub-namespace for Registered Protocol 902 Parameters", BCP 73, RFC 3553, June 2003. 904 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 905 Procedures for Message Header Fields", BCP 90, RFC 3864, 906 September 2004. 908 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 909 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 910 May 2008. 912 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 914 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 915 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 916 2014. 918 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 919 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 921 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 922 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 924 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 926 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 927 Protocol Version 2", RFC 7540, May 2015. 929 11.2. Informative References 931 [API] Sullivan, B., Fullea, E., and M. van Ouwerkerk, "Web Push 932 API", ED push-api, February 2015, . 935 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 936 Morris, J., Hansen, M., and R. Smith, "Privacy 937 Considerations for Internet Protocols", RFC 6973, July 938 2013. 940 Appendix A. Change Log 942 [[The RFC Editor is requested to remove this section at 943 publication.]] 945 A.1. Since draft-ietf-webpush-protocol-00 947 Editorial changes for Push Message Time-To-Live 949 Editorial changes for Push Acknowledgements 951 Removed subscription expiration based on HTTP cache headers 953 Authors' Addresses 955 Martin Thomson 956 Mozilla 957 331 E Evelyn Street 958 Mountain View, CA 94041 959 US 961 Email: martin.thomson@gmail.com 963 Elio Damaggio 964 Microsoft 965 One Microsoft Way 966 Redmond, WA 98052 967 US 969 Email: elioda@microsoft.com 970 Brian Raymor (editor) 971 Microsoft 972 One Microsoft Way 973 Redmond, WA 98052 974 US 976 Email: brian.raymor@microsoft.com