idnits 2.17.1 draft-ietf-secevent-http-push-03.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 date (October 18, 2018) is 2016 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) == Unused Reference: 'RFC3986' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC5988' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC6750' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC7521' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC7617' is defined on line 603, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Events Working Group A. Backman, Ed. 3 Internet-Draft Amazon 4 Intended status: Standards Track M. Jones, Ed. 5 Expires: April 21, 2019 Microsoft 6 M. Scurtescu 7 Coinbase 8 M. Ansari 9 Cisco 10 A. Nadalin 11 Microsoft 12 October 18, 2018 14 Push-Based Security Event Token (SET) Delivery Using HTTP 15 draft-ietf-secevent-http-push-03 17 Abstract 19 This specification defines how a Security Event Token (SET) may be 20 delivered to an intended recipient using HTTP POST. The SET is 21 transmitted in the body of an HTTP POST reqest to an endpoint 22 operated by the recipient, and the recipient indicates successful or 23 failed transmission via the HTTP response. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 60 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 61 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 4 64 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Security Event Token Delivery Error Codes . . . . . . . . 6 67 3. Authentication and Authorization . . . . . . . . . . . . . . 7 68 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 8 71 5.2. TLS Support Considerations . . . . . . . . . . . . . . . 8 72 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 73 5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 8 74 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Security Event Token Delivery Error Codes . . . . . . . . 9 77 7.1.1. Registration Template . . . . . . . . . . . . . . . . 9 78 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Appendix A. Other Streaming Specifications . . . . . . . . . . . 13 83 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 84 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction and Overview 89 This specification defines a mechanism by which a transmitter of a 90 Security Event Token (SET) [RFC8417] may deliver the SET to an 91 intended recipient via HTTP POST [RFC7231]. 93 Push-Based SET Delivery over HTTP POST is intended for scenarios 94 where all of the following apply: 96 o The transmitter of the SET is capable of making outbound HTTP 97 requests. 99 o The recipient is capable of hosting an HTTP endpoint that is 100 accessible to the transmitter. 102 o The transmitter and recipient are known to one another. 104 o The transmitter and recipient have an out-of-band mechanism for 105 exchanging configuration metadata such as endpoint URLs and 106 cryptographic key parameters. 108 1.1. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 Throughout this documents all figures may contain spaces and extra 117 line-wrapping for readability and due to space limitations. 119 1.2. Definitions 121 This specification utilizes terminology defined in [RFC8417], as well 122 as the terms defined below: 124 SET Transmitter 125 An entity that delivers SETs in its possession to one or more SET 126 Recipients. 128 2. SET Delivery 130 To deliver a SET to a given SET Recipient, the SET Transmitter makes 131 a SET Transmission Request to the SET Recipient, with the SET itself 132 contained within the request. The SET Recipient replies to this 133 request with a response either acknowledging successful transmission 134 of the SET, or indicating that an error occurred while receiving, 135 parsing, and/or validating the SET. 137 Upon receipt of a SET, the SET Recipient SHALL validate that all of 138 the following are true: 140 o The SET Recipient can parse the SET. 142 o The SET is authentic (i.e., it was issued by the issuer specified 143 within the SET). 145 o The SET Recipient is identified as an intended audience of the 146 SET. 148 The mechanisms by which the SET Recipient performs this validation 149 are out of scope for this document. SET parsing and issuer and 150 audience identification are defined in [RFC8417]. The mechanism for 151 validating the authenticity of a SET is implementation specific, and 152 may vary depending on the authentication mechanisms in use, and 153 whether the SET is signed and/or encrypted (See Section 3). 155 The SET Recipient SHOULD ensure that the SET is persisted in a way 156 that is sufficient to meet the SET Recipient's own reliability 157 requirements, and MUST NOT expect or depend on a SET Transmitter to 158 re-transmit or otherwise make available to the SET Recipient a SET 159 once the SET Recipient acknowledges that it was received 160 successfully. 162 Once the SET has been validated and persisted, the SET Recipient 163 SHOULD immediately return a response indicating that the SET was 164 successfully delivered. The SET Recipient SHOULD NOT perform 165 extensive business logic that processes the event expressed by the 166 SET prior to sending this response. Such logic SHOULD be executed 167 asynchronously from delivery, in order to minimize the expense and 168 impact of SET delivery on the SET Transmitter. 170 The SET Transmitter SHOULD NOT re-transmit a SET, unless the response 171 from the SET Recipient in previous transmissions indicated a 172 potentially recoverable error (such as server unavailability that may 173 be transient, or a decryption failure that may be due to 174 misconfigured keys on the SET Recipient's side). In the latter case, 175 the SET Transmitter MAY re-transmit a SET, after an appropriate delay 176 to avoid overwhelming the SET Recipient (see Section 4). 178 2.1. Transmitting a SET 180 To transmit a SET to a SET Recipient, the SET Transmitter makes an 181 HTTP POST request to an HTTP endpoint provided by the SET Recipient. 182 The "Content-Type" header of this request MUST be "application/ 183 secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and 184 the "Accept" header MUST be "application/json". The request body 185 MUST consist of the SET itself, represented as a JWT [RFC7519]. 187 The mechanisms by which the SET Transmitter determines the HTTP 188 endpoint to use when transmitting a SET to a given SET Recipient are 189 not defined by this specification and may be implementation-specific. 191 The following is a non-normative example of a SET transmission 192 request: 194 POST /Events HTTP/1.1 195 Host: notify.rp.example.com 196 Accept: application/json 197 Content-Type: application/secevent+jwt 199 eyJhbGciOiJub25lIn0 200 . 201 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 202 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 203 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 204 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 205 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 206 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 207 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 208 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 209 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 210 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 211 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 212 . 214 Figure 1: Example SET Transmission Request 216 2.2. Success Response 218 If the SET is determined to be valid, the SET Recipient SHALL 219 "acknowledge" successful transmission by responding with HTTP 220 Response Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). 221 The body of the response MUST be empty. 223 The following is a non-normative example of a successful receipt of a 224 SET. 226 HTTP/1.1 202 Accepted 228 Figure 2: Example Successful Delivery Response 230 Note that the purpose of the "acknowledgement" response is to let the 231 SET Transmitter know that a SET has been delivered and the 232 information no longer needs to be retained by the SET Transmitter. 233 Before acknowledgement, SET Recipients SHOULD ensure they have 234 validated received SETs and retained them in a manner appropriate to 235 information retention requirements appropriate to the SET event types 236 signaled. The level and method of retention of SETs by SET 237 Recipients is out of scope of this specification. 239 2.3. Failure Response 241 In the event of a general HTTP error condition, the SET Recipient MAY 242 respond with an appropriate HTTP Status Code as defined in Section 6 243 of [RFC7231]. 245 When the SET Recipient detects an error parsing or validating a SET 246 transmitted in a SET Transmission Request, the SET Recipient SHALL 247 respond with an HTTP Response Status Code of 400 (Bad Request). The 248 "Content-Type" header of this response MUST be "application/json", 249 and the body MUST be a JSON object containing the following name/ 250 value pairs: 252 err A Security Event Token Error Code (see Section 2.4). 254 description Human-readable text that describes the error and MAY 255 contain additional diagnostic information. 257 The following is an example non-normative error response. 259 HTTP/1.1 400 Bad Request 260 Content-Type: application/json 262 { 263 "err":"dup", 264 "description":"SET already received. Ignored." 266 } 268 Figure 3: Example Error Response 270 2.4. Security Event Token Delivery Error Codes 272 Security Event Token Delivery Error Codes are strings that identify a 273 specific type of error that may occur when parsing or validating a 274 SET. Every Security Event Token Delivery Error Code MUST have a 275 unique name registered in the IANA "Security Event Token Delivery 276 Error Codes" registry established by Section 7.1. 278 The following table presents the initial set of Error Codes that are 279 registered in the IANA "Security Event Token Delivery Error Codes" 280 registry: 282 +-----------+-------------------------------------------------------+ 283 | Error | Description | 284 | Code | | 285 +-----------+-------------------------------------------------------+ 286 | json | Invalid JSON object. | 287 | jwtParse | Invalid or unparsable JWT or JSON structure. | 288 | jwtHdr | An invalid JWT header was detected. | 289 | jwtCrypto | Unable to parse due to unsupported algorithm. | 290 | jws | Signature was not validated. | 291 | jwe | Unable to decrypt JWE encoded data. | 292 | jwtAud | Invalid audience value. | 293 | jwtIss | Issuer not recognized. | 294 | setType | An unexpected Event type was received. | 295 | setParse | Invalid structure was encountered such as an | 296 | | inability to parse or an incomplete set of Event | 297 | | claims. | 298 | setData | SET claims incomplete or invalid. | 299 | dup | A duplicate SET was received and has been ignored. | 300 +-----------+-------------------------------------------------------+ 302 Table 1: SET Delivery Error Codes 304 3. Authentication and Authorization 306 The SET delivery method described in this specification is based upon 307 HTTP and depends on the use of TLS and/or standard HTTP 308 authentication and authorization schemes as per [RFC7235]. 310 Because SET Delivery describes a simple function, authorization for 311 the ability to pick-up or deliver SETs can be derived by considering 312 the identity of the SET issuer, or via other employed authentication 313 methods. Because SETs are not commands, SET Recipients are free to 314 ignore SETs that are not of interest. 316 4. Delivery Reliability 318 Delivery reliability requirements may vary from implementation to 319 implementation. This specification defines the response from the SET 320 Recipient in such a way as to provide the SET Transmitter with the 321 information necessary to determine what further action is required, 322 if any, in order to meet their requirements. SET Transmitters with 323 high reliability requirements may be tempted to always retry failed 324 transmissions, however it should be noted that for many types of SET 325 delivery errors, a retry is extremely unlikely to be successful. For 326 example, "json", "jwtParse", and "setParse" all indicate structural 327 errors in the content of the SET that are likely to remain when re- 328 transmitting the same SET. Others such as "jws" or "jwe" may be 329 transient, for example if cryptographic material has not been 330 properly distributed to the SET Recipient's systems. 332 Implementers SHOULD evaluate their reliability requirements and the 333 impact of various retry mechanisms on the performance of their 334 systems to determine the correct strategy for various error 335 conditions. 337 5. Security Considerations 339 5.1. Authentication Using Signed SETs 341 In scenarios where HTTP authorization or TLS mutual authentication 342 are not used or are considered weak, JWS signed SETs SHOULD be used 343 (see [RFC7515] and Security Considerations [RFC8417]). This enables 344 the SET Recipient to validate that the SET issuer is authorized to 345 deliver the SET. 347 5.2. TLS Support Considerations 349 SETs may contain sensitive information that is considered PII (e.g., 350 subject claims). In such cases, SET Transmitters and SET Recipients 351 MUST require the use of a transport-layer security mechanism. Event 352 delivery endpoints MUST support TLS 1.2 [RFC5246] and MAY support 353 additional transport-layer mechanisms meeting its security 354 requirements. When using TLS, the client MUST perform a TLS/SSL 355 server certificate check, per [RFC6125]. Implementation security 356 considerations for TLS can be found in "Recommendations for Secure 357 Use of TLS and DTLS" [RFC7525]. 359 5.3. Denial of Service 361 The SET Recipient may be vulnerable to a denial-of-service attack 362 where a malicious party makes a high volume of requests containing 363 invalid SETs, causing the endpoint to expend significant resources on 364 cryptographic operations that are bound to fail. This may be 365 mitigated by authenticating SET Transmitters with a mechanism with 366 low runtime overhead, such as mutual TLS. 368 5.4. Authenticating Persisted SETs 370 At the time of receipt, the SET Recipient can rely upon transport 371 layer mechanisms, HTTP authentication methods, and/or other context 372 from the transmission request to authenticate the SET Transmitter and 373 validate the authenticity of the SET. However, this context is 374 typically unavailable to systems that the SET Recipient forwards the 375 SET onto, or to systems that retrieve the SET from storage. If the 376 SET Recipient requires the ability to validate SET authenticity 377 outside of the context of the transmission request, then the SET 378 Transmitter SHOULD sign the SET in accordance with [RFC7515] and 379 optionally also encrypt it in accordance with [RFC7516]. 381 6. Privacy Considerations 383 If a SET needs to be retained for audit purposes, a JWS signature MAY 384 be used to provide verification of its authenticity. 386 When sharing personally identifiable information or information that 387 is otherwise considered confidential to affected users, SET 388 Transmitters and Recipients MUST have the appropriate legal 389 agreements and user consent or terms of service in place. 391 The propagation of subject identifiers can be perceived as personally 392 identifiable information. Where possible, SET Transmitters and 393 Recipients SHOULD devise approaches that prevent propagation -- for 394 example, the passing of a hash value that requires the subscriber to 395 already know the subject. 397 7. IANA Considerations 399 7.1. Security Event Token Delivery Error Codes 401 This document defines Security Event Token Delivery Error Codes, for 402 which IANA is asked to create and maintain a new registry titled 403 "Security Event Token Delivery Error Codes". Initial values for the 404 Security Event Token Delivery Error Codes registry are given in 405 Table 1. Future assignments are to be made through the Expert Review 406 registration policy ([RFC8126]) and shall follow the template 407 presented in Section 7.1.1. 409 7.1.1. Registration Template 411 Error Code 412 The name of the Security Event Token Delivery Error Code, as 413 described in Section 2.4. The name MUST be a case-sensitive ASCII 414 string consisting only of upper-case letters ("A" - "Z"), lower- 415 case letters ("a" - "z"), and digits ("0" - "9"). 417 Description 418 A brief human-readable description of the Security Event Token 419 Delivery Error Code. 421 Change Controller 422 For error codes registered by the IETF or its working groups, list 423 "IETF Secevent Working Group". For all other error codes, list 424 the name of the party responsible for the registration. Contact 425 information such as mailing address, email address, or phone 426 number may also be provided. 428 Defining Document(s) 429 A reference to the document or documents that define the Security 430 Event Token Delivery Error Code. The definition MUST specify the 431 name and description of the error code, and explain under what 432 circumstances the error code may be used. URIs that can be used 433 to retrieve copies of each document at no cost SHOULD be included. 435 7.1.2. Initial Registry Contents 437 Error Code: json 438 Description: Invalid JSON object 439 Change Controller: IETF Secevent Working Group 440 Defining Document(s): Section 2.4 of this document 442 Error Code: jwtParse 443 Description: Invalid or unparsable JWT or JSON structure 444 Change Controller: IETF Secevent Working Group 445 Defining Document(s): Section 2.4 of this document 447 Error Code: jwtHdr 448 Description: An invalid JWT header was detected 449 Change Controller: IETF Secevent Working Group 450 Defining Document(s): Section 2.4 of this document 452 Error Code: jwtCrypto 453 Description: Unable to parse due to unsupported algorithm 454 Change Controller: IETF Secevent Working Group 455 Defining Document(s): Section 2.4 of this document 457 Error Code: jws 458 Description: Signature was not validated 459 Change Controller: IETF Secevent Working Group 460 Defining Document(s): Section 2.4 of this document 462 Error Code: jwe 463 Description: Unable to decrypt JWE encoded data 464 Change Controller: IETF Secevent Working Group 465 Defining Document(s): Section 2.4 of this document 467 Error Code: jwtAud 468 Description: Invalid audience value 469 Change Controller: IETF Secevent Working Group 470 Defining Document(s): Section 2.4 of this document 472 Error Code: jwtIss 473 Description: Issuer not recognized 474 Change Controller: 475 Defining Document(s): Section 2.4 of this document 477 Error Code: setType 478 Description: An unexpected Event type was received 479 Change Controller: IETF Secevent Working Group 480 Defining Document(s): Section 2.4 of this document 482 Error Code: setParse 483 Description: Invalid structure was encountered such as an 484 inability to parse or an incomplete set of Event claims. 485 Change Controller: IETF Secevent Working Group 486 Defining Document(s): Section 2.4 of this document 488 Error Code: setData 489 Description: SET claims incomplete or invalid 490 Change Controller: IETF Secevent Working Group 491 Defining Document(s): Section 2.4 of this document 493 Error Code: dup 494 Description: A duplicate SET was received and has been ignored. 495 Change Controller: IETF Secevent Working Group 496 Defining Document(s): Section 2.4 of this document 498 8. References 500 8.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 508 Resource Identifier (URI): Generic Syntax", STD 66, 509 RFC 3986, DOI 10.17487/RFC3986, January 2005, 510 . 512 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 513 (TLS) Protocol Version 1.2", RFC 5246, 514 DOI 10.17487/RFC5246, August 2008, 515 . 517 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 518 DOI 10.17487/RFC5988, October 2010, 519 . 521 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 522 Verification of Domain-Based Application Service Identity 523 within Internet Public Key Infrastructure Using X.509 524 (PKIX) Certificates in the Context of Transport Layer 525 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 526 2011, . 528 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 529 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 530 2014, . 532 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 533 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 534 DOI 10.17487/RFC7231, June 2014, 535 . 537 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 538 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 539 2015, . 541 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 542 RFC 7516, DOI 10.17487/RFC7516, May 2015, 543 . 545 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 546 DOI 10.17487/RFC7517, May 2015, 547 . 549 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 550 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 551 . 553 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 554 "Recommendations for Secure Use of Transport Layer 555 Security (TLS) and Datagram Transport Layer Security 556 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 557 2015, . 559 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 560 Writing an IANA Considerations Section in RFCs", BCP 26, 561 RFC 8126, DOI 10.17487/RFC8126, June 2017, 562 . 564 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 565 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 566 May 2017, . 568 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 569 "Security Event Token (SET)", RFC 8417, 570 DOI 10.17487/RFC8417, July 2018, 571 . 573 8.2. Informative References 575 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 576 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 577 . 579 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 580 RFC 6749, DOI 10.17487/RFC6749, October 2012, 581 . 583 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 584 Framework: Bearer Token Usage", RFC 6750, 585 DOI 10.17487/RFC6750, October 2012, 586 . 588 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 589 Protocol (HTTP/1.1): Message Syntax and Routing", 590 RFC 7230, DOI 10.17487/RFC7230, June 2014, 591 . 593 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 594 Protocol (HTTP/1.1): Authentication", RFC 7235, 595 DOI 10.17487/RFC7235, June 2014, 596 . 598 [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 599 "Assertion Framework for OAuth 2.0 Client Authentication 600 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 601 May 2015, . 603 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 604 RFC 7617, DOI 10.17487/RFC7617, September 2015, 605 . 607 Appendix A. Other Streaming Specifications 609 [[EDITORS NOTE: This section to be removed prior to publication]] 611 The following pub/sub, queuing, streaming systems were reviewed as 612 possible solutions or as input to the current draft: 614 XMPP Events 615 The WG considered the XMPP events ands its ability to provide a 616 single messaging solution without the need for both polling and push 617 modes. The feeling was the size and methodology of XMPP was to far 618 apart from the current capabilities of the SECEVENTs community which 619 focuses in on HTTP based service delivery and authorization. 621 Amazon Simple Notification Service 623 Simple Notification Service, is a pub/sub messaging product from AWS. 624 SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS 625 Lambda functions, email addresses (as JSON or plain text), phone 626 numbers (via SMS), and AWS SQS standard queues. It doesn't directly 627 support pull, but subscribers can get the pull model by creating an 628 SQS queue and subscribing it to the topic. Note that this puts the 629 cost of pull support back onto the subscriber, just as it is in the 630 push model. It is not clear that one way is strictly better than the 631 other; larger, sophisticated developers may be happy to own message 632 persistence so they can have their own internal delivery guarantees. 633 The long tail of OIDC clients may not care about that, or may fail to 634 get it right. Regardless, I think we can learn something from the 635 Delivery Policies supported by SNS, as well as the delivery controls 636 that SQS offers (e.g., Visibility Timeout, Dead-Letter Queues). I'm 637 not suggesting that we need all of these things in the spec, but they 638 give an idea of what features people have found useful. 640 Other information: 642 o API Reference: 643 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 644 APIReference/Welcome.html 646 o Visibility Timeouts: 647 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 648 SQSDeveloperGuide/sqs-visibility-timeout.html 650 Apache Kafka 652 Apache Kafka is an Apache open source project based upon TCP for 653 distributed streaming. It prescribes some interesting general 654 purpose features that seem to extend far beyond the simpler streaming 655 model SECEVENTs is after. A comment from MS has been that Kafka does 656 an acknowledge with poll combination event which seems to be a 657 performance advantage. See: https://kafka.apache.org/intro 659 Google Pub/Sub 660 Google Pub Sub system favours a model whereby polling and 661 acknowledgement of events is done as separate endpoints as separate 662 functions. 664 Information: 666 o Cloud Overview - https://cloud.google.com/pubsub/ 668 o Subscriber Overview - https://cloud.google.com/pubsub/docs/ 669 subscriber 671 o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull 673 Appendix B. Acknowledgments 675 The editors would like to thank the members of the SCIM working 676 group, which began discussions of provisioning events starting with: 677 draft-hunt-scim-notify-00 in 2015. 679 The editors would like to thank Phil Hunt and the other authors of 680 draft-ietf-secevent-delivery-02, on which this draft is based. 682 The editors would like to thank the participants in the the SECEVENTS 683 working group for their contributions to this specification. 685 Appendix C. Change Log 687 Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the 688 following changes: 690 o Renamed to "Push-Based SET Token Delivery Using HTTP" 692 o Removed references to the HTTP Polling delivery method. 694 o Removed informative reference to RFC6202. 696 Draft 01 - AB: 698 o Fixed area and workgroup to match secevent. 700 o Removed unused definitions and definitions already covered by SET. 702 o Renamed Event Transmitter and Event Receiver to SET Transmitter 703 and SET Receiver, respectively. 705 o Added IANA registry for SET Delivery Error Codes. 707 o Removed enumeration of HTTP authentication methods. 709 o Removed generally applicable guidance for HTTP, authorization 710 tokens, and bearer tokens. 712 o Moved guidance for using authentication methods as DoS protection 713 to Security Considerations. 715 o Removed redundant instruction to use WWW-Authenticate header. 717 o Removed further generally applicable guidance for authorization 718 tokens. 720 o Removed bearer token from example delivery request, and text 721 referencing it. 723 o Broke delivery method description into separate request/response 724 sections. 726 o Added missing empty line between headers and body in example 727 request. 729 o Removed unapplicable notes about example formatting. 731 o Removed text about SET creation and handling. 733 o Removed duplication in protocol description. 735 o Added "non-normative example" text to example transmission 736 request. 738 o Fixed inconsistencies in use of Error Code term. 740 Draft 02 - AB: 742 o Rewrote abstract and introduction. 744 o Rewrote definitions for SET Transmitter, SET Receiver. 746 o Renamed Event Delivery section to SET Delivery. 748 o Readability edits to Success Response and Failure Response 749 sections. 751 o Consolidated definition of error response under Failure Response 752 section. 754 o Removed Event Delivery Process section and moved its content to 755 parent section. 757 o Readability edits to SET Delivery section and its subsections. 759 o Added callout that SET Receiver HTTP endpoint configuration is 760 out-of-scope. 762 o Added callout that SET verification mechanisms are out-of-scope. 764 o Added retry guidance, notes regarding delivery reliability 765 requirements. 767 o Added guidance around using JWS and/or JWE to authenticate 768 persisted SETs. 770 Draft 03 - mbj: 772 o Addressed problems identified in my 18-Jul-18 review message 773 titled "Issues for both the Push and Poll Specs". 775 o Changes to align terminology with RFC 8417, for instance, by using 776 the already defined term SET Recipient rather than SET Receiver. 778 o Applied editorial and minor normative corrections. 780 o Updated Marius' contact information. 782 Authors' Addresses 784 Annabelle Backman (editor) 785 Amazon 787 Email: richanna@amazon.com 789 Michael B. Jones (editor) 790 Microsoft 792 Email: mbj@microsoft.com 793 URI: http://self-issued.info/ 795 Marius Scurtescu 796 Coinbase 798 Email: marius.scurtescu@coinbase.com 799 Morteza Ansari 800 Cisco 802 Email: morteza.ansari@cisco.com 804 Anthony Nadalin 805 Microsoft 807 Email: tonynad@microsoft.com