idnits 2.17.1 draft-scurtescu-secevent-event-stream-mgmt-api-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: state OPTIONAL. An arbitrary string that the Event Transmitter MUST echo back to the Event Receiver in the verification event's payload. Event Receivers MAY use the value of this parameter to correlate a verification event with a verification request. If the verification event is initiated by the transmitter then this parameter MUST not be set. -- The document date (August 10, 2017) is 2441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7159 (ref. 'JSON') (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 secevent M. Scurtescu 3 Internet-Draft Google 4 Intended status: Informational A. Backman 5 Expires: February 11, 2018 Amazon 6 August 10, 2017 8 Management API for SET Event Streams 9 draft-scurtescu-secevent-event-stream-mgmt-api-00 11 Abstract 13 Security Event Token (SET) delivery requires event receivers to 14 indicate to event transmitters the subjects about which they wish to 15 receive events, and how they wish to receive them. This 16 specification defines an HTTP API for a basic control plane that 17 event transmitters can implement and event receivers may use to 18 manage the flow of events from one to the other. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 11, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Event Stream Management . . . . . . . . . . . . . . . . . . . 3 58 4.1. Stream Configuration . . . . . . . . . . . . . . . . . . 4 59 4.1.1. Checking a Stream's Status . . . . . . . . . . . . . 5 60 4.1.2. Reading a Stream's Configuration . . . . . . . . . . 6 61 4.1.3. Updating a Stream's Configuration . . . . . . . . . . 7 62 4.2. Subjects . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2.1. Adding a Subject to a Stream . . . . . . . . . . . . 10 64 4.2.2. Removing a Subject . . . . . . . . . . . . . . . . . 11 65 4.3. Verification . . . . . . . . . . . . . . . . . . . . . . 13 66 4.3.1. Verification Event . . . . . . . . . . . . . . . . . 13 67 4.3.2. Triggering a Verification Event. . . . . . . . . . . 13 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 5.1. Subject Probing . . . . . . . . . . . . . . . . . . . . . 15 70 5.2. Information Harvesting . . . . . . . . . . . . . . . . . 16 71 5.3. Malicious Subject Removal . . . . . . . . . . . . . . . . 16 72 6. Normative References . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 This specification defines an HTTP API to be implemented by Event 78 Transmitters and that can be used by Event Receivers to query the 79 Event Stream status, to add and remove subjects and to trigger 80 verification. 82 +------------+ +------------+ 83 | | Stream Config | | 84 | Event <----------------+ Event | 85 | Stream | | Receiver | 86 | Management | Stream Status | | 87 | API <----------------+ | 88 | | | | 89 | | Add Subject | | 90 | <----------------+ | 91 | | | | 92 | | Remove Subject | | 93 | <----------------+ | 94 | | | | 95 | | Verification | | 96 | <----------------+ | 97 | | | | 98 +------------+ +------------+ 100 Figure 1: Event Stream Management API 102 How events are delivered and the structure of events are not in scope 103 for this specification. 105 2. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Definitions 113 In addition to terms defined in [SET], this specification uses the 114 following terms: 116 Subject Identifier Object 117 A JSON object containing a set of one or more claims about a 118 subject that when taken together uniquely identify that subject. 119 This set of claims SHOULD be declared as an acceptable way to 120 identify subjects of SETs by one or more specifications that 121 profile [SET]. 123 4. Event Stream Management 125 Event Receivers manage how they receive events, and the subjects 126 about which they want to receive events over an Event Stream by 127 making HTTP requests to endpoints in the Event Stream Management API. 129 The Event Stream Management API is implemented by the Event 130 Transmitter and consists of the following endpoints: 132 Configuration Endpoint 133 An endpoint used to read the Event Stream's current configuration. 135 Status Endpoint 136 An endpoint used to read the Event Stream's current status. 138 Add Subject Endpoint 139 An endpoint used to add subjects to an Event Stream. 141 Remove Subject Endpoint 142 An endpoint used to remove subjects from an Event Stream. 144 Verification Endpoint 145 An endpoint used to request the Event Transmitter transmit a 146 Verification Event over the Event Stream. 148 An Event Transmitter MAY use the same URLs as endpoints for multiple 149 streams, provided that the Event Transmitter has some mechanism 150 through which they can identify the applicable Event Stream for any 151 given request, e.g. from authentication credentials. The definition 152 of such mechanisms is outside the scope of this specification. 154 4.1. Stream Configuration 156 An Event Stream's configuration is represented as a JSON object with 157 the following properties: 159 aud 160 A string containing an audience claim as defined in JSON Web Token 161 (JWT) [RFC7519] that identifies the Event Receiver for the Event 162 Stream. This property cannot be updated. 164 events 165 OPTIONAL. An array of URIs identifying the set of events which 166 MAY be delivered over the Event Stream. If omitted, Event 167 Transmitters SHOULD make this set available to the Event Receiver 168 via some other means (e.g. publishing it in online 169 documentation). 171 delivery 172 A JSON object containing a set of name/value pairs specifying 173 configuration parameters for the SET delivery method. The actual 174 delivery method is identified by the special key "delivery_method" 175 with the value being a URI as defined in [DELIVERY]. 177 min_verification_interval 178 An integer indicating the minimum amount of time in seconds that 179 must pass in between verification requests. If an Event Receiver 180 submits verification requests more frequently than this, the Event 181 Transmitter MAY respond with a 429 status code. An Event 182 Transmitter SHOULD NOT respond with a 429 status code if an Event 183 Receiver is not exceeding this frequency. 185 status 186 A string indicating the current status of the event stream. It 187 MUST have one of the following values: 189 enabled 190 The transmitter will transmit events over the stream, according 191 to the stream's configured delivery method. 193 paused 194 The transmitter will not transmit events over the stream. The 195 transmitter will hold any events it would have transmitted 196 while paused, and will transmit them when the stream's status 197 becomes "enabled". 199 disabled 200 The transmitter will not transmit events over the stream, and 201 will not hold any events for later transmission. 203 4.1.1. Checking a Stream's Status 205 An Event Receiver checks the current status of an event stream by 206 making an HTTP GET request to the stream's Status Endpoint. On 207 receiving a valid request the Event Transmitter responds with a 200 208 OK response containing a [JSON] object with a single attribute 209 "status", whose string value is the value of the stream's status. 211 The following is a non-normative example request to check an event 212 stream's status: 214 GET /set/stream/status HTTP/1.1 215 Host: transmitter.example.com 216 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 218 Figure 2: Example: Check Stream Status Request 220 The following is a non-normative example response: 222 HTTP/1.1 200 OK 223 Content-Type: application/json; charset=UTF-8 224 Cache-Control: no-store 225 Pragma: no-cache 227 { 228 "status": "enabled" 229 } 231 Figure 3: Example: Check Stream Status Response 233 4.1.2. Reading a Stream's Configuration 235 An Event Receiver gets the current configuration of a stream by 236 making an HTTP GET request to the Configuration Endpoint. On 237 receiving a valid request the Event Transmitter responds with a 200 238 OK response containing a [JSON] representation of the stream's 239 configuration in the body. 241 The following is a non-normative example request to read an Event 242 Stream's configuration: 244 GET /set/stream HTTP/1.1 245 Host: transmitter.example.com 246 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 248 Figure 4: Example: Read Stream Configuration Request 250 The following is a non-normative example response: 252 HTTP/1.1 200 OK 253 Content-Type: application/json; charset=UTF-8 254 Cache-Control: no-store 255 Pragma: no-cache 257 { 258 "aud": "http://www.example.com", 259 "delivery": { 260 "delivery_method": "urn:example:secevent:delivery:http_post", 261 "url": "https://receiver.example.com/events" 262 }, 263 "status": "enabled", 264 "events": [ 265 "urn:example:secevent:events:type_1", 266 "urn:example:secevent:events:type_2", 267 "urn:example:secevent:events:type_3" 268 ], 269 "min_verification_interval": 60, 270 } 272 Figure 5: Example: Read Stream Configuration Response 274 Errors are signaled with HTTP staus codes as follows: 276 +------+------------------------------------------------------------+ 277 | Code | Description | 278 +------+------------------------------------------------------------+ 279 | 401 | if authorization failed or it is missing | 280 | | | 281 | 403 | if the Event Receiver is not allowed to read the stream | 282 | | configuration | 283 | | | 284 | 404 | if there is no Event Stream configured for this Event | 285 | | Receiver | 286 +------+------------------------------------------------------------+ 288 Table 1: Read Stream Configuration Errors 290 4.1.3. Updating a Stream's Configuration 292 An Event Receiver updates the current configuration of a stream by 293 making an HTTP POST request to the Configuration Endpoint. The POST 294 body contains a {{!JSON} representation of the updated configuration. 295 On receiving a valid request the Event Transmitter responds with a 296 200 OK response containing a [JSON] representation of the updated 297 stream configuration in the body. 299 The full set of editable properties must be present in the POST body, 300 not only the ones that are specifically intended to be changed. 301 Missing properties SHOULD be interpreted as requested to be deleted. 302 Event Receivers should read the configuration first, modify the 303 [JSON] representation, then make an update request. 305 Properties that cannot be updated MAY be present, but they MUST match 306 the expected value. 308 The following is a non-normative example request to read an Event 309 Stream's configuration: 311 POST /set/stream HTTP/1.1 312 Host: transmitter.example.com 313 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 315 { 316 "aud": "http://www.example.com", 317 "delivery": { 318 "delivery_method": "urn:example:secevent:delivery:http_post", 319 "url": "https://receiver.example.com/events" 320 }, 321 "status": "paused", 322 "events": [ 323 "urn:example:secevent:events:type_1", 324 "urn:example:secevent:events:type_2", 325 "urn:example:secevent:events:type_3" 326 ] 327 } 329 Figure 6: Example: Update Stream Configuration Request 331 The following is a non-normative example response: 333 HTTP/1.1 200 OK 334 Content-Type: application/json; charset=UTF-8 335 Cache-Control: no-store 336 Pragma: no-cache 338 { 339 "aud": "http://www.example.com", 340 "delivery": { 341 "delivery_method": "urn:example:secevent:delivery:http_post", 342 "url": "https://receiver.example.com/events" 343 }, 344 "status": "paused", 345 "events": [ 346 "urn:example:secevent:events:type_1", 347 "urn:example:secevent:events:type_2", 348 "urn:example:secevent:events:type_3" 349 ] 350 } 352 Figure 7: Example: Update Stream Configuration Response 354 Errors are signaled with HTTP staus codes as follows: 356 +------+------------------------------------------------------------+ 357 | Code | Description | 358 +------+------------------------------------------------------------+ 359 | 400 | if the request body cannot be parsed or if the request is | 360 | | otherwise invalid | 361 | | | 362 | 401 | if authorization failed or it is missing | 363 | | | 364 | 403 | if the Event Receiver is not allowed to update the stream | 365 | | configuration | 366 +------+------------------------------------------------------------+ 368 Table 2: Update Stream Configuration Errors 370 4.2. Subjects 372 An Event Receiver can indicate to an Event Transmitter whether or not 373 the receiver wants to receive events about a particular subject by 374 "adding" or "removing" that subject to the Event Stream, 375 respectively. 377 4.2.1. Adding a Subject to a Stream 379 To add a subject to an Event Stream, the Event Receiver makes an HTTP 380 POST request to the Add Subject Endpoint, containing in the body a 381 Subject Identifier Object identifying the subject to be added. On a 382 successful response, the Event Transmitter responds with an empty 200 383 OK response. 385 The Event Transmitter MAY choose to silently ignore the request, for 386 example if the subject has previously indicated to the transmitter 387 that they do not want events to be transmitted to the Event Receiver. 388 In this case, the transmitter MAY return an empty 200 OK response or 389 an appropriate error code (See Security Considerations (Section 5)). 391 Errors are signaled with HTTP staus codes as follows: 393 +------+------------------------------------------------------------+ 394 | Code | Description | 395 +------+------------------------------------------------------------+ 396 | 400 | if the request body cannot be parsed or if the request is | 397 | | otherwise invalid | 398 | | | 399 | 401 | if authorization failed or it is missing | 400 | | | 401 | 403 | if the Event Receiver is not allowed to add this | 402 | | particular subject | 403 | | | 404 | 404 | if the subject is not recognized by the Event Transmitter, | 405 | | the Event Transmitter may chose to stay silent in this | 406 | | case and respond with 200 | 407 | | | 408 | 429 | if the Event Receiver is sending too many requests in a | 409 | | gvien amount of time | 410 +------+------------------------------------------------------------+ 412 Table 3: Add Subject Errors 414 The following is a non-normative example request to add a subject to 415 a stream, where the subject is identified by an OpenID Connect email 416 claim: 418 POST /set/subjects:add HTTP/1.1 419 Host: transmitter.example.com 420 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 422 { 423 "email": "example.user@example.com" 424 } 426 Figure 8: Example: Add Subject Request 428 The following is a non-normative example response to a successful 429 request: 431 HTTP/1.1 200 OK 432 Server: transmitter.example.com 433 Cache-Control: no-store 434 Pragma: no-cache 436 Figure 9: Example: Add Subject Response 438 4.2.2. Removing a Subject 440 To remove a subject from an Event Stream, the Event Receiver makes an 441 HTTP POST request to the Remove Subject Endpoint, containing in the 442 body a Subject Identifier Object identifying the subject to be 443 removed. On a successful response, the Event Transmitter responds 444 with a 204 No Content response. 446 Errors are signaled with HTTP staus codes as follows: 448 +------+------------------------------------------------------------+ 449 | Code | Description | 450 +------+------------------------------------------------------------+ 451 | 400 | if the request body cannot be parsed or if the request is | 452 | | otherwise invalid | 453 | | | 454 | 401 | if authorization failed or it is missing | 455 | | | 456 | 403 | if the Event Receiver is not allowed to remove this | 457 | | particular subject | 458 | | | 459 | 404 | if the subject is not recognized by the Event Transmitter, | 460 | | the Event Transmitter may chose to stay silent in this | 461 | | case and respond with 204 | 462 | | | 463 | 429 | if the Event Receiver is sending too many requests in a | 464 | | gvien amount of time | 465 +------+------------------------------------------------------------+ 467 Table 4: Remove Subject Errors 469 The following is a non-normative example request where the subject is 470 identified by a phone_number claim: 472 POST /set/subjects:remove HTTP/1.1 473 Host: transmitter.example.com 474 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 476 { 477 "phone_number": "+1 206 555 0123" 478 } 480 Figure 10: Example: Remove Subject Request 482 The following is a non-normative example response to a successful 483 request: 485 HTTP/1.1 204 No Content 486 Server: transmitter.example.com 487 Cache-Control: no-store 488 Pragma: no-cache 490 Figure 11: Example: Remove Subject Response 492 4.3. Verification 494 In some cases, the frequency of event transmission on an Event Stream 495 will be very low, making it difficult for an Event Receiver to tell 496 the difference between expected behavior and event transmission 497 failure due to a misconfigured stream. Event Receivers can request 498 that a verification event be transmitted over the Event Stream, 499 allowing the receiver to confirm that the stream is configured 500 correctly upon successful receipt of the event. The acknowledgment 501 of a Verification Event also confirms to the Event Transmitter that 502 end-to-end delivery is working, including signature verification and 503 encryption. 505 An Event Transmitter MAY send a Verification Event at any time, even 506 if one was not requested by the Event Receiver. 508 4.3.1. Verification Event 510 The Verification Event is a standard SET with the following 511 attributes: 513 event type 514 The Event Type URI is: "urn:ietf:params:secevent:event- 515 type:core:verification". 517 state 518 OPTIONAL An opaque value provided by the Event Receiver when the 519 event is triggered. This is a nested attribute in the event 520 payload. 522 Upon receiving a Verification Event, the Event Receiver SHALL parse 523 the SET and validate its claims. In particular, the Event Receiver 524 SHALL confirm that the value for "state" is as expected. If the 525 value of "state" does not match, an error response of "setData" 526 SHOULD be returned (see Section 2.4 of [DELIVERY]). 528 In many cases, Event Transmitters MAY disable or suspend an Event 529 Stream that fails to successfully verify based on the acknowledgement 530 or lack of acknowledgement by the Event Receiver. 532 4.3.2. Triggering a Verification Event. 534 To request that a verification event be sent over an Event Stream, 535 the Event Receiver makes an HTTP POST request to the Verification 536 Endpoint, with a JSON object containing the parameters of the 537 verification request, if any. On a successful request, the event 538 transmitter responds with an empty 204 No Content response. 540 Verification requests have the following properties: 542 state 543 OPTIONAL. An arbitrary string that the Event Transmitter MUST 544 echo back to the Event Receiver in the verification event's 545 payload. Event Receivers MAY use the value of this parameter to 546 correlate a verification event with a verification request. If 547 the verification event is initiated by the transmitter then this 548 parameter MUST not be set. 550 A successful response from a POST to the Verification Endpoint does 551 not indicate that the verification event was transmitted 552 successfully, only that the Event Transmitter has transmitted the 553 event or will do so at some point in the future. Event Transmitters 554 MAY transmit the event via an asynchronous process, and SHOULD 555 publish an SLA for verification event transmission times. Event 556 Receivers MUST NOT depend on the verification event being transmitted 557 synchronously or in any particular order relative to the current 558 queue of events. 560 Errors are signaled with HTTP staus codes as follows: 562 +------+------------------------------------------------------------+ 563 | Code | Description | 564 +------+------------------------------------------------------------+ 565 | 400 | if the request body cannot be parsed or if the request is | 566 | | otherwise invalid | 567 | | | 568 | 401 | if authorization failed or it is missing | 569 | | | 570 | 429 | if the Event Receiver is sending too many requests in a | 571 | | gvien amount of time | 572 +------+------------------------------------------------------------+ 574 Table 5: Verification Errors 576 The following is a non-normative example request to trigger a 577 verification event: 579 POST /set/verify HTTP/1.1 580 Host: transmitter.example.com 581 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo= 582 Content-Type: application/json; charset=UTF-8 584 { 585 "state": "VGhpcyBpcyBhbiBleGFtcGxlIHN0YXRlIHZhbHVlLgo=" 586 } 588 Figure 12: Example: Trigger Verification Request 590 The following is a non-normative example response to a successful 591 request: 593 HTTP/1.1 204 No Content 594 Server: transmitter.example.com 595 Cache-Control: no-store 596 Pragma: no-cache 598 Figure 13: Example: Trigger Verification Response 600 And the following is a non-normative example of a verification event 601 sent to the Event Receiver as a result of the above request: 603 { 604 "jti": "123456", 605 "iss": "https://transmitter.example.com", 606 "aud": "receiver.example.com", 607 "iat": "1493856000", 608 "events": [ 609 "urn:ietf:params:secevent:event-type:core:verification" : { 610 "state": "VGhpcyBpcyBhbiBleGFtcGxlIHN0YXRlIHZhbHVlLgo=", 611 }, 612 ], 613 } 615 Figure 14: Example: Verification SET 617 5. Security Considerations 619 5.1. Subject Probing 621 It may be possible for an Event Transmitter to leak information about 622 subjects through their responses to add subject requests. A 404 623 response may indicate to the Event Receiver that the subject does not 624 exist, which may inadvertantly reveal information about the subject 625 (e.g. that a particular individual does or does not use the Event 626 Transmitter's service). 628 Event Transmitters SHOULD carefully evaluate the conditions under 629 which they will return error responses to add subject requests. 630 Event Transmitters MAY return a 204 response even if they will not 631 actually send any events related to the subject, and Event Receivers 632 MUST NOT assume that a 204 response means that they will receive 633 events related to the subject. 635 5.2. Information Harvesting 637 SETs may contain personally identifiable information (PII) or other 638 non-public information about the event transmitter, the subject (of 639 an event in the SET), or the relationship between the two. It is 640 important for Event Transmitters to understand what information they 641 are revealing to Event Receivers when transmitting events to them, 642 lest the event stream become a vector for unauthorized access to 643 private information. 645 Event Transmitters SHOULD interpret add subject requests as 646 statements of interest in a subject by an Event Receiver, and ARE NOT 647 obligated to transmit events related to every subject an Event 648 Receiver adds to the stream. Event Transmitters MAY choose to 649 transmit some, all, or no events related to any given subject and 650 SHOULD validate that they are permitted to share the information 651 contained within an event with the Event Receiver before transmitting 652 the event. The mechanisms by which such validation is performed are 653 outside the scope of this specification. 655 5.3. Malicious Subject Removal 657 A malicious party may find it advantageous to remove a particular 658 subject from a stream, in order to reduce the Event Receiver's 659 ability to detect malicious activity related to the subject, 660 inconvenience the subject, or for other reasons. Consequently it may 661 be in the best interests of the subject for the Event Transmitter to 662 continue to send events related to the subject for some time after 663 the subject has been removed from a stream. 665 Event Transmitters MAY continue sending events related to a subject 666 for some amount of time after that subject has been removed from the 667 stream. Event Receivers MUST tolerate receiving events for subjects 668 that have been removed from the stream, and MUST NOT report these 669 events as errors to the Event Transmitter. 671 6. Normative References 673 [DELIVERY] 674 "SET Token Delivery Using HTTP", n.d., . 678 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 679 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 680 2014, . 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 684 RFC2119, March 1997, 685 . 687 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 688 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 689 . 691 [SET] "Security Event Token (SET)", n.d., . 694 Authors' Addresses 696 Marius Scurtescu 697 Google 699 Email: mscurtescu@google.com 701 Annabelle Backman 702 Amazon 704 Email: richanna@amazon.com