idnits 2.17.1 draft-ietf-secevent-http-push-06.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 (May 9, 2019) is 1808 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** 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 7235 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 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: November 10, 2019 Microsoft 6 M. Scurtescu 7 Coinbase 8 M. Ansari 9 Cisco 10 A. Nadalin 11 Microsoft 12 May 9, 2019 14 Push-Based Security Event Token (SET) Delivery Using HTTP 15 draft-ietf-secevent-http-push-06 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 request 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 November 10, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 5 64 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Security Event Token Delivery Error Codes . . . . . . . . 8 67 3. Authentication and Authorization . . . . . . . . . . . . . . 8 68 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 9 71 5.2. Confidentiality of SETs . . . . . . . . . . . . . . . . . 9 72 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 73 5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 10 74 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Security Event Token Delivery Error Codes . . . . . . . . 10 77 7.1.1. Registration Template . . . . . . . . . . . . . . . . 11 78 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Appendix A. Other Streaming Specifications . . . . . . . . . . . 14 83 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 84 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 A mechanism for exchanging configuration metadata such as endpoint 105 URLs and cryptographic key parameters between the transmitter and 106 recipient is out of scope for this specifications. 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 document, 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 SET Recipient 129 An entity that receives SETs through some distribution method. 131 2. SET Delivery 133 To deliver a SET to a given SET Recipient, the SET Transmitter makes 134 a SET transmission request to the SET Recipient, with the SET itself 135 contained within the request. The SET Recipient replies to this 136 request with a response either acknowledging successful transmission 137 of the SET or indicating that an error occurred while receiving, 138 parsing, and/or validating the SET. 140 Upon receipt of a SET, the SET Recipient SHALL validate that all of 141 the following are true: 143 o The SET Recipient can parse the SET. 145 o The SET is authentic (i.e., it was issued by the issuer specified 146 within the SET). 148 o The SET Recipient is identified as an intended audience of the 149 SET. 151 o The SET Issuer is recognized as an issuer that the SET Recipient 152 is willing to receive SETs from (e.g., the issuer is whitelisted 153 by the SET Recipient). 155 o The SET Recipient is willing to accept the SET when transmitted by 156 the SET Transmitter (e.g., the SET Transmitter is expected to send 157 SETs with the subject of the SET in question). 159 The mechanisms by which the SET Recipient performs this validation 160 are out of scope for this document. SET parsing and issuer and 161 audience identification are defined in [RFC8417]. The mechanism for 162 validating the authenticity of a SET is deployment specific, and may 163 vary depending on the authentication mechanisms in use, and whether 164 the SET is signed and/or encrypted (See Section 3). 166 SET Transmitters MAY transmit SETs issued by another entity. The SET 167 Recipient may accept or reject (i.e., return an error response such 168 as "access_denied") a SET at its own discretion. 170 The SET Recipient SHOULD ensure that the SET is persisted in a way 171 that is sufficient to meet the SET Recipient's own reliability 172 requirements, and MUST NOT expect or depend on a SET Transmitter to 173 re-transmit or otherwise make available to the SET Recipient a SET 174 once the SET Recipient acknowledges that it was received 175 successfully. 177 Once the SET has been validated and persisted, the SET Recipient 178 SHOULD immediately return a response indicating that the SET was 179 successfully delivered. The SET Recipient SHOULD NOT perform 180 extensive business logic that processes the event expressed by the 181 SET prior to sending this response. Such logic SHOULD be executed 182 asynchronously from delivery, in order to minimize the expense and 183 impact of SET delivery on the SET Transmitter. 185 The SET Transmitter MAY re-transmit a SET if the responses from 186 previous transmissions timed out or indicated potentially recoverable 187 error (such as server unavailability that may be transient). In all 188 other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The 189 SET Transmitter SHOULD delay retransmission for an appropriate amount 190 of time to avoid overwhelming the SET Recipient (see Section 4). 192 2.1. Transmitting a SET 194 To transmit a SET to a SET Recipient, the SET Transmitter makes an 195 HTTP POST request to an HTTP endpoint provided by the SET Recipient. 196 The "Content-Type" header of this request MUST be "application/ 197 secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and 198 the "Accept" header MUST be "application/json". The request body 199 MUST consist of the SET itself, represented as a JWT [RFC7519]. 201 The SET Transmitter MAY include in the request an "Accept-Language" 202 header to indicate to the SET Recipient the preferred language(s) in 203 which to receive error messages. 205 The mechanisms by which the SET Transmitter determines the HTTP 206 endpoint to use when transmitting a SET to a given SET Recipient are 207 not defined by this specification and are deployment specific. 209 The following is a non-normative example of a SET transmission 210 request: 212 POST /Events HTTP/1.1 213 Host: notify.rp.example.com 214 Accept: application/json 215 Accept-Language: en-US, en;q=0.5 216 Content-Type: application/secevent+jwt 218 eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg 219 . 220 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 221 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 222 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 223 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 224 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 225 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 226 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 227 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 228 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 229 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 230 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQo 231 . 232 Y4rXxMD406P2edv00cr9Wf3/XwNtLjB9n+jTqN1/lLc 234 Figure 1: Example SET Transmission Request 236 2.2. Success Response 238 If the SET is determined to be valid, the SET Recipient SHALL 239 acknowledge successful transmission by responding with HTTP Response 240 Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). The 241 body of the response MUST be empty. 243 The following is a non-normative example of a successful receipt of a 244 SET. 246 HTTP/1.1 202 Accepted 248 Figure 2: Example Successful Delivery Response 250 Note that the purpose of the acknowledgement response is to let the 251 SET Transmitter know that a SET has been delivered and the 252 information no longer needs to be retained by the SET Transmitter. 253 Before acknowledgement, SET Recipients SHOULD ensure they have 254 validated received SETs and retained them in a manner appropriate to 255 information retention requirements appropriate to the SET event types 256 signaled. The level and method of retention of SETs by SET 257 Recipients is out of scope of this specification. 259 2.3. Failure Response 261 In the event of a general HTTP error condition, the SET Recipient 262 SHOULD respond with an appropriate HTTP Status Code as defined in 263 Section 6 of [RFC7231]. 265 When the SET Recipient detects an error parsing, validating or 266 authenticating a SET transmitted in a SET Transmission Request, the 267 SET Recipient SHALL respond with an HTTP Response Status Code of 400 268 (Bad Request). The "Content-Type" header of this response MUST be 269 "application/json", and the body MUST be a UTF-8 encoded JSON 270 [RFC8259] object containing the following name/value pairs: 272 err A Security Event Token Error Code (see Section 2.4). 274 description A UTF-8 string containing a human-readable description 275 of the error that MAY provide additional diagnostic information. 276 The exact content of this field is implementation-specific. 278 The response MUST include a "Content-Language" header, whose value 279 indicates the language of the error descriptions included in the 280 response body. If the SET Recipient can provide error descriptions 281 in multiple languages, they SHOULD choose the language to use 282 according to the value of the "Accept-Language" header sent by the 283 SET Transmitter in the transmission request, as described in 284 Section 5.3.5 of [RFC7231]. If the SET Transmitter did not send an 285 "Accept-Language" header, or if the SET Recipient does not support 286 any of the languages included in the header, the SET Recipient MUST 287 respond with messages that are understandable by an English-speaking 288 person, as described in Section 4.5 of [RFC2277]. 290 The following is an example non-normative error response indicating 291 that the key used to encrypt the SET has been revoked. 293 HTTP/1.1 400 Bad Request 294 Content-Language: en-US 295 Content-Type: application/json 297 { 298 "err": "invalid_key", 299 "description": "Key ID 12345 has been revoked." 300 } 302 Figure 3: Example Error Response (invalid_key) 304 The following is an example non-normative error response indicating 305 that the access token included in the request is expired. 307 HTTP/1.1 400 Bad Request 308 Content-Language: en-US 309 Content-Type: application/json 311 { 312 "err": "authentication_failed", 313 "description": "Access token is expired." 314 } 316 Figure 4: Example Error Response (authentication_failed) 318 The following is an example non-normative error response indicating 319 that the SET Receiver is not willing to accept SETs issued by the 320 specified issuer from this particular SET Transmitter. 322 HTTP/1.1 400 Bad Request 323 Content-Language: en-US 324 Content-Type: application/json 326 { 327 "err": "access_denied", 328 "description": "Not authorized for issuer http://iss.example.com/." 329 } 331 Figure 5: Example Error Response (access_denied) 333 2.4. Security Event Token Delivery Error Codes 335 Security Event Token Delivery Error Codes are strings that identify a 336 specific category of error that may occur when parsing or validating 337 a SET. Every Security Event Token Delivery Error Code MUST have a 338 unique name registered in the IANA "Security Event Token Delivery 339 Error Codes" registry established by Section 7.1. 341 The following table presents the initial set of Error Codes that are 342 registered in the IANA "Security Event Token Delivery Error Codes" 343 registry: 345 +-----------------------+-------------------------------------------+ 346 | Error Code | Description | 347 +-----------------------+-------------------------------------------+ 348 | invalid_request | The request body cannot be parsed as a | 349 | | SET, or the event payload within the SET | 350 | | does not conform to the event's | 351 | | definition. | 352 | invalid_key | One or more keys used to encrypt or sign | 353 | | the SET is invalid or otherwise | 354 | | unacceptable to the SET Recipient. (e.g., | 355 | | expired, revoked, failed certificate | 356 | | validation, etc.) | 357 | authentication_failed | The SET Recipient could not authenticate | 358 | | the SET Transmitter from the contents of | 359 | | the request. | 360 | access_denied | The SET Transmitter is not authorized to | 361 | | transmit the provided SET to the SET | 362 | | Recipient. | 363 +-----------------------+-------------------------------------------+ 365 Table 1: SET Delivery Error Codes 367 3. Authentication and Authorization 369 The SET delivery method described in this specification is based upon 370 HTTP and depends on the use of TLS and/or standard HTTP 371 authentication and authorization schemes, as per [RFC7235]. 373 Because SET Delivery describes a simple function, authorization for 374 the ability to pick-up or deliver SETs can be derived by considering 375 the identity of the SET Issuer, or via other employed authentication 376 methods. Because SETs are not commands, SET Recipients are free to 377 ignore SETs that are not of interest. 379 4. Delivery Reliability 381 Delivery reliability requirements may vary from implementation to 382 implementation. This specification defines the response from the SET 383 Recipient in such a way as to provide the SET Transmitter with the 384 information necessary to determine what further action is required, 385 if any, in order to meet their requirements. SET Transmitters with 386 high reliability requirements may be tempted to always retry failed 387 transmissions, however it should be noted that for many types of SET 388 delivery errors, a retry is extremely unlikely to be successful. For 389 example, "invalid_request" indicates a structural error in the 390 content of the request body that is likely to remain when re- 391 transmitting the same SET. Others such as "access_denied" may be 392 transient, for example if the SET Transmitter refreshes expired 393 credentials prior to re-transmission. 395 Implementers SHOULD evaluate their reliability requirements and the 396 impact of various retry mechanisms on the performance of their 397 systems to determine the correct strategy for various error 398 conditions. 400 5. Security Considerations 402 5.1. Authentication Using Signed SETs 404 In scenarios where HTTP authorization or TLS mutual authentication 405 are not used or are considered weak, JWS signed SETs SHOULD be used 406 (see [RFC7515] and Security Considerations [RFC8417]). This enables 407 the SET Recipient to validate that the SET Transmitter is authorized 408 to deliver the SET. 410 5.2. Confidentiality of SETs 412 SETs may contain sensitive information that is considered Personally 413 Identifiable Information (e.g., subject claims). In such cases, SET 414 Transmitters and SET Recipients MUST protect the confidentiality of 415 the SET contents by encrypting the SET as described in JWE [RFC7516], 416 using a transport-layer security mechanism such as TLS, or both. If 417 an Event delivery endpoint supports TLS, it MUST support at least TLS 418 version 1.2 [RFC5246] and SHOULD support the newest version of TLS 419 that meets its security requirements. When using TLS, the client 420 MUST perform a TLS/SSL server certificate check, per [RFC6125]. 421 Implementation security considerations for TLS can be found in 422 "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. 424 5.3. Denial of Service 426 The SET Recipient may be vulnerable to a denial-of-service attack 427 where a malicious party makes a high volume of requests containing 428 invalid SETs, causing the endpoint to expend significant resources on 429 cryptographic operations that are bound to fail. This may be 430 mitigated by authenticating SET Transmitters with a mechanism with 431 low runtime overhead, such as mutual TLS. 433 5.4. Authenticating Persisted SETs 435 At the time of receipt, the SET Recipient can rely upon transport 436 layer mechanisms, HTTP authentication methods, and/or other context 437 from the transmission request to authenticate the SET Transmitter and 438 validate the authenticity of the SET. However, this context is 439 typically unavailable to systems that the SET Recipient forwards the 440 SET onto, or to systems that retrieve the SET from storage. If the 441 SET Recipient requires the ability to validate SET authenticity 442 outside of the context of the transmission request, then the SET 443 Recipient SHOULD ensure that such SETs have been signed in accordance 444 with [RFC7515]. 446 6. Privacy Considerations 448 If a SET needs to be retained for audit purposes, a JWS signature MAY 449 be used to provide verification of its authenticity. 451 When sharing personally identifiable information or information that 452 is otherwise considered confidential to affected users, SET 453 Transmitters and Recipients MUST have the appropriate legal 454 agreements and user consent or terms of service in place. 456 In some cases subject identifiers themselves may be considered 457 sensitive information, such that its inclusion within a SET may be 458 considered a violation of privacy. SET Transmitters should consider 459 the ramifications of sharing a particular subject identifier with a 460 SET Recipient (e.g., whether doing so could enable correlation and/or 461 de-anonymization of data), and choose appropriate subject identifiers 462 for their use case. 464 7. IANA Considerations 466 7.1. Security Event Token Delivery Error Codes 468 This document defines Security Event Token Delivery Error Codes, for 469 which IANA is asked to create and maintain a new registry titled 470 "Security Event Token Delivery Error Codes". Initial values for the 471 Security Event Token Delivery Error Codes registry are given in 472 Table 1. Future assignments are to be made through the First Come 473 First Served registration policy ([RFC8126]) and shall follow the 474 template presented in Section 7.1.1. 476 Error Codes are intended to be interpreted by automated systems, and 477 therefore SHOULD identify classes of errors to which an automated 478 system could respond in a meaningfully distinct way (e.g., by 479 refreshing authentication credentials and retrying the request). 481 7.1.1. Registration Template 483 Error Code 484 The name of the Security Event Token Delivery Error Code, as 485 described in Section 2.4. The name MUST be a case-sensitive ASCII 486 string consisting only of letters, digits and underscore, these 487 are the characters whose codes fall within the inclusive ranges 488 0x30-39, 0x41-5A, 0x5F and 0x61-7A. 490 Description 491 A brief human-readable description of the Security Event Token 492 Delivery Error Code. 494 Change Controller 495 For error codes registered by the IETF or its working groups, list 496 "IETF SecEvent Working Group". For all other error codes, list 497 the name of the party responsible for the registration. Contact 498 information such as mailing address, email address, or phone 499 number may also be provided. 501 Defining Document(s) 502 A reference to the document or documents that define the Security 503 Event Token Delivery Error Code. The definition MUST specify the 504 name and description of the error code, and explain under what 505 circumstances the error code may be used. URIs that can be used 506 to retrieve copies of each document at no cost SHOULD be included. 508 7.1.2. Initial Registry Contents 510 Error Code: invalid_request 511 Description: The request body cannot be parsed as a SET or the 512 event payload within the SET does not conform to the event's 513 definition. 514 Change Controller: IETF Secevent Working Group 515 Defining Document(s): Section 2.4 of this document 517 Error Code: invalid_key 518 Description: One or more keys used to encrypt or sign the SET is 519 invalid or otherwise unacceptable to the SET Recipient. (e.g., 520 expired, revoked, failed certificate validation, etc.) 521 Change Controller: IETF Secevent Working Group 522 Defining Document(s): Section 2.4 of this document 524 Error Code: authentication_failed 525 Description: The SET Recipient could not authenticate the SET 526 Transmitter from the contents of the request. 527 Change Controller: IETF Secevent Working Group 528 Defining Document(s): Section 2.4 of this document 530 Error Code: access_denied 531 Description: The SET Transmitter is not authorized to transmit the 532 SET to the SET Recipient. 533 Change Controller: IETF Secevent Working Group 534 Defining Document(s): Section 2.4 of this document 536 8. References 538 8.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 546 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 547 January 1998, . 549 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 550 (TLS) Protocol Version 1.2", RFC 5246, 551 DOI 10.17487/RFC5246, August 2008, 552 . 554 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 555 Verification of Domain-Based Application Service Identity 556 within Internet Public Key Infrastructure Using X.509 557 (PKIX) Certificates in the Context of Transport Layer 558 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 559 2011, . 561 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 562 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 563 DOI 10.17487/RFC7231, June 2014, 564 . 566 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 567 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 568 2015, . 570 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 571 RFC 7516, DOI 10.17487/RFC7516, May 2015, 572 . 574 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 575 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 576 . 578 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 579 "Recommendations for Secure Use of Transport Layer 580 Security (TLS) and Datagram Transport Layer Security 581 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 582 2015, . 584 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 585 Writing an IANA Considerations Section in RFCs", BCP 26, 586 RFC 8126, DOI 10.17487/RFC8126, June 2017, 587 . 589 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 590 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 591 May 2017, . 593 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 594 Interchange Format", STD 90, RFC 8259, 595 DOI 10.17487/RFC8259, December 2017, 596 . 598 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 599 "Security Event Token (SET)", RFC 8417, 600 DOI 10.17487/RFC8417, July 2018, 601 . 603 8.2. Informative References 605 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 606 Protocol (HTTP/1.1): Authentication", RFC 7235, 607 DOI 10.17487/RFC7235, June 2014, 608 . 610 Appendix A. Other Streaming Specifications 612 [[EDITORS NOTE: This section to be removed prior to publication]] 614 The following pub/sub, queuing, streaming systems were reviewed as 615 possible solutions or as input to the current draft: 617 Poll-Based Security Event Token (SET) Delivery Using HTTP 619 In addition to this specification, the WG is defining a polling-based 620 SET delivery protocol. That protocol's draft (draft-ietf-secevent- 621 http-poll) describes it as: 623 This specification defines how a series of Security Event Tokens 624 (SETs) may be delivered to an intended recipient using HTTP POST over 625 TLS initiated as a poll by the recipient. The specification also 626 defines how delivery can be assured, subject to the SET Recipient's 627 need for assurance. 629 XMPP Events 631 The WG considered the XMPP events ands its ability to provide a 632 single messaging solution without the need for both polling and push 633 modes. The feeling was the size and methodology of XMPP was to far 634 apart from the current capabilities of the SECEVENTs community which 635 focuses in on HTTP based service delivery and authorization. 637 Amazon Simple Notification Service 639 Simple Notification Service, is a pub/sub messaging product from AWS. 640 SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS 641 Lambda functions, email addresses (as JSON or plain text), phone 642 numbers (via SMS), and AWS SQS standard queues. It doesn't directly 643 support pull, but subscribers can get the pull model by creating an 644 SQS queue and subscribing it to the topic. Note that this puts the 645 cost of pull support back onto the subscriber, just as it is in the 646 push model. It is not clear that one way is strictly better than the 647 other; larger, sophisticated developers may be happy to own message 648 persistence so they can have their own internal delivery guarantees. 649 The long tail of OIDC clients may not care about that, or may fail to 650 get it right. Regardless, I think we can learn something from the 651 Delivery Policies supported by SNS, as well as the delivery controls 652 that SQS offers (e.g., Visibility Timeout, Dead-Letter Queues). I'm 653 not suggesting that we need all of these things in the spec, but they 654 give an idea of what features people have found useful. 656 Other information: 658 o API Reference: 659 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 660 APIReference/Welcome.html 662 o Visibility Timeouts: 663 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ 664 SQSDeveloperGuide/sqs-visibility-timeout.html 666 Apache Kafka 668 Apache Kafka is an Apache open source project based upon TCP for 669 distributed streaming. It prescribes some interesting general 670 purpose features that seem to extend far beyond the simpler streaming 671 model SECEVENTs is after. A comment from MS has been that Kafka does 672 an acknowledge with poll combination event which seems to be a 673 performance advantage. See: https://kafka.apache.org/intro 675 Google Pub/Sub 677 Google Pub Sub system favours a model whereby polling and 678 acknowledgement of events is done as separate endpoints as separate 679 functions. 681 Information: 683 o Cloud Overview - https://cloud.google.com/pubsub/ 685 o Subscriber Overview - https://cloud.google.com/pubsub/docs/ 686 subscriber 688 o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull 690 Appendix B. Acknowledgments 692 The editors would like to thank the members of the SCIM working 693 group, which began discussions of provisioning events starting with 694 draft-hunt-scim-notify-00 in 2015. 696 The editors would like to thank Phil Hunt and the other authors of 697 draft-ietf-secevent-delivery-02, on which this draft is based. 699 The editors would like to thank the participants in the the SecEvents 700 working group for their contributions to this specification. 702 Appendix C. Change Log 704 Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the 705 following changes: 707 o Renamed to "Push-Based SET Token Delivery Using HTTP" 709 o Removed references to the HTTP Polling delivery method. 711 o Removed informative reference to RFC6202. 713 Draft 01 - AB: 715 o Fixed area and workgroup to match secevent. 717 o Removed unused definitions and definitions already covered by SET. 719 o Renamed Event Transmitter and Event Receiver to SET Transmitter 720 and SET Receiver, respectively. 722 o Added IANA registry for SET Delivery Error Codes. 724 o Removed enumeration of HTTP authentication methods. 726 o Removed generally applicable guidance for HTTP, authorization 727 tokens, and bearer tokens. 729 o Moved guidance for using authentication methods as DoS protection 730 to Security Considerations. 732 o Removed redundant instruction to use WWW-Authenticate header. 734 o Removed further generally applicable guidance for authorization 735 tokens. 737 o Removed bearer token from example delivery request, and text 738 referencing it. 740 o Broke delivery method description into separate request/response 741 sections. 743 o Added missing empty line between headers and body in example 744 request. 746 o Removed unapplicable notes about example formatting. 748 o Removed text about SET creation and handling. 750 o Removed duplication in protocol description. 752 o Added "non-normative example" text to example transmission 753 request. 755 o Fixed inconsistencies in use of Error Code term. 757 Draft 02 - AB: 759 o Rewrote abstract and introduction. 761 o Rewrote definitions for SET Transmitter, SET Receiver. 763 o Renamed Event Delivery section to SET Delivery. 765 o Readability edits to Success Response and Failure Response 766 sections. 768 o Consolidated definition of error response under Failure Response 769 section. 771 o Removed Event Delivery Process section and moved its content to 772 parent section. 774 o Readability edits to SET Delivery section and its subsections. 776 o Added callout that SET Receiver HTTP endpoint configuration is 777 out-of-scope. 779 o Added callout that SET verification mechanisms are out-of-scope. 781 o Added retry guidance, notes regarding delivery reliability 782 requirements. 784 o Added guidance around using JWS and/or JWE to authenticate 785 persisted SETs. 787 Draft 03 - mbj: 789 o Addressed problems identified in my 18-Jul-18 review message 790 titled "Issues for both the Push and Poll Specs". 792 o Changes to align terminology with RFC 8417, for instance, by using 793 the already defined term SET Recipient rather than SET Receiver. 795 o Applied editorial and minor normative corrections. 797 o Updated Marius' contact information. 799 Draft 04 - AB: 801 o Replaced Error Codes with smaller set of meaningfully 802 differentiated codes. 804 o Added more error response examples. 806 o Removed un-referenced normative references. 808 o Added normative reference to JSON in error response definition. 810 o Added text clarifying that the value of the "description" 811 attribute in error responses is implementation specific. 813 o Added requirement that error descriptions and responses are UTF-8 814 encoded. 816 o Added error description language preferences and specification via 817 "Accept-Language" and "Content-Language" headers. 819 o Added "recognized issuer" validation requirement in section 2. 821 o Added time outs as an acceptable reason to resend a SET in section 822 2. 824 o Edited text in section 1 to clarify that configuration is out of 825 scope. 827 o Made minor editorial corrections. 829 Draft 05 - AB: 831 o Made minor editorial corrections. 833 o Updated example request with a correct SET header and signature. 835 o Revised TLS guidance to allow implementers to provide 836 confidentiality protection via JWE. 838 o Revised TLS guidance to require *at least* TLS 1.2. 840 o Revised TLS guidance to recommend supporting the newest version of 841 TLS that meets security requirements. 843 o Revised SET Delivery Error Code format to allow the same set of 844 characters as is allowed in error codes in RFC6749. 846 o Added mention of HTTP Poll spec to list of other streaming specs 847 in appendix. 849 o Added validation step requiring SET Recipient to verify that the 850 SET is one which the SET Transmitter is expected to send to the 851 SET Recipient. 853 o Changed responding to errors with an appropriate HTTP status code 854 from optional to recommended. 856 o Changed Error Codes registry change policy from Expert Review to 857 First Come First Served; added guidance that error codes are meant 858 to be consumed by automated systems. 860 o Added text making clear that it is up to SET Recipients whether or 861 not they will accept SETs where the SET Issuer is different from 862 the SET Transmitter. 864 o Reworded guidance around signing and/or encrypting SETs for 865 integrity protection. 867 o Renamed TLS "Support Considerations" section to "Confidentiality 868 of SETs". 870 o Reworded guidance around subject identifier selection and privacy 871 concerns. 873 Authors' Addresses 875 Annabelle Backman (editor) 876 Amazon 878 Email: richanna@amazon.com 880 Michael B. Jones (editor) 881 Microsoft 883 Email: mbj@microsoft.com 884 URI: http://self-issued.info/ 886 Marius Scurtescu 887 Coinbase 889 Email: marius.scurtescu@coinbase.com 890 Morteza Ansari 891 Cisco 893 Email: morteza.ansari@cisco.com 895 Anthony Nadalin 896 Microsoft 898 Email: tonynad@microsoft.com