idnits 2.17.1 draft-thomson-webpush-protocol-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 15, 2015) is 3300 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) -- Looks like a reference, but probably isn't: '1' on line 929 -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP-URI' == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-06 ** 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 7234 (Obsoleted by RFC 9111) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: October 17, 2015 B. Raymor 6 Microsoft 7 April 15, 2015 9 Generic Event Delivery Using HTTP Push 10 draft-thomson-webpush-protocol-00 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 October 17, 2015. 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. Header Field Registrations . . . . . . . . . . . . . . . 18 76 9.2. Link Relation URNs . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 11.2. Informative References . . . . . . . . . . . . . . . . . 21 81 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 Many applications on mobile and embedded devices require continuous 87 access to network communications so that real-time events - such as 88 incoming calls or messages - can be delivered (or "pushed") in a 89 timely fashion. These devices typically have limited power reserves, 90 so finding more efficient ways to serve application requirements 91 greatly benefits the application ecosystem. 93 One significant contributor to power usage is the radio. Radio 94 communications consume a significant portion of the energy budget on 95 a wireless device. 97 Uncoordinated use of persistent connections or sessions from multiple 98 applications can contribute to unnecessary use of the device radio, 99 since each independent session independently incurs overheads. In 100 particular, keep alive traffic used to ensure that middleboxes do not 101 prematurely time out sessions, can result in significant waste. 102 Maintenance traffic tends to dominate over the long term, since 103 events are relatively rare. 105 Consolidating all real-time events into a single session ensures more 106 efficient use of network and radio resources. A single service 107 consolidates all events, distributing those events to applications as 108 they arrive. This requires just one session, avoiding duplicated 109 overhead costs. 111 The W3C Web Push API [API] describes an API that enables the use of a 112 consolidated push service from web applications. This expands on 113 that work by describing a protocol that can be used to: 115 o request the delivery of a push message to a user agent, 117 o create new push message delivery subscriptions, and 119 o monitor for new push messages. 121 Requesting the delivery of events is particularly important for the 122 Web Push API. The subscription, management and monitoring functions 123 are currently fulfilled by proprietary protocols; these are adequate, 124 but do not offer any of the advantages that standardization affords. 126 This document intentionally does not describe how a push service is 127 discovered. Discovery of push services is left for future efforts, 128 if it turns out to be necessary at all. User agents are expected to 129 be configured with a URL for a push service. 131 1.1. Conventions and Terminology 133 In cases where normative language needs to be emphasized, this 134 document falls back on established shorthands for expressing 135 interoperability requirements on implementations: the capitalized 136 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 137 is described in [RFC2119]. 139 This document defines the following terms: 141 application: Both the sender and ultimate consumer of push messages. 142 Many applications have components that are run on a user agent and 143 other components that run on servers. 145 application server: The component of an application that runs on a 146 server and requests the delivery of a push message. 148 push message subscription: A message delivery context that is 149 established between the user agent and the push service and shared 150 with the application server. All push messages are associated 151 with a push message subscription. 153 push message: A message sent from an application server to a user 154 agent via a push service. 156 push message receipt: A message delivery confirmation sent from the 157 push server to the application server. 159 push service: A service that delivers push messages to user agents. 161 user agent: A device and software that is the recipient of push 162 messages. 164 Examples in this document use the HTTP/1.1 message format [RFC7230]. 165 Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 166 is necessary, the more verbose frame format from 167 [I-D.ietf-httpbis-http2] 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 server 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 server 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 285 Cache-Control: max-age:864000, private 287 4. Subscribing for Push Message Receipts 289 An application server requests the creation of a receipt subscription 290 by sending a HTTP POST request to the receipt subscribe resource 291 distributed to the application server by a user agent. 293 POST /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ HTTP/1.1 294 Host: push.example.net 296 A successful response with a 201 (Created) status code includes a URI 297 for the receipt subscription resource in the Location header field. 299 HTTP/1.1 201 Created 300 Date: Thu, 11 Dec 2014 23:56:52 GMT 301 Location: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN 303 A push service SHOULD provide the same receipt subscribe URI to user 304 agents. An application MAY reuse a receipt subscription resource 305 with a push message request if the receipt subscribe URI provided 306 with the push resource is identical to the one used to create the 307 receipt subscription. 309 5. Requesting Push Message Delivery 311 An application server requests the delivery of a push message by 312 sending a HTTP request to a push resource distributed to the 313 application server by a user agent. The push message is included in 314 the body of the request. 316 POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 317 Host: push.example.net 318 Content-Type: text/plain;charset=utf8 319 Content-Length: 36 321 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 323 A 201 (Created) response indicates that the push message was 324 accepted. A URI for the push message resource that was created in 325 response to the request is included in the Location header field. 326 This does not indicate that the message was delivered to the user 327 agent. 329 HTTP/1.1 201 Created 330 Date: Thu, 11 Dec 2014 23:56:55 GMT 331 Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 333 A push service MAY generate a 413 (Payload Too Large) status code in 334 response to requests that include an entity body that is too large. 335 Push services MUST NOT generate a 413 status code in responses to an 336 entity body that is 4k (4096 bytes) or less in size. 338 5.1. Requesting Push Message Receipts 340 An application server can use the Push-Receipt header field to 341 request a confirmation from the push server when a push message is 342 delivered and acknowledged by the user agent. The Push-Receipt 343 header field is a URI-Reference as defined in Section 2.7 of 344 [RFC7230]. 346 Push-Receipt = URI-reference 348 The application sets the Push-Receipt header field value to a receipt 349 subscription URI. This receipt subscription resource MUST be created 350 from the same receipt subscribe resource which was returned with the 351 push message subscription response (see Section 3). 353 5.2. Push Message Time-To-Live 355 A push service can improve the reliability of push message delivery 356 considerably by storing push messages for a period. User agents are 357 often only intermittently connected, and so benefit from having short 358 term message storage at the push service. 360 Delaying delivery might also be used to batch communication with the 361 user agent, thereby conserving radio resources. 363 Some push messages are not useful once a certain period of time 364 elapses. Delivery of messages after they have ceased to be relevant 365 is wasteful. For example, if the push message contains a call 366 notification, receiving a message after the caller has abandoned the 367 call is of no value; the application at the user agent is forced to 368 suppress the message so that it does not generate a useless alert. 370 An application server can use the TTL header field to limit the time 371 that a push message is retained by a push service. The TTL header 372 field contains a value in seconds that describes how long a push 373 message is retained by the push service. 375 TTL = 1*DIGIT 377 Once the Time-To-Live (TTL) period elapses, the push service MUST 378 remove the push message and cease any attempt to deliver it to the 379 user agent. A push service might retain values for a short duration 380 after the TTL period to account for time accounting errors in 381 processing. For instance, distributing a push message within a 382 server cluster might accrue errors due to clock variation, or 383 processing and transit delays. 385 A push service is not obligated to account for time spent by the 386 application server in sending a push message to the push service, or 387 delays incurred while sending a push message to the user agent. An 388 application server needs to account for transit delays in selecting a 389 TTL header field value. 391 Absence of the TTL header field is interpreted as equivalent to a 392 zero value. Push messages with a zero TTL indicate that storage is 393 not needed and that the message can be dropped if the user agent 394 isn't immediately available to receive the message. Push messages 395 with a zero TTL can be delivered very efficiently. 397 A push service MAY choose to retain a push message for a shorter 398 duration than that requested. It indicates this by including a TTL 399 header field in the response that includes the actual TTL. This TTL 400 value MUST be less than or equal to the value provided by the 401 application server. 403 6. Receiving Push Messages 405 A user agent requests the delivery of new push messages by making a 406 GET request to a push message subscription resource. The push 407 service does not respond to this request, it instead uses HTTP/2 408 server push [I-D.ietf-httpbis-http2] to send the contents of push 409 messages as they are sent by application servers. 411 Each push message is pushed in response to a synthesized GET request. 412 The GET request is made to the push message resource that was created 413 by the push server when the application server requested message 414 delivery. The response body is the entity body from the most recent 415 request sent to the push resource. 417 The following example request is made over HTTP/2. 419 HEADERS [stream 7] +END_STREAM +END_HEADERS 420 :method = GET 421 :path = /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 422 :authority = push.example.net 424 The push service permits the request to remain outstanding. When a 425 push message is sent by an application server, a server push is 426 associated with the initial request. The response includes the push 427 message. 429 PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS 430 :method = GET 431 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 432 :authority = push.example.net 434 HEADERS [stream 4] +END_HEADERS 435 :status = 200 436 date = Thu, 11 Dec 2014 23:56:56 GMT 437 last-modified = Thu, 11 Dec 2014 23:56:55 GMT 438 cache-control = private 439 content-type = text/plain;charset=utf8 440 content-length = 36 442 DATA [stream 4] +END_STREAM 443 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 445 A user agent can request the contents of the push message 446 subscription resource immediately by including a Prefer header field 447 [RFC7240] with a "wait" parameter set to "0". In response to this 448 request, the push service SHOULD return link references to the push 449 and receipt subscribe resources, plus expiration information. In 450 response to this request, the push server MUST generate a server push 451 for all push messages that have not yet been delivered. 453 A 204 (No Content) status code with no associated server pushes 454 indicates that no messages are presently available. This could be 455 because push messages have expired. 457 6.1. Acknowledging Push Messages 459 To ensure that a push message is properly delivered to the user agent 460 at least once, the user agent MUST acknowledge receipt of the message 461 by performing a HTTP DELETE on the push message resource. 463 DELETE /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk HTTP/1.1 464 Host: push.example.net 466 If the application has requested a delivery receipt, the push server 467 MUST deliver a response to the application server monitoring the 468 receipt subscription resource. 470 6.2. Receiving Push Message Receipts 472 The application server requests the delivery of receipts from the 473 push server by making a HTTP GET request to the receipt subscription 474 resource. The push service does not respond to this request, it 475 instead uses HTTP/2 server push [I-D.ietf-httpbis-http2] to send push 476 receipts when messages are acknowledged (Section 6.1) by the user 477 agent. 479 Each receipt is pushed in response to a synthesized GET request. The 480 GET request is made to the same push message resource that was 481 created by the push server when the application server requested 482 message delivery. A successful response includes a 410 (GONE) status 483 code with no data. 485 The following example request is made over HTTP/2. 487 HEADERS [stream 13] +END_STREAM +END_HEADERS 488 :method = GET 489 :path = /r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN 490 :authority = push.example.net 492 The push service permits the request to remain outstanding. When the 493 user agent acknowledges the message, the push server pushes a 494 delivery receipt to the application server. A 410 (Gone) status code 495 confirms that the message was delivered and acknowledged. 497 PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS 498 :method = GET 499 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 500 :authority = push.example.net 502 HEADERS [stream 4] +END_STREAM 503 +END_HEADERS 504 :status = 410 505 date = Thu, 11 Dec 2014 23:56:56 GMT 507 The push server MUST push a response with a status code of 5XX (TBD) 508 if the user agent fails to acknowledge the receipt of the push 509 message or the push server fails to deliver the message prior to its 510 expiration. 512 7. Operational Considerations 514 A push service is likely to have to maintain a very large number of 515 open TCP connections. Effective management of those connections can 516 depend on being able to move connections between server instances. 518 7.1. Load Management 520 A user agent MUST support the 307 (Temporary Redirect) status code 521 [RFC7231], which can be used by a push service to redistribute load 522 at the time that a new subscription is requested. 524 A server that wishes to redistribute load can do so using alternative 525 services [I-D.ietf-httpbis-alt-svc]. Alternative services allows for 526 redistribution of load whilst maintaining the same URIs for various 527 resources. User agents can ensure a graceful transition by using the 528 GOAWAY frame once it has established a replacement connection. 530 7.2. Push Message Expiration 532 Storage of push messages based on the TTL header field comprises a 533 potentially significant amount of storage for a push service. A push 534 service is not obligated to store messages indefinitely. A push 535 service is able to indicate how long it intends to retain a message 536 to an application server using the TTL header field (see 537 Section 5.2). 539 A user agent that does not actively monitor for push messages will 540 not receive messages that expire during that interval. 542 Push messages that are stored and not delivered to a user agent are 543 delivered when the user agent recommences monitoring. Stored push 544 messages SHOULD include a Last-Modified header field (see Section 2.2 545 of [RFC7232]) indicating when delivery was requested by an 546 application server. 548 A GET request to a push message subscription resource that has only 549 expired messages results in response as though no push message were 550 ever sent. 552 Push services might need to limit the size and number of stored push 553 messages to avoid overloading. In addition to using the 413 (Payload 554 Too Large) status code for too large push messages, a push service 555 MAY expire push messages prior to any advertised expiration time. A 556 push service can reduce the impact push message retention by reducing 557 the time-to-live of push messages. 559 7.3. Subscription Expiration 561 In some cases, it may be necessary to terminate subscriptions so that 562 they can be refreshed. This applies to both push message 563 subscriptions and receipt subscriptions. 565 A push service might choose to set a fixed expiration time. If a 566 resource has a known expiration time, expiration information is 567 included in responses to requests that create the resource, or in 568 requests that retrieve a representation of the resource. 570 Expiration is indicated using either the Expires header field, or by 571 setting a "max-age" parameter on a Cache-Control header field (see 572 [RFC7234]). The Cache-Control header field MUST also include the 573 "private" directive. 575 A push service can remove a subscription at any time. If a user 576 agent or application server has an outstanding request to a 577 subscription resource (see Section 6), this can be signaled by 578 returning a 400-series status code, such as 410 (Gone). 580 A user agent or application server can request that a subscription be 581 removed by sending a DELETE request to the push message subscription 582 or receipt subscription URI. 584 A push service MUST return a 400-series status code, such as 404 (Not 585 Found) or 410 (Gone) if an application server attempts to send a push 586 message to a removed or expired push message subscription. 588 7.4. Implications for Application Reliability 590 A push server that does not support reliable delivery over 591 intermittent network connections or failing applications on devices, 592 forces the device to acknowledge receipt directly to the application 593 server, incurring additional power drain in order to establish 594 (usually secure) connections to the individual application servers. 596 Push message reliability can be important if messages contain 597 information critical to the state of an application. Repairing state 598 can be costly, particularly for devices with limited communications 599 capacity. Knowing that a push message has been correctly received 600 avoids costly retransmissions, polling and state resynchronization. 602 The availability of push message delivery receipts ensures that the 603 application developer is not tempted to create alternative mechanisms 604 for message delivery in case the push service fails to deliver a 605 critical message. Setting up a polling mechanism or a backup 606 messaging channel in order to compensate for these shortcomings 607 negates almost all of the advantages a push service provides. 609 However, reliability might not be necessary for messages that are 610 transient (e.g. an incoming call) or messages that are quickly 611 superceded (e.g. the current number of unread emails). 613 8. Security Considerations 615 This protocol MUST use HTTP over TLS [RFC2818]. This includes any 616 communications between user agent and push service, plus 617 communications between the application and the push service. All 618 URIs therefore use the "https" scheme. This provides confidentiality 619 and integrity protection for subscriptions and push messages from 620 external parties. 622 8.1. Confidentiality from Push Service Access 624 The protection afforded by TLS does not protect content from the push 625 service. Without additional safeguards, a push service is able to 626 see and modify the content of the messages. 628 Applications are able to provide additional confidentiality, 629 integrity or authentication mechanisms within the push message 630 itself. The application server sending the push message and the 631 application on the user agent that receives it are frequently just 632 different instances of the same application, so no standardized 633 protocol is needed to establish a proper security context. The 634 process of providing the application server with subscription 635 information provides a convenient medium for key agreement. 637 The Web Push API codifies this practice by requiring that each push 638 subscription created by the browser be bound to a browser generated 639 encryption key. Pushed messages are authenticated and decrypted by 640 the browser before delivery to applications. This scheme ensures 641 that the push service is unable to examine the contents of push 642 messages. 644 The public key for a subscription ensures that applications using 645 that subscription can identify messages from unknown sources and 646 discard them. This depends on the public key only being disclosed to 647 entities that are authorized to send messages on the channel. The 648 push server does not require access to this public key. 650 8.2. Privacy Considerations 652 Push message confidentiality does not ensure that the identity of who 653 is communicating and when they are communicating is protected. 654 However, the amount of information that is exposed can be limited. 656 The URIs provided for push resources MUST NOT provide any basis to 657 correlate communications for a given user agent. It MUST NOT be 658 possible to correlate any two push resource URIs based solely on 659 their contents. This allows a user agent to control correlation 660 across different applications, or over time. 662 Similarly, the URIs provided by the push service to identify a push 663 message MUST NOT provide any information that allows for correlation 664 across subscriptions. Push message URIs for the same subscription 665 MAY contain information that would allow correlation with the 666 associated subscription or other push messages for that subscription. 668 User and device information MUST NOT be exposed through a push or 669 push message URI. 671 In addition, push URIs established by the same user agent or push 672 message URIs for the same subscription MUST NOT include any 673 information that allows them to be correlated with the user agent. 675 Note: This need not be perfect as long as the resulting anonymity 676 set (see [RFC6973], Section 6.1.1) is sufficiently large. A push 677 URI necessarily identifies a push service or a single server 678 instance. It is also possible that traffic analysis could be used 679 to correlate subscriptions. 681 A user agent MUST be able to create new subscriptions with new 682 identifiers at any time. 684 8.3. Authorization 686 This protocol does not define how a push service establishes whether 687 a user agent is permitted to create a subscription, or whether push 688 messages can be delivered to the user agent. A push service MAY 689 choose to authorize requests based on any HTTP-compatible 690 authorization method available, of which there are numerous options. 691 The authorization process and any associated credentials are expected 692 to be configured in the user agent along with the URI for the push 693 service. 695 Authorization is managed using capability URLs for the push message 696 subscription, push, and receipt subscription resources (see 697 [CAP-URI]). A capability URL grants access to a resource based 698 solely on knowledge of the URL. 700 Capability URLs are used for their "easy onward sharing" and "easy 701 client API" properties. These make it possible to avoid relying on 702 relationships between push services and application servers, with the 703 protocols necessary to build and support those relationships. 705 Capability URLs act as bearer tokens. Knowledge of a push message 706 subscription URI implies authorization to either receive push 707 messages or delete the subscription. Knowledge of a push URI implies 708 authorization to send push messages. Knowledge of a push message URI 709 allows for reading and acknowledging that specific message. 710 Knowledge of a receipt subscription URI implies authorization to 711 receive push receipts. Knowledge of a receipt subscribe URI implies 712 authorization to create subscriptions for receipts. 714 Note that the same receipt subscribe URI could be returned for 715 multiple push message subscriptions. Using the same value for a 716 large number of subscriptions allows application servers to reuse 717 receipt subscriptions, which can provide a significant efficiency 718 advantage. A push service that uses a common receipt subscribe URI 719 loses control over the creation of receipt subscriptions. This can 720 result in a potential exposure to denial of service; stateless 721 resource creation can be used to mitigate the effects of this 722 exposure. 724 Encoding a large amount of random entropy (at least 120 bits) in the 725 path component ensures that it is difficult to successfully guess a 726 valid capability URL. 728 8.4. Denial of Service Considerations 730 Discarding unwanted messages at the user agent based on message 731 authentication doesn't protect against a denial of service attack on 732 the user agent. Even a relatively small volume of push messages can 733 cause battery-powered devices to exhaust power reserves. 735 An application can limit where valid push messages can originate by 736 limiting the distribution of push URIs to authorized entities. 737 Ensuring that push URIs are hard to guess ensures that only 738 application servers that have been given a push URI can use it. 740 A malicious application with a valid push URI could use the greater 741 resources of a push service to mount a denial of service attack on a 742 user agent. Push services SHOULD limit the rate at which push 743 messages are sent to individual user agents. A push service or user 744 agent MAY terminate subscriptions (Section 7.3) that receive too many 745 push messages. 747 End-to-end confidentiality mechanisms, such as those in [API], 748 prevent an entity with a valid push message subscription URI from 749 learning the contents of push messages. Push messages that are not 750 successfully authenticated will not be delivered by the API, but this 751 can present a denial of service risk. 753 Conversely, a push service is also able to deny service to user 754 agents. Intentional failure to deliver messages is difficult to 755 distinguish from faults, which might occur due to transient network 756 errors, interruptions in user agent availability, or genuine service 757 outages. 759 8.5. Logging Risks 761 Server request logs can reveal subscription-related URIs. Acquiring 762 a push message subscription URI enables the receipt of messages or 763 deletion of the subscription. Acquiring a push URI permits the 764 sending of push messages. Logging could also reveal relationships 765 between different subscription-related URIs for the same user agent. 766 Encrypted message contents are not revealed to the push service. 768 Limitations on log retention and strong access control mechanisms can 769 ensure that URIs are not learned by unauthorized entities. 771 9. IANA Considerations 773 This protocol defines new HTTP header fields in Section 9.1. New 774 link relation types are identified using the URNs defined in 775 Section 9.2. 777 9.1. Header Field Registrations 779 HTTP header fields are registered within the "Message Headers" 780 registry maintained at [1]. 782 This document defines the following HTTP header fields, so their 783 associated registry entries shall be added according to the permanent 784 registrations below (see [RFC3864]): 786 +-------------------+----------+----------+--------------+ 787 | Header Field Name | Protocol | Status | Reference | 788 +-------------------+----------+----------+--------------+ 789 | TTL | http | standard | Section 5.2 | 790 | Push-Receipt | http | standard | Section 5.1 | 791 +-------------------+----------+----------+--------------+ 793 The change controller is: "IETF (iesg@ietf.org) - Internet 794 Engineering Task Force". 796 9.2. Link Relation URNs 798 This document registers URNs for use in identifying link relation 799 types. These are added to a new "Web Push Identifiers" registry 800 according to the procedures in Section 4 of [RFC3553]; the 801 corresponding "push" sub-namespace is entered in the "IETF URN Sub- 802 namespace for Registered Protocol Parameter Identifiers" registry. 804 The "Web Push Identifiers" registry operates under the IETF Review 805 policy [RFC5226]. 807 Registry name: Web Push Identifiers 809 URN Prefix: urn:ietf:params:push 811 Specification: (this document) 813 Repository: [Editor/IANA note: please include a link to the final 814 registry location.] 816 Index value: Values in this registry are URNs or URN prefixes that 817 start with the prefix "urn:ietf:params:push". Each is registered 818 independently. 820 New registrations in the "Web Push Identifiers" are encouraged to 821 include the following information: 823 URN: A complete URN or URN prefix. 825 Description: A summary description. 827 Specification: A reference to a specification describing the 828 semantics of the URN or URN prefix. 830 Contact: Email for the person or group making the registration. 832 Index value: As described in [RFC3553], URN prefixes that are 833 registered include a description of how the URN is constructed. 834 This is not applicable for specific URNs. 836 These values are entered as the initial content of the "Web Push 837 Identifiers" registry. 839 URN: urn:ietf:params:push 841 Description: This link relation type is used to identify a resource 842 for sending push messages. 844 Specification: (this document) 846 Contact: The Web Push WG (webpush@ietf.org) 848 URN: urn:ietf:params:push:receipt 850 Description: This link relation type is used to identify a resource 851 for creating new push message receipt subscriptions. 853 Specification: (this document) 855 Contact: The Web Push WG (webpush@ietf.org) 857 10. Acknowledgements 859 Significant technical input to this document has been provided by 860 Costin Manolache, Robert Sparks, Mark Nottingham, Matthew Kaufman and 861 many others. 863 11. References 865 11.1. Normative References 867 [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD 868 capability-urls, February 2014, 869 . 871 [I-D.ietf-httpbis-alt-svc] 872 Nottingham, M., McManus, P., and J. Reschke, "HTTP 873 Alternative Services", draft-ietf-httpbis-alt-svc-06 (work 874 in progress), February 2015. 876 [I-D.ietf-httpbis-http2] 877 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 878 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 879 progress), February 2015. 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, March 1997. 884 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 886 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 887 IETF URN Sub-namespace for Registered Protocol 888 Parameters", BCP 73, RFC 3553, June 2003. 890 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 891 Procedures for Message Header Fields", BCP 90, RFC 3864, 892 September 2004. 894 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 895 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 896 May 2008. 898 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 900 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 901 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 902 2014. 904 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 905 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 907 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 908 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 910 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 911 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 912 2014. 914 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 916 11.2. Informative References 918 [API] Sullivan, B., Fullea, E., and M. van Ouwerkerk, "Web Push 919 API", ED push-api, February 2015, . 922 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 923 Morris, J., Hansen, M., and R. Smith, "Privacy 924 Considerations for Internet Protocols", RFC 6973, July 925 2013. 927 11.3. URIs 929 [1] https://www.iana.org/assignments/message-headers/ 931 Authors' Addresses 933 Martin Thomson 934 Mozilla 935 331 E Evelyn Street 936 Mountain View, CA 94041 937 US 939 Email: martin.thomson@gmail.com 941 Elio Damaggio 942 Microsoft 943 One Microsoft Way 944 Redmond, WA 98052 945 US 947 Email: elioda@microsoft.com 949 Brian Raymor 950 Microsoft 951 One Microsoft Way 952 Redmond, WA 98052 953 US 955 Email: brian.raymor@microsoft.com