idnits 2.17.1 draft-ietf-secevent-http-push-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 are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2018) is 2039 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 572, but no explicit reference was found in the text == Unused Reference: 'RFC5988' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC6750' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC7516' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC7521' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC7617' is defined on line 671, 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 (~~), 13 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 4, 2019 Microsoft 6 M. Scurtescu 7 Google 8 M. Ansari 9 Cisco 10 A. Nadalin 11 Microsoft 12 October 1, 2018 14 Push-Based SET Token Delivery Using HTTP 15 draft-ietf-secevent-http-push-01 17 Abstract 19 This specification defines how a series of security event tokens 20 (SETs) may be delivered to a previously registered receiver using 21 HTTP POST over TLS initiated as a push to the receiver. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 4, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 58 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 59 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Event Delivery Process . . . . . . . . . . . . . . . . . 3 62 2.2. Transmitting a SET . . . . . . . . . . . . . . . . . . . 4 63 2.3. Handling a SET Transmission Request . . . . . . . . . . . 5 64 2.3.1. Success Response . . . . . . . . . . . . . . . . . . 5 65 2.3.2. Failure Response . . . . . . . . . . . . . . . . . . 5 66 2.3.3. Security Event Token Delivery Error Codes . . . . . . 6 67 2.3.4. Error Responses . . . . . . . . . . . . . . . . . . . 7 68 3. Authentication and Authorization . . . . . . . . . . . . . . 7 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 4.1. Authentication Using Signed SETs . . . . . . . . . . . . 7 71 4.2. TLS Support Considerations . . . . . . . . . . . . . . . 7 72 4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 73 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. Security Event Token Delivery Error Codes . . . . . . . . 8 76 6.1.1. Registration Template . . . . . . . . . . . . . . . . 8 77 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 7.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Appendix A. Other Streaming Specifications . . . . . . . . . . . 15 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 83 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction and Overview 88 This specification defines how SETs (see [RFC8417]) can be 89 transmitted to a previously registered SET Receiver using HTTP 90 [RFC7231] over TLS. The specification defines a method to push SETs 91 via HTTP POST. 93 1.1. Notational Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 Throughout this documents all figures may contain spaces and extra 102 line-wrapping for readability and space limitations. 104 1.2. Definitions 106 This specification assumes terminology defined in the Security Event 107 Token specification[RFC8417], as well as the terms defined below: 109 SET Transmitter 110 A service provider that delivers SETs to other providers known as 111 SET Receivers. 113 SET Receiver 114 A service provider that registers to receive SETs from a SET 115 Transmitter and provides an endpoint to receive SETs via HTTP 116 POST. 118 2. Event Delivery 120 2.1. Event Delivery Process 122 In Push-Based SET Delivery Using HTTP, SETs are delivered one at a 123 time using HTTP POST requests by a SET Transmitter to a SET Receiver, 124 as described below in Section 2.2. Upon receipt, the SET Receiver 125 acknowledges receipt or indicates an error via the HTTP response, as 126 described below in Section 2.3. 128 After successful (acknowledged) SET delivery, SET Transmitters SHOULD 129 NOT be required to maintain or record SETs for recovery. Once a SET 130 is acknowledged, the SET Receiver SHALL be responsible for retention 131 and recovery. 133 Transmitted SETs SHOULD be self-validating (e.g. signed) if there is 134 a requirement to verify they were issued by the SET Transmitter at a 135 later date when de-coupled from the original delivery where 136 authenticity could be checked via the HTTP or TLS mutual 137 authentication. 139 Upon receiving a SET, the SET Receiver reads the SET and validates 140 it. The SET Receiver MUST acknowledge receipt to the SET 141 Transmitter, using the defined acknowledgement or error method. 143 The SET Receiver SHALL NOT use the Event acknowledgement mechanism to 144 report Event errors other than relating to the parsing and validation 145 of the SET. 147 2.2. Transmitting a SET 149 This method allows a SET Transmitter to use HTTP POST (Section 4.3.3 150 [RFC7231]) to deliver SETs to a previously registered web callback 151 URI supplied by the SET Receiver as part of a configuration process 152 (not defined by this document). 154 The SET to be delivered MAY be signed and/or encrypted as defined in 155 [RFC8417]. 157 The HTTP Content-Type (see Section 3.1.1.5 [RFC7231]) for the HTTP 158 POST is "application/secevent+jwt" and the request body SHALL consist 159 of a single SET (see [RFC8417]). As per Section 5.3.2 [RFC7231], the 160 value of the "Accept" header is "application/json". 162 The following is a non-normative example of a SET transmission HTTP 163 POST request: 165 POST /Events HTTP/1.1 167 Host: notify.examplerp.com 168 Accept: application/json 169 Content-Type: application/secevent+jwt 171 eyJhbGciOiJub25lIn0 172 . 173 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 174 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 175 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 176 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 177 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 178 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 179 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 180 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 181 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 182 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 183 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 184 . 186 Figure 1: Example SET Transmission Request 188 2.3. Handling a SET Transmission Request 190 Upon receipt of the request, the SET Receiver SHALL validate the JWT 191 structure of the SET as defined in Section 7.2 [RFC7519]. The SET 192 Receiver SHALL also validate the SET information as described in 193 Section 2 [RFC8417]. 195 2.3.1. Success Response 197 If the SET is determined to be valid, the SET Receiver SHALL 198 "acknowledge" successful submission by responding with HTTP Status 199 202 as "Accepted" (see Section 6.3.3 [RFC7231]). 201 In order to maintain compatibility with other methods of 202 transmission, the SET Receiver SHOULD NOT include an HTTP response 203 body representation of the submitted SET or what the SET's pending 204 status is when acknowledging success. In the case of an error (e.g. 205 HTTP Status 400), the purpose of the HTTP response body is to 206 indicate any SET parsing, validation, or cryptographic errors. 208 The following is a non-normative example of a successful receipt of a 209 SET. 211 HTTP/1.1 202 Accepted 213 Figure 2: Example Successful Delivery Response 215 Note that the purpose of the "acknowledgement" response is to let the 216 SET Transmitter know that a SET has been delivered and the 217 information no longer needs to be retained by the SET Transmitter. 218 Before acknowledgement, SET Receivers SHOULD ensure they have 219 validated received SETs and retained them in a manner appropriate to 220 information retention requirements appropriate to the SET event types 221 signaled. The level and method of retention of SETs by SET Receivers 222 is out-of-scope of this specification. 224 2.3.2. Failure Response 226 In the Event of a general HTTP error condition, the SET Receiver MAY 227 respond with an appropriate HTTP Status code as defined in Section 6 228 [RFC7231]. 230 When the SET Receiver detects an error parsing or validating a 231 received SET (as defined by [RFC8417]), the SET Receiver SHALL 232 indicate an HTTP Status 400 error with an error response as described 233 in Section 2.3.4. 235 The following is an example non-normative error response. 237 HTTP/1.1 400 Bad Request 238 Content-Type: application/json 240 { 241 "err":"dup", 242 "description":"SET already received. Ignored." 244 } 246 Figure 3: Example Error Response 248 2.3.3. Security Event Token Delivery Error Codes 250 Security Event Token Delivery Error Codes are strings that identify a 251 specific type of error that may occur when parsing or validating a 252 SET. Every Security Event Token Delivery Error Code MUST have a 253 unique name registered in the IANA "Security Event Token Delivery 254 Error Codes" registry established by Section 6.1. 256 The following table presents the initial set of Error Codes that are 257 registered in the IANA "Security Event Token Delivery Error Codes" 258 registry: 260 +-----------+-------------------------------------------------------+ 261 | Error | Description | 262 | Code | | 263 +-----------+-------------------------------------------------------+ 264 | json | Invalid JSON object. | 265 | jwtParse | Invalid or unparsable JWT or JSON structure. | 266 | jwtHdr | In invalid JWT header was detected. | 267 | jwtCrypto | Unable to parse due to unsupported algorithm. | 268 | jws | Signature was not validated. | 269 | jwe | Unable to decrypt JWE encoded data. | 270 | jwtAud | Invalid audience value. | 271 | jwtIss | Issuer not recognized. | 272 | setType | An unexpected Event type was received. | 273 | setParse | Invalid structure was encountered such as an | 274 | | inability to parse or an incomplete set of Event | 275 | | claims. | 276 | setData | SET event claims incomplete or invalid. | 277 | dup | A duplicate SET was received and has been ignored. | 278 +-----------+-------------------------------------------------------+ 280 Table 1: SET Delivery Error Codes 282 2.3.4. Error Responses 284 An error response SHALL include a JSON object which provides details 285 about the error. The JSON object includes the JSON attributes: 287 err 288 A value which is a keyword that describes the error (see Table 1). 290 description 291 A human-readable text that provides additional diagnostic 292 information. 294 When included as part of an HTTP Status 400 response, the above JSON 295 is the HTTP response body (see Figure 3). 297 3. Authentication and Authorization 299 The SET delivery method described in this specification is based upon 300 HTTP and depends on the use of TLS and/or standard HTTP 301 authentication and authorization schemes as per [RFC7235]. 303 Because SET Delivery describes a simple function, authorization for 304 the ability to pick-up or deliver SETs can be derived by considering 305 the identity of the SET issuer, or via other employed authentication 306 methods. Because SETs are not commands (see ), SET Receivers are 307 free to ignore SETs that are not of interest. 309 4. Security Considerations 311 4.1. Authentication Using Signed SETs 313 In scenarios where HTTP authorization or TLS mutual authentication 314 are not used or are considered weak, JWS signed SETs SHOULD be used 315 (see [RFC7515] and Security Considerations [RFC8417]). This enables 316 the SET Receiver to validate that the SET issuer is authorized to 317 deliver SETs. 319 4.2. TLS Support Considerations 321 SETs contain sensitive information that is considered PII (e.g. 322 subject claims). Therefore, SET Transmitters and SET Receivers MUST 323 require the use of a transport-layer security mechanism. Event 324 delivery endpoints MUST support TLS 1.2 [RFC5246] and MAY support 325 additional transport-layer mechanisms meeting its security 326 requirements. When using TLS, the client MUST perform a TLS/SSL 327 server certificate check, per [RFC6125]. Implementation security 328 considerations for TLS can be found in "Recommendations for Secure 329 Use of TLS and DTLS" [RFC7525]. 331 4.3. Denial of Service 333 The SET Receiver may be vulnerable to a denial-of-service attack 334 where a malicious party makes a high volume of requests containing 335 invalid SETs, causing the endpoint to expend significant resources on 336 cryptographic operations that are bound to fail. This may be 337 mitigated by authenticating SET Transmitters with a mechanism with 338 low runtime overhead, such as mutual TLS or statically assigned 339 bearer tokens. 341 5. Privacy Considerations 343 If a SET needs to be retained for audit purposes, JWS MAY be used to 344 provide verification of its authenticity. 346 When sharing personally identifiable information or information that 347 is otherwise considered confidential to affected users, SET 348 Transmitters and Receivers MUST have the appropriate legal agreements 349 and user consent or terms of service in place. 351 The propagation of subject identifiers can be perceived as personally 352 identifiable information. Where possible, SET Transmitters and 353 Receivers SHOULD devise approaches that prevent propagation -- for 354 example, the passing of a hash value that requires the subscriber to 355 already know the subject. 357 6. IANA Considerations 359 6.1. Security Event Token Delivery Error Codes 361 This document defines Security Event Token Delivery Error Codes, for 362 which IANA is asked to create and maintain a new registry titled 363 "Security Event Token Delivery Error Codes". Initial values for the 364 Security Event Token Delivery Error Codes registry are given in 365 Table 1. Future assignments are to be made through the Expert Review 366 registration policy ([RFC8126]) and shall follow the template 367 presented in Section 6.1.1. 369 6.1.1. Registration Template 371 Error Code 372 The name of the Security Event Token Delivery Error Code, as 373 described in Section 2.3.3. The name MUST be a case-sensitive 374 ASCII string consisting only of upper-case letters ("A" - "Z"), 375 lower-case letters ("a" - "z"), and digits ("0" - "9"). 377 Description 378 A brief human-readable description of the Security Event Token 379 Delivery Error Code. 381 Change Controller 382 For error codes registered by the IETF or its working groups, list 383 "IETF Secevent Working Group". For all other error codes, list 384 the name of the party responsible for the registration. Contact 385 information such as mailing address, email address, or phone 386 number may also be provided. 388 Defining Document(s) 389 A reference to the document or documents that define the Security 390 Event Token Delivery Error Code. The definition MUST specify the 391 name and description of the error code, and explain under what 392 circumstances the error code may be used. URIs that can be used 393 to retrieve copies of each document at no cost SHOULD be included. 395 6.1.2. Initial Registry Contents 397 o 399 Error Code 400 json 402 Description 403 Invalid JSON object. 405 Change Controller 406 IETF Secevent Working Group 408 Defining Document(s) 409 Section 2.3.3 of this document. 411 o 413 Error Code 414 jwtParse 416 Description 417 Invalid or unparsable JWT or JSON structure. 419 Change Controller 420 IETF Secevent Working Group 422 Defining Document(s) 423 Section 2.3.3 of this document. 425 o 426 Error Code 427 jwtHdr 429 Description 430 An invalid JWT header was detected. 432 Change Controller 433 IETF Secevent Working Group 435 Defining Document(s) 436 Section 2.3.3 of this document. 438 o 440 Error Code 441 jwtCrypto 443 Description 444 Unable to parse due to unsupported algorithm. 446 Change Controller 447 IETF Secevent Working Group 449 Defining Document(s) 450 Section 2.3.3 of this document. 452 o 454 Error Code 455 jws 457 Description 458 Signature was not validated. 460 Change Controller 461 IETF Secevent Working Group 463 Defining Document(s) 464 Section 2.3.3 of this document. 466 o 468 Error Code 469 jwe 471 Description 472 Unable to decrypt JWE encoded data. 474 Change Controller 475 IETF Secevent Working Group 477 Defining Document(s) 478 Section 2.3.3 of this document. 480 o 482 Error Code 483 jwtAud 485 Description 486 Invalid audience value. 488 Change Controller 489 IETF Secevent Working Group 491 Defining Document(s) 492 Section 2.3.3 of this document. 494 o 496 Error Code 497 jwtIss 499 Description 500 Issuer not recognized. 502 Change Controller 504 Defining Document(s) 505 Section 2.3.3 of this document. 507 o 509 Error Code 510 setType 512 Description 513 An unexpected Event type was received. 515 Change Controller 516 IETF Secevent Working Group 518 Defining Document(s) 519 Section 2.3.3 of this document. 521 o 522 Error Code 523 setParse 525 Description 526 Invalid structure was encountered such as an inability to parse 527 or an incomplete set of Event claims. 529 Change Controller 530 IETF Secevent Working Group 532 Defining Document(s) 533 Section 2.3.3 of this document. 535 o 537 Error Code 538 setData 540 Description 541 SET event claims incomplete or invalid. 543 Change Controller 544 IETF Secevent Working Group 546 Defining Document(s) 547 Section 2.3.3 of this document. 549 o 551 Error Code 552 dup 554 Description 555 A duplicate SET was received and has been ignored. 557 Change Controller 558 IETF Secevent Working Group 560 Defining Document(s) 561 Section 2.3.3 of this document. 563 7. References 565 7.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 573 Resource Identifier (URI): Generic Syntax", STD 66, 574 RFC 3986, DOI 10.17487/RFC3986, January 2005, 575 . 577 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 578 (TLS) Protocol Version 1.2", RFC 5246, 579 DOI 10.17487/RFC5246, August 2008, 580 . 582 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 583 DOI 10.17487/RFC5988, October 2010, 584 . 586 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 587 Verification of Domain-Based Application Service Identity 588 within Internet Public Key Infrastructure Using X.509 589 (PKIX) Certificates in the Context of Transport Layer 590 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 591 2011, . 593 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 594 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 595 2014, . 597 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 598 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 599 DOI 10.17487/RFC7231, June 2014, 600 . 602 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 603 DOI 10.17487/RFC7517, May 2015, 604 . 606 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 607 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 608 . 610 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 611 "Recommendations for Secure Use of Transport Layer 612 Security (TLS) and Datagram Transport Layer Security 613 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 614 2015, . 616 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 617 Writing an IANA Considerations Section in RFCs", BCP 26, 618 RFC 8126, DOI 10.17487/RFC8126, June 2017, 619 . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 626 "Security Event Token (SET)", RFC 8417, 627 DOI 10.17487/RFC8417, July 2018, 628 . 630 7.2. Informative References 632 [openid-connect-core] 633 NRI, "OpenID Connect Core 1.0", Nov 2014. 635 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 636 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 637 . 639 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 640 RFC 6749, DOI 10.17487/RFC6749, October 2012, 641 . 643 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 644 Framework: Bearer Token Usage", RFC 6750, 645 DOI 10.17487/RFC6750, October 2012, 646 . 648 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 649 Protocol (HTTP/1.1): Message Syntax and Routing", 650 RFC 7230, DOI 10.17487/RFC7230, June 2014, 651 . 653 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 654 Protocol (HTTP/1.1): Authentication", RFC 7235, 655 DOI 10.17487/RFC7235, June 2014, 656 . 658 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 659 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 660 2015, . 662 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 663 RFC 7516, DOI 10.17487/RFC7516, May 2015, 664 . 666 [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 667 "Assertion Framework for OAuth 2.0 Client Authentication 668 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 669 May 2015, . 671 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 672 RFC 7617, DOI 10.17487/RFC7617, September 2015, 673 . 675 [saml-core-2.0] 676 Internet2, "Assertions and Protocols for the OASIS 677 Security Assertion Markup Language (SAML) V2.0", March 678 2005. 680 Appendix A. Other Streaming Specifications 682 [[EDITORS NOTE: This section to be removed prior to publication]] 684 The following pub/sub, queuing, streaming systems were reviewed as 685 possible solutions or as input to the current draft: 687 XMPP Events 689 The WG considered the XMPP events ands its ability to provide a 690 single messaging solution without the need for both polling and push 691 modes. The feeling was the size and methodology of XMPP was to far 692 apart from the current capabilities of the SECEVENTs community which 693 focuses in on HTTP based service delivery and authorization. 695 Amazon Simple Notification Service 697 Simple Notification Service, is a pub/sub messaging product from AWS. 698 SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS 699 Lambda functions, email addresses (as JSON or plain text), phone 700 numbers (via SMS), and AWS SQS standard queues. It doesn't directly 701 support pull, but subscribers can get the pull model by creating an 702 SQS queue and subscribing it to the topic. Note that this puts the 703 cost of pull support back onto the subscriber, just as it is in the 704 push model. It is not clear that one way is strictly better than the 705 other; larger, sophisticated developers may be happy to own message 706 persistence so they can have their own internal delivery guarantees. 707 The long tail of OIDC clients may not care about that, or may fail to 708 get it right. Regardless, I think we can learn something from the 709 Delivery Policies supported by SNS, as well as the delivery controls 710 that SQS offers (e.g. Visibility Timeout, Dead-Letter Queues). I'm 711 not suggesting that we need all of these things in the spec, but they 712 give an idea of what features people have found useful. 714 Other information: 716 o API Reference: 717 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 718 APIReference/Welcome.html 720 o Visibility Timeouts: 721 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 722 SQSDeveloperGuide/sqs-visibility-timeout.html 724 Apache Kafka 726 Apache Kafka is an Apache open source project based upon TCP for 727 distributed streaming. It prescribes some interesting general 728 purpose features that seem to extend far beyond the simpler streaming 729 model SECEVENTs is after. A comment from MS has been that Kafka does 730 an acknowledge with poll combination event which seems to be a 731 performance advantage. See: https://kafka.apache.org/intro 733 Google Pub/Sub 735 Google Pub Sub system favours a model whereby polling and 736 acknowledgement of events is done as separate endpoints as separate 737 functions. 739 Information: 741 o Cloud Overview - https://cloud.google.com/pubsub/ 743 o Subscriber Overview - https://cloud.google.com/pubsub/docs/ 744 subscriber 746 o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull 748 Appendix B. Acknowledgments 750 The editors would like to thanks the members of the SCIM WG which 751 began discussions of provisioning events starting with: draft-hunt- 752 scim-notify-00 in 2015. 754 The editors would like to thank Phil Hunt and the other authors of 755 draft-ietf-secevent-delivery-02, on which this draft is based. 757 The editor would like to thank the participants in the the SECEVENTS 758 working group for their support of this specification. 760 Appendix C. Change Log 762 Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the 763 following changes: 765 o Renamed to "Push-Based SET Token Delivery Using HTTP" 767 o Removed references to the HTTP Polling delivery method. 769 o Removed informative reference to RFC6202. 771 Draft 01 - AB: 773 o Fixed area and workgroup to match secevent. 775 o Removed unused definitions and definitions already covered by SET. 777 o Renamed Event Transmitter and Event Receiver to SET Transmitter 778 and SET Receiver, respectively. 780 o Added IANA registry for SET Delivery Error Codes. 782 o Removed enumeration of HTTP authentication methods. 784 o Removed generally applicable guidance for HTTP, authorization 785 tokens, and bearer tokens. 787 o Moved guidance for using authentication methods as DoS protection 788 to Security Considerations. 790 o Removed redundant instruction to use WWW-Authenticate header. 792 o Removed further generally applicable guidance for authorization 793 tokens. 795 o Removed bearer token from example delivery request, and text 796 referencing it. 798 o Broke delivery method description into separate request/response 799 sections. 801 o Added missing empty line between headers and body in example 802 request. 804 o Removed unapplicable notes about example formatting. 806 o Removed text about SET creation and handling. 808 o Removed duplication in protocol description. 810 o Added "non-normative example" text to example transmission 811 request. 813 o Fixed inconsistencies in use of Error Code term. 815 Authors' Addresses 817 Annabelle Backman (editor) 818 Amazon 820 Email: richanna@amazon.com 822 Michael B. Jones (editor) 823 Microsoft 825 Email: mbj@microsoft.com 826 URI: http://self-issued.info/ 828 Marius Scurtescu 829 Google 831 Email: mscurtescu@google.com 833 Morteza Ansari 834 Cisco 836 Email: morteza.ansari@cisco.com 838 Anthony Nadalin 839 Microsoft 841 Email: tonynad@microsoft.com