idnits 2.17.1 draft-hunt-secevent-distribution-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 is 1 instance of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 2 instances 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 (March 8, 2017) is 2599 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: 'RFC5988' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC7516' is defined on line 1136, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-secevent-token-00 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hunt, Ed. 3 Internet-Draft Oracle 4 Intended status: Standards Track M. Scurtescu 5 Expires: September 9, 2017 Google 6 March 8, 2017 8 SET Token Delivery Using HTTP 9 draft-hunt-secevent-distribution-01 11 Abstract 13 This specification defines how a series of security event tokens 14 (SETs) may be delivered to a previously registered receiver using 15 HTTP over TLS. The specification defines the metadata the an Event 16 Transmitter uses to describe the Event Receiver's HTTP endpoint and 17 the SET token delivery configuration. The specification defines how 18 the Event Receiver may check the current configuration metadata and 19 delivery status using HTTP GET over TLS. The specification also 20 defines how delivery can be assured subject to the SET Token 21 Receiver's need for assurance. 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 http://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 September 9, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . 4 59 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Control Plane - Monitoring . . . . . . . . . . . . . . . . . 6 61 2.1. Event Stream Configuration . . . . . . . . . . . . . . . 6 62 2.2. Event Stream State Model . . . . . . . . . . . . . . . . 9 63 2.3. Checking Stream Configuration and Stream State . . . . . 11 64 3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 3.1. Event Delivery Process . . . . . . . . . . . . . . . . . 13 66 3.2. Event Stream State . . . . . . . . . . . . . . . . . . . 14 67 3.3. HTTP POST Delivery . . . . . . . . . . . . . . . . . . . 15 68 3.4. Event Stream Verification . . . . . . . . . . . . . . . . 18 69 4. Control Plane - Management and Provisioning . . . . . . . . . 20 70 4.1. Event Stream Resource Type Definition . . . . . . . . . . 20 71 4.2. Creating A New Event Stream . . . . . . . . . . . . . . . 22 72 4.3. Updating An Event Stream . . . . . . . . . . . . . . . . 24 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 75 6.1. SCIM Schema Registration . . . . . . . . . . . . . . . . 26 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 78 7.2. Informative References . . . . . . . . . . . . . . . . . 27 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 27 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 83 1. Introduction and Overview 85 This specification defines how a stream of SETs (see 86 [I-D.ietf-secevent-token]) can be transmitted to a previously 87 registered Event Receiver using HTTP POST [RFC7231] over TLS. The 88 specification defines the metadata the Event Transmitter uses to 89 describe the Event Receiver's HTTP endpoint and the SET token 90 delivery configuration. The specification defines how the Event 91 Receiver may check the current configuration metadata and delivery 92 status using HTTP GET over TLS. The specification also defines how 93 delivery can be assured subject to the SET Token Receiver's need for 94 assurance. 96 The following diagram shows a typical SET Event Stream. A stream 97 consists of a pair of HTTP endpoints, one for the event stream 98 transmitter and one for the receiver. The receiver endpoint is used 99 by the transmitter to deliver SET events via HTTPS POST and is known 100 as the "Data Plane". The transmitter's HTTP endpoint is used by the 101 receiver to perform HTTPS GET requests to check the stream status and 102 is known as the "Control Plane". In the diagram, the arrow heads 103 point to the service provider (the direction of an HTTP request): 105 +-----------+ Data Plane +----------+ 106 |Transmitter+------HTTP POST--------> Receiver | 107 | <------HTTP GET---------+ | 108 +-----------+ Control Plane +----------+ 110 Figure 1: SET Event Stream 112 In some service provider relationships, for example between Identity 113 Providers and Relying Parties, there may be a need to have bi- 114 directional SET event exchange. This involves establishing a second 115 event stream that works with transmitter and receiver roles reversed. 117 Identity Relying 118 Provider Party 120 IDP to RP Stream 122 +-----------+ Data Plane +------------+ 123 |Transmitter+-----------------------> Receiver | 124 | <-----------------------+ | 125 +-----------+ Control Plane +------------+ 127 RP to IDP Stream 129 +-----------+ Data Plane +------------+ 130 | Receiver <-----------------------+ Transmitter| 131 | +-----------------------> | 132 +-----------+ Control Plane +------------+ 134 Figure 2: Duplexed Streams 136 This specification contains two major sections: 138 Control Plane The service through which Event Receivers can review 139 and optionally managed Event Streams. It defines the metadata 140 associated with Event Streams along with stream status reporting. 142 Data Plane Through which SET Events are delivered by an Event 143 Transmitter to an Event Receiver using a defined Event Stream. 144 The Data Plane includes a verification process which tests and 145 validates Event Stream configuration. The Data plan defines 146 processing and error signaling used in the delivery of SETs. 148 1.1. Notational Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119] . These 153 keywords are capitalized when used to unambiguously specify 154 requirements of the protocol or application features and behavior 155 that affect the inter-operability and security of implementations. 156 When these words are not capitalized, they are meant in their 157 natural-language sense. 159 For purposes of readability examples are not URL encoded. 160 Implementers MUST percent encode URLs as described in Section 2.1 of 161 [RFC3986] . 163 Throughout this documents all figures MAY contain spaces and extra 164 line-wrapping for readability and space limitations. Similarly, some 165 URI's contained within examples, have been shortened for space and 166 readability reasons. 168 1.2. Definitions 170 This specification assumes terminology defined in the Security Event 171 Token specification[I-D.ietf-secevent-token] . 173 The following definitions are defined for Security Event 174 distribution: 176 Identity Provider 177 An Identity Provider is a service provider that issues 178 authentication assertions that may be used by Relying Party 179 service providers to establish login sessions with users. 180 Examples of Identity Providers are defined in: OpenID Connect 181 [openid-connect-core] and SAML2 [saml-core-2.0]. For the purpose 182 of this specification an Identity Provider also includes any 183 provider of services where the compromise of an account may open 184 up relying parties to attack. For example for the purposes of 185 security events, an email service provider could be considered an 186 "implicit" Identity Provider. 188 Relying Party 189 A Relying Party is a service provider that accepts assertions from 190 Identity Providers to establish sessions. Examples of Relying 191 Parties are defined in: OpenID Connect [openid-connect-core] and 192 SAML2 [saml-core-2.0] 194 Event Transmitter 195 A service provider that delivers SETs to other providers known as 196 Event Receivers. Some examples of Event Transmitters are Identity 197 Providers and Relying Parties. An Event Transmitter is 198 responsible for offering a service that allows the Event Receiver 199 to check the Event Stream configuration and status known as the 200 "Control Plane". 202 Event Receiver 203 A service provider that registers to receive SETs from an Event 204 Transmitter and provides an endpoint to receive SETs via HTTP POST 205 (known as the "Data Plane"). Some examples of Event Receivers are 206 Identity Providers and Relying Parties. Event Receivers can check 207 current Event Stream configuration and status by accessing the 208 Event Transmitters "Control Plane". 210 Event Stream 211 An Event Stream establishes Event Receiver communication 212 endpoints, security configuration and feed content that is used by 213 an Event Transmitter to send a series of SET Events to an Event 214 Receiver. An Event Stream defines a "Data Plane" and "Control 215 Plane" service relationship between an Event Transmitter and and 216 Event Receiver. 218 Control Plane 219 A Control Plane represents an service offered by an Event 220 Transmitter that lets an Event Receiver query the current 221 operational and/or error status of an Event Stream. The Control 222 Plane MAY also be used to retrieve Event Stream and SET 223 configuration data. 225 Data Plane 226 The Data Plane represents the HTTP service offered by an Event 227 Receiver that allows the Event Transmitter to deliver multiple 228 SETs via HTTP POST as part of an Event Stream. 230 Event Family 231 An Event Family is a URI that describes the set of events types be 232 issued in an Event Stream. 234 Subject 235 The security subject around which a security event has occurred. 236 For example, a security subject might per a user, a person, an 237 email address, a service provider entity, an IP address, an OAuth 238 Client, a mobile device, or any identifiable thing referenced in 239 security and authorization systems. 241 2. Control Plane - Monitoring 243 The Control Plane is provided by the Event Transmitter and enables 244 Event Receivers to check the Event Stream configuration and check for 245 transmission errors. This section describes mandatory to implement 246 functionality to enable Event Receivers to detect SET delivery 247 problems that may occur when an Event Transmitter fails to deliver 248 SETs. 250 Implementers MAY optionally implement and support full Event Stream 251 provisioning and management as described in Section 4. This 252 functionality also allows Event Receivers to "pause", "disable", or 253 re-enable Event Streams in scenario where the operational needs of 254 the receiver need to be co-ordinated with Event Transmitters (see 255 Section 2.2 and Section 4.3). 257 SCIM defines flexible mechanisms to ease adaptability to different 258 underlying data systems while maximizing inter-operabilty. Section 2 259 [RFC7643] SHALL provide the processing rule that enable Control Plane 260 providers and clients negotiate specific attributes (metadata) 261 including differing provider definitions of attribute types, 262 mutability, cardinality, or returnability that MAY differ. For HTTP 263 method handling and error signaling, the processing rules in 264 [RFC7644] SHALL apply. 266 2.1. Event Stream Configuration 268 An Event Stream represents an agreement to deliver SETs from a 269 specified Feed URI from an Event Transmitter to an Event Receiver. 270 The method of delivery and the parameters for delivery are specified 271 a set of parameters called Event Stream metadata (see Section 2.1). 273 An Event Stream is defined by the following metadata: 275 feedUri 276 An OPTIONAL JSON String value containing the URI for a feed 277 supported by the feed provider. It describes the content of the 278 feed and MAY also be a resolvable URI where the feed meta data may 279 be returned as a JSON object. REQUIRED. 281 methodUri 282 A REQUIRED JSON String value which is a URI with a prefix of 283 "urn:ietf:params:set:method". This specification defines HTTP 284 POST delivery method: 285 "urn:ietf:params:set:method:HTTP:webCallback" 286 in which the Feed Provider delivers events using HTTP POST to a 287 specified callback URI. 289 deliveryUri 290 A JSON String value containing a URI that describes the location 291 where SETs are received (e.g. via HTTP POST). Its format and 292 usage requirements are defined by the associated "methodUri". 294 aud 295 An OPTIONAL JSON Array of JSON String values which are URIs 296 representing the audience(s) of the Event Stream. The value SHALL 297 be the value of SET "aud" claim sent to the Event Receiver. 299 feedJwk 300 An OPTIONAL public JSON Web Key (see [RFC7517]) from the Event 301 Transmitter that will be used by the Event Receiver to verify the 302 authenticity of issued SETs. 304 confidentialJwk 305 An OPTIONAL public JSON Web Key (see [RFC7517]) for the Event 306 Receiver that MAY be used by the Feed Provider to encrypt SET 307 tokens for the specified Event Receiver. 309 subStatus 310 An OPTIONAL JSON String keyword that indicates the current state 311 of an Event Stream. More information on the Event Stream state 312 can be found in Section 2.2. Valid keywords are: 314 "on" - indicates the Event Stream has been verified and that 315 the Feed Provider MAY pass SETs to the Event Receiver. 317 "verify" - indicates the Event Stream is pending verification. 318 While in "verify", SETs, except for the verify SET (see 319 Section 3.4) are not delivered to the Event Receiver. Once 320 verified, the status returns to "on". 322 "paused" - indicates the Event Stream is temporarily suspended. 323 While "paused", SETs SHOULD be retained and delivered when 324 state returns to "on". If delivery is paused for an extended 325 period defined by the Event Transmitter, the Event Transmitter 326 MAY change the state to "off" indicating SETs are no longer 327 retained. 329 "off" - indicates that the Event Stream is no longer passing 330 SETs. While in off mode, the Event Stream metadata is 331 maintained, but new events are ignored, not delivered or 332 retained. Before returning to "on", a verification MUST be 333 performed. 335 "fail" - indicates that the Event Stream was unable to deliver 336 SETs to the Event Receiver due an unrecoverable error or for an 337 extended period of time. Unlike paused status, a failed Event 338 Stream does not retain existing or new SETs that are issued. 339 Before returning to "on", a verification MUST be performed. 341 maxRetries 342 An OPTIONAL JSON number indicating the maximum number of attempts 343 to deliver a SET. A value of '0' indicates there is no maximum. 344 Upon reaching the maximum, the Event Stream "subStatus" attribute 345 is set to "failed". 347 maxDeliveryTime 348 An OPTIONAL number indicating the maximum amount of time in 349 seconds a SET MAY take for successful delivery per request or 350 cumulatively across multiple retries. Upon reaching the maximum, 351 the Event Stream "subStatus" is set to "failed". If undefined, 352 there is no maximum time. 354 minDeliveryInterval 355 An OPTIONAL JSON integer that represents the minimum interval in 356 seconds between deliveries. A value of '0' indicates delivery 357 should happen immediately. When delivery is a polling method 358 (e.g. HTTP GET), it is the expected time between Event Receiver 359 attempts. When in push mode (e.g. HTTP POST), it is the interval 360 the server will wait before sending a new event or events. 362 txErr 363 An OPTIONAL JSON String keyword value. When the Event Stream has 364 "subState" set to "fail", one of the following error keywords is 365 set: 367 "connection" indicates an error occurred attempting to open a 368 TCP connection with the assigned endpoint. 370 "tls" indicates an error occurred establishing a TLS connection 371 with the assigned endpoint. 373 "dnsname" indicates an error occurred establishing a TLS 374 connection where the dnsname was not validated. 376 "receiver" indicates an error occurred whereby the Event 377 Receiver has indicated an error for which the Event Transmitter 378 is unable to correct. 380 [[Editors note: other conditions?]] 382 txErrDesc 383 An OPTIONAL String value that is usually human readable that 384 provides further diagnostic detail by the indicated "txErr" error 385 code. 387 Additional Event Stream metadata (attributes) MAY be defined as 388 extensions. The method for adding new attributes is defined in 389 Section 3.3 [RFC7643]. 391 2.2. Event Stream State Model 393 The Event Stream configuration attribute "subStatus" tracks the state 394 of any particular Event Stream with regards to whether SETs are ready 395 or able to be delivered. The impact on delivery processing is 396 described in Table 1. 398 The following is the state machine representation of a Event Stream 399 on a Event Transmitter. Note that a Event Stream cannot be made 400 active until a verification process has been completed. As such, a 401 newly created Event Stream begins with state "verify". 403 + 404 | 405 Create 406 v 407 +------+ +----------+ 408 | fail +->Restart---->| verify | 409 +------+ +----+-----+ 410 ^ | 411 |<----Confirm Fail<----+ 412 | Confirm 413 | v 414 | +----------+ +--------+ 415 | | +--->Suspend--->| | 416 +------Timeout<---+ on | | paused | 417 | |<--Resume<-----+ | 418 +-+--------+ +----+---+ 419 | ^ | 420 Disable Enable | 421 v | | 422 +--------+-+ | 423 | off |<----Limited<-------+ 424 +----------+ 426 Figure 3: Event Stream States at Event Transmitter 428 In the above diagram, the following actions impact the state of an 429 Event Stream. "subStatus" values are shown in the boxes, and change 430 based on the following actions: 432 Create 433 A Event Receiver or an administrator creates a new Event Stream 434 using SCIM as described in Section 4.2. The initial state is 435 "verify". 437 Confirm 438 The Event Transmitter sends a verification SET to the Event 439 Receiver which confirms with the correct response as described in 440 Section 3.4. If it succeeds to deliver, the Event Transmitter 441 SHALL set state to "on". 443 Confirm Fail 444 If the confirmation fails, the Event Transmitter sets the state to 445 "fail" requiring administrative action to correct the issue and 446 "Restart". 448 Timeout 449 A Event Transmitter who has not been able to deliver a SET over 450 one or more retries which has reached a limit of attempts 451 ("maxRetries") or time ("maxDeliveryTime") MAY set the Event 452 Stream state to "fail". In general, the intention is to indicate 453 the maximum number of retries or time a Event Transmitter is able 454 to wait until SET event loss begins to occur resulting in the 455 failed state. 457 Limited 458 A paused Event Stream has reached a limit and the Event 459 Transmitter can no longer retain SETs. The Event Transmitter 460 changes the state to "off". 462 Restart 463 An administrator having corrected the failed delivery condition 464 modifies the Event Stream state to "verify" (e.g. see 465 Section 4.3). 467 Suspend and Resume 468 An Event Stream MAY be suspended and resumed by updating the Event 469 Stream state to "paused" or "on". For example, see see 470 Section 4.3. While suspended, the Event Transmitter MAY retain 471 undelivered SETs for a period of time. If the Event Transmitter 472 is no longer able to retain SETs, the Event Stream state SHOULD be 473 set to "off" to indicate SETs are being lost. 475 Enable and Disable 476 A Event Stream MAY be disabled and enabled by updating the Event 477 Stream state to "off" or "on". For example, see see Section 4.3. 478 While the Event Stream is disabled, all SETs that occur at the 479 Event Transmitter are lost. 481 2.3. Checking Stream Configuration and Stream State 483 An Event Receiver MAY check the current status of a Stream with the 484 Event Transmitter, by performing an HTTP GET using the provided URI 485 from the Transmitter. 487 The format of the response is defined by Section TBD [RFC7644]. 489 In addition to the attributes defined in Section 2.1, the response 490 SHALL include an additional JSON attribute "schemas" with at least a 491 single value of "urn:ietf:params:scim:schemas:event:2.0:EventStream". 492 This static attribute is provided to enable optional SCIM client 493 compatibility and informs the client of the type of JSON object being 494 returned. Service providers may offer additional attributes by 495 adding additional schema values as per [RFC7644]. 497 The response below shows an example response to an HTTP GET, in this 498 case to "https://example.com/v2/ 499 EventStreams/767aad7853d240debc8e3c962051c1c0". 501 HTTP/1.1 200 OK 502 Content-Type: application/json 503 Location: 504 https://example.com/v2/EventStreams/767aad7853d240debc8e3c962051c1c0 506 { 507 "schemas":["urn:ietf:params:scim:schemas:event:2.0:EventStream"], 508 "id":"767aad7853d240debc8e3c962051c1c0", 509 "feedName":"OIDCLogoutFeed", 510 "feedUri": 511 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 512 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 513 "deliveryUri":"https://notify.examplerp.com/Events", 514 "aud":"https://sets.myexamplerp.com", 515 "subStatus":"fail", 516 "txErr":"connection", 517 "txErrDesc":"TCP connect error to notify.examplerp.com.", 518 "maxDeliveryTime":3600, 519 "minDeliveryInterval":0, 520 "description":"Logout events from oidc.example.com", 521 "meta":{ 522 ... SCIM meta attributes ... 523 } 524 } 526 Figure 4: Example Stream GET Response 528 In the above figure, the Event Stream is showing a failed status due 529 to a TCP connection error. The Event Receiver is able to discover 530 that its endpoint was unavailable and has been marked failed by the 531 Event Transmitter. It is expected that the appropriate operations 532 staff would be alerted and some corrective action would be taken. 534 The frequency with which Event Receivers should poll the Event Stream 535 status depends on the following factors: 537 o The level of technical fault tolerance and availability of the 538 receiving endpoint. 540 o A frequency appropriate to the amount of risk that can be 541 tolerated for lost events. For example, if Security Events are 542 considered informational, then infrequent (hourly or daily) may be 543 sufficient. 545 In most cases Event Stream status polling can be triggered on a 546 timeout basis. Event Receivers would typically poll if they have not 547 received a SET for some period during which SETs would be expected 548 based on past experience. 550 3. Data Plane 552 The data plane represent the HTTP request channel by which the Event 553 Transmitter delivers SET Events to an Event Receiver. 555 3.1. Event Delivery Process 557 When a Security Event occurs, the Feed Provider constructs a SET 558 token [I-D.ietf-secevent-token] that describes the event. The feed 559 provider determines the feeds that the event should be distributed 560 to, and determines which Event Receivers need to be notified. 562 How SET Events are defined and the process by which events are 563 identified for Event Receivers is out-of-scope of this specification. 565 When a SET is available for a Event Receiver, the Feed Transmitter 566 attempts to deliver the SET based on the Event Receiver's registered 567 delivery mechanism: 569 o The Event Transmitter uses an HTTP/1.1 POST to the Event Receiver 570 endpoint to deliver the SET; 572 o Or, the Feed Transmitter delivers the event through a different 573 method not defined by this specification. 575 Feed Transmitters SHALL NOT be required to main or record SETs. As 576 such, transmitted SETs SHOULD be self-validating (e.g. signed). 578 If delivery to any particular Event Receiver has been delayed for an 579 extended period of time, the Feed Transmitter MAY suspend the 580 affected Event Stream and even stop maintaining outstanding SETs for 581 the Event Receiver at its discretion and available resources. See 582 Event Stream "subState" in Section 2.1. 584 Upon receiving a SET, the Event Receiver reads the SET and validates 585 it. Based upon the content of the token, the Event Receiver decides 586 what, if any, action needs to be taken in response to the received 587 SET. For example, in response to a SCIM provisioning event 588 [idevent-scim] indicating a changed resource, the Event Receiver 589 might perform a SCIM GET request (see Section 3.4 [RFC7644]) to the 590 affected resource URI in order to confidentially obtain the current 591 state of the transmitter's affected SCIM resource in order to 592 reconcile local corresponding state changes. 594 The action a Event Receiver takes in response to a SET MAY be 595 substantially different than merely copying the action of the SET 596 issuer. A single SET can trigger one or more receiver actions or it 597 can be ignored. For example, upon receiving notification that a user 598 resource has been added to a group, the Event Receiver may first 599 determine that the user does not exist in the Event Receiver's 600 domain. The Event Receiver translates the event into two actions: 602 1. Retrieve the user (e.g. using SCIM GET) and then provisions the 603 user locally. After enabling the user, 605 2. The Event Receiver then enables the user for the application 606 associated with membership in the issuer's group. 608 3.2. Event Stream State 610 As mentioned in Section 2.1, the attribute "subStatus" defines the 611 current state of an Event Stream. Figure 3 shows a state diagram for 612 Event Streams. The following describes that actions taken by the 613 Event Transmitter based upon "subStatus". 615 +--------+----------------------------------------------------------+ 616 | Status | Action | 617 +--------+----------------------------------------------------------+ 618 | on | Delivery SHALL be attempted based on the method defined | 619 | | in the Event Stream attribute "methodUri". If the SET | 620 | | fails to deliver it MAY be retained for a retry delivery | 621 | | in a minimum of "minDeliveryInterval" seconds. If new | 622 | | SETs arrive before the interval, the SETs MUST be held | 623 | | for delivery in order of reception. If this is a repeat | 624 | | attempt to deliver, the Event Transmitter MAY discard | 625 | | the SET if "maxRetries" or "maxDeliveryTime" is | 626 | | exceeded. If a SET is discarded, the Event Transmitter | 627 | | MAY set "subStatus" to "failed". | 628 | verify | If the SET is not a Verify SET, the SET MAY be retained | 629 | | for a retry at the Event Transmitter's discretion. If a | 630 | | Verify SET fails to deliver, the Event Transmitter SHALL | 631 | | set "subStatus" to "failed". The Event Transmitter MAY | 632 | | opt to make multiple attempts to complete a verification | 633 | | during which status remains as "verify". | 634 | paused | The SET is held for delivery in a queue. The Event | 635 | | Transmitter MAY at its own discretion set the Event | 636 | | Stream state to "failed" if "subStatus" is not returned | 637 | | to "on" in what the Event Transmitter determines to be a | 638 | | reasonable amount of time. | 639 | off | The SET is ignored. | 640 | fail | The SET is ignored due to a previous unrecoverable | 641 | | error. | 642 +--------+----------------------------------------------------------+ 644 Table 1: Delivery Processing By Status 646 3.3. HTTP POST Delivery 648 This method allows a feed provider to use HTTP POST (Section 4.3.3 649 [RFC7231]) to deliver SETs to the registered web callback URI 650 identified in the Event Stream configuration. The Event Stream 651 "methodUri" value for this method is 652 "urn:ietf:params:set:method:HTTP:webCallback". 654 The SET to be delivered MAY be signed and/or encrypted as defined in 655 [I-D.ietf-secevent-token]. 657 The Event Stream's "deliveryUri" attribute indicates the location of 658 a Event Receiver provided endpoint which accepts HTTP POST requests 659 (e.g. "https://notify.examplerp.com/Events"). 661 The content-type for the HTTP POST is "application/jwt" and SHALL 662 consists of a single SET token (see [I-D.ietf-secevent-token]). 664 eyJhbGciOiJub25lIn0 665 . 666 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 667 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 668 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 669 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 670 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 671 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 672 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 673 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 674 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 675 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 676 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 677 . 679 Figure 5: Encoded SET To Be Transmitted 681 To deliver an event, the Event Transmitter generates an event 682 delivery message and uses HTTP POST to the EventStream configured 683 endpoint. The content-type of the message is "application/jwt" and 684 the expected response type (accept) is "application/json". 686 POST /Events HTTP/1.1 688 Host: notify.examplerp.com 689 Accept: application/json 690 Content-Type: application/jwt 691 "eyJhbGciOiJub25lIn0 692 . 693 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 694 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 695 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 696 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 697 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 698 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 699 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 700 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 701 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 702 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 703 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 704 . 706 Figure 6: Example Web Callback POST Request 708 Upon receipt of the request, the Event Receiver SHALL validate the 709 JWT structure of the SET as defined in Section 7.2 [RFC7519]. The 710 Event Receiver SHALL also validate the SET information as described 711 in Section 2 [I-D.ietf-secevent-token]. 713 If the SET is determined to be valid, the Event Receiver SHALL 714 indicate successful submission by responding with HTTP Status 202 as 715 "Accepted" (see Section 6.3.3 [RFC7231]). 717 If SET or JWT is invalid, or there is an HTTP error, the Event 718 Receiver SHALL respond with the appropriate HTTP error or an HTTP 719 Status 400 Bad Request error as follows: 721 +----------+--------------------------------------------------------+ 722 | Err | Description | 723 | Value | | 724 +----------+--------------------------------------------------------+ 725 | jwtParse | Invalid or unparsable JWT or JSON structure. | 726 | jwtHdr | In invalid JWT header was detected. | 727 | jwtCypto | Unable to parse due to unsupported algorithm. | 728 | jws | Signature was not validated. | 729 | jwe | Unable to decrypt JWE encoded data. | 730 | jwtAud | Invalid audience value. | 731 | jwtIss | Issuer not recognized. | 732 | setType | An unexpected event type was received. | 733 | setParse | Invalid structure was encountered such as inability to | 734 | | parse SET event payload. | 735 | setData | SET event claims incomplete or invalid. | 736 | dup | A duplicate SET was received and has been ignored. | 737 +----------+--------------------------------------------------------+ 739 Table 2: HTTP Status 400 Errors 741 The following is a non-normative example of a successful receipt of a 742 SET. 744 HTTP/1.1 202 Accepted 746 Figure 7: Example Successful Delivery Response 748 An HTTP Status 400 Bad Request response includes a JSON object which 749 provides details about the error. The JSON object includes the JSON 750 attributes: 752 err 753 A value which is a keyword that describes the error (see Table 2). 755 description 756 A human-readable text that provides additional diagnostic 757 information. 759 The following is an example non-normative Bad Request error. 761 HTTP/1.1 400 Bad Request 762 Content-Type: application/json 764 { 765 "err":"dup", 766 "description":"SET already received. Ignored." 768 } 770 Figure 8: Example Bad Request Response 772 3.4. Event Stream Verification 774 To confirm an Event Stream configuration, the Event Transmitter SHALL 775 send a verification SET to the Event Receiver using the registered 776 "methodUri" mechanism which in this case is 777 "urn:ietf:params:set:method:HTTP:webCallback". 779 The Verify SET contains the following attributes: 781 events Set with a value of "[[this RFC URL]]#verify". 783 iss Set to the URI defined in the Event Stream metadata (see 784 Section 2.1). 786 aud MUST be set to a value that matches the EventStream "aud" value 787 (see Section 2.1). 789 exp A value that indicates the time the verification request will 790 expire. Once expired, the server will set the Event Stream state 791 to "fail". 793 If the Event Stream "confidentialJWK" value was supplied, then the 794 SET SHOULD be encrypted with the provided key. Successful parsing of 795 the message confirms that provides confirmation of correct 796 configuration and possession of keys. 798 A payload attribute "confirmChallenge" is provided with a JSON String 799 value that the Event Receiver SHALL echo back in its response. The 800 intent is to confirm that the Event Receiver has successfully parsed 801 the SET and is not just echoing back HTTP success. 803 A non-normative JSON representation of an event to be sent to a Event 804 Receiver as a Event Stream confirmation. Note the event is not yet 805 encoded as a JWT token: 807 { 808 "jti": "4d3559ec67504aaba65d40b0363faad8", 809 "events":["[[this RFC URL]]#verify"], 810 "iat": 1458496404, 811 "iss": "https://scim.example.com", 812 "exp": 1458497000, 813 "aud":[ 814 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 815 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 816 ], 817 "[[this RFC URL]]#verify":{ 818 "confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7" 819 } 820 } 822 Figure 9: Example Verification SET with Challenge 824 The above SET is encoded as a JWT and transmitted to the Event 825 Receiver as shown in Figure 6. 827 Upon receiving a verify SET, the Event Receiver SHALL respond with a 828 JSON object that includes a "challengeResponse" attribute and the 829 value that was provided in "confirmChallenge". The content type 830 header is set to "application/json". 832 The following is a non-normative example response to a Verify SET 833 received via HTTP/1.1 POST and includes a JSON object containing the 834 confirmation attribute and value. 836 HTTP/1.1 200 OK 837 Content-Type: application/json 839 { 840 "challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7" 841 } 843 Figure 10: Example Response to Verify SET with Challenge 845 If the Event Receiver returns a non-matching value or an HTTP status 846 other than a 200 series response, the Event Stream "state" SHALL be 847 set to "fail". A declining Event Receiver MAY simply respond with 848 any 400 series HTTP error (e.g. 404). 850 4. Control Plane - Management and Provisioning 852 This section describes how SCIM [RFC7644] and [RFC7643] MAY be used 853 to add create, read, update, delete capability to the Control Plane 854 to enable provisioning and operational management of Event Streams. 855 In addition to provisioning of Event Streams, it can also be used by 856 Event Receivers to change or reset the operational state of Event 857 Streams such as pausing, stopping, or re-enabling after a failure. 859 SCIM is a protocol used by many security systems for provisioning and 860 co-ordinating identities and other security subjects in cross-domain 861 scenarios. SCIM is a RESTful profile of HTTP that is intended to be 862 implemented by applications that need provisioning and management of 863 security subjects and is ideal to the task of provisioning related 864 security event signal systems. Examples of provisioning endpoints 865 (SCIM service providers) include both Identity Providers and Relying 866 Party applications (e.g. business and consumer web applications) as 867 well as security and authorization infrastructure components. 869 [[Editors Note: At the time of writing, some groups feel a CRUD API 870 is not required and participants would prefer to manage streams using 871 an out-of-band workflow approach.]] 873 4.1. Event Stream Resource Type Definition 875 To extend SCIM to support Event Streams, requires defining an 876 "EventStream" SCIM resource type, and implementing the corresponding 877 RESTful HTTP operations to create, update, retrieve EventStream 878 Resources. For SCIM service provider capability and schema discovery 879 (see Sections 3 and 4 [RFC7644]). 881 The "EventStream" resource type definition is defined as follows: 883 { 884 "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], 885 "id": "EventStream", 886 "name": "EventStream", 887 "endpoint": "/EventStreams", 888 "description": "Endpoint and event configuration and status for SEC EVENT streams.", 889 "schema": "urn:ietf:params:scim:schemas:event:2.0:EventStream", 890 "schemaExtensions": [] 891 } 893 The resource type above is discoverable in the "/ResourceTypes" and 894 informs SCIM clients about the endpoint location of EventStream 895 resources and the SCIM schema used to define the resource. The 896 corresponding schema for the EventStream resource MAY be retrieved 897 from the SCIM "/Schemas" endpoint (see Section 3.2 [RFC7644]). 899 Figure 11: SCIM EventStream Resource Type Definition 901 To retrieve information about one or more Event Streams, authorized 902 clients MAY query the "/EventStreams" endpoint as defined in 903 Section 3.4 [RFC7644]. 905 The example below retrieves a specific "EventStream" resource whose 906 "id" is "548b7c3f77c8bab33a4fef40". 908 GET /EventStreams/767aad7853d240debc8e3c962051c1c0 909 Host: example.com 910 Accept: application/json 911 Authorization: Bearer h480djs93hd8 913 Figure 12: Example SCIM EventStream HTTP GET Request 915 The response below shows an example Feed resource that describes an 916 available feed. 918 HTTP/1.1 200 OK 919 Content-Type: application/json 920 Location: 921 https://example.com/v2/EventStreams/767aad7853d240debc8e3c962051c1c0 923 { 924 "schemas":["urn:ietf:params:scim:schemas:event:2.0:EventStream"], 925 "id":"767aad7853d240debc8e3c962051c1c0", 926 "feedName":"OIDCLogoutFeed", 927 "feedUri": 928 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 929 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 930 "deliveryUri":"https://notify.examplerp.com/Events", 931 "aud":"https://sets.myexamplerp.com", 932 "subStatus":"verify", 933 "maxDeliveryTime":3600, 934 "minDeliveryInterval":0, 935 "description":"Logout events from oidc.example.com", 936 "meta":{ 937 ... SCIM meta attributes ... 938 } 939 } 941 Figure 13: Example EventStream HTTP GET Response 943 In the above example (Figure 13) the EventStream is for the the Feed 944 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74". The 945 current Event Stream state is "verify" which suggest the Event Stream 946 Verification (see Section 3.4) process has not yet completed. Since 947 there is no value for "feedJwk", ) or "confidentialJwk", SETs will be 948 sent without signing or encryption (plain text). 950 4.2. Creating A New Event Stream 952 To subscribe to a feed, the Event Receiver first obtains an 953 authorization credential authorizing to to make the request (this 954 process is out of scope of the specification but is often completed 955 through OAuth). Upon obtaining authorization, the Event Receiver 956 organization uses the SCIM Create operation (HTTP POST) as defined in 957 Section 3.3 [RFC7644]. Event Transmitter's Control Plane service MAY 958 have additional schema requirements for Event Stream creation which 959 MAY be discovered using SCIM service configuration and schema 960 discovery, see Section 4 [RFC7644]. 962 In the following non-normative example, a new EventStream is created. 963 Note that the Event Transmitter's control-plane automatically assigns 964 the "id" attribute. 966 POST /EventStreams 967 Host: example.com 968 Accept: application/scim+json 969 Content-Type: application/scim+json 970 Authorization: Bearer h480djs93hd8 972 { 973 "schemas":["urn:ietf:params:scim:schemas:event:2.0:EventStream"], 974 "feedName":"OIDCLogoutFeed", 975 "feedUri": 976 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 977 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 978 "deliveryUri":"https://notify.examplerp.com/Events", 979 "aud":"https://sets.myexamplerp.com", 980 "maxDeliveryTime":3600, 981 "minDeliveryInterval":0, 982 "description":"Logout events from oidc.example.com" 983 } 985 Figure 14: Example Create Event Stream Request 987 In following non-normative response, the Event service provider has 988 automatically assigned a resource location as well as an "id". 989 Usually upon creation, the initial value of "subStatus" is "pending" 990 indicating that the Stream Verification process (see Section 3.4) has 991 not been completed. 993 HTTP/1.1 201 Created 994 Content-Type: application/scim+json 995 Location: 996 https://example.com/v2/EventStreams/767aad7853d240debc8e3c962051c1c0 998 { 999 "schemas":["urn:ietf:params:scim:schemas:event:2.0:EventStream"], 1000 "id":"767aad7853d240debc8e3c962051c1c0", 1001 "feedName":"OIDCLogoutFeed", 1002 "feedUri": 1003 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 1004 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 1005 "deliveryUri":"https://notify.examplerp.com/Events", 1006 "aud":"https://sets.myexamplerp.com", 1007 "subStatus":"verify", 1008 "maxDeliveryTime":3600, 1009 "minDeliveryInterval":0, 1010 "description":"Logout events from oidc.example.com", 1011 "meta":{ 1012 ... SCIM meta attributes ... 1013 } 1014 } 1016 Figure 15: Example Response to Create EventStream Request 1018 4.3. Updating An Event Stream 1020 Periodically, Event Receivers MAY have need to update an Event Stream 1021 configuration for the purpose of: 1023 o Rotating access credentials or keys 1025 o Updating endpoint configuration 1027 o Making operational changes such as pausing, resetting, or 1028 disabling an Event Stream. 1030 o Other operations (e.g. such as adding or removing subjects) as 1031 defined by profiling Event specifications. 1033 To modify an EventStream, an Event Receiver or authorized management 1034 client MAY use the HTTP PUT operation (see Section 3.5.1 [RFC7644]) 1035 or MAY use the HTTP PATCH operation (see Section 3.5.2 [RFC7644]) if 1036 supported by the Event Transmitter's control plane service. Note 1037 that HTTP PATCH enables more specific changes. This is particularly 1038 useful when updating multi-valued attributes that may contain large 1039 numbers of values. An example of this would be an EventStream that 1040 uses a "members" attribute to define the subjects of the Event 1041 Stream. 1043 In the following non-normative example, the client is requesting that 1044 "subStatus" be changed to "paused" for the EventStream whose path is 1045 identified by the request URI path. 1047 PATCH /EventStreams/767aad7853d240debc8e3c962051c1c0 1048 Host: example.com 1049 Accept: application/scim+json 1050 Content-Type: application/scim+json 1051 Authorization: Bearer h480djs93hd8 1053 { 1054 "schemas": 1055 ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], 1056 "Operations": [{ 1057 "op":"replace", 1058 "path":"subStatus", 1059 "value":"paused" 1060 }] 1061 } 1063 Upon receiving the request, the Event Transmitter would stop sending 1064 Events to the Receiver. Note that while the request MAY seem complex 1065 it avoids the need for the requestor to have all of the current 1066 EventStream values in order to make a PUT request. In other words, 1067 an HTTP PATCH can be typically done in a single request response 1068 whereas an HTTP POST usually is preceded by an HTTP GET. 1070 Figure 16: Example EventStream PATCH Request 1072 5. Security Considerations 1074 [TO BE COMPLETED] 1076 6. IANA Considerations 1077 6.1. SCIM Schema Registration 1079 As per the "SCIM Schema URIs for Data Resources" registry established 1080 by Section 10.3 [RFC7643], the following defines and registers the 1081 following SCIM URIs and Resource Types for Feeds and Event Streams. 1083 +---------------------------+----------+--------------+-------------+ 1084 | Schema URI | Name | ResourceType | Reference | 1085 +---------------------------+----------+--------------+-------------+ 1086 | urn:ietf:params:scim: | SET | EventStream | Section 2.1 | 1087 | schemas:event:2.0: | Event | | | 1088 | EventStream | Stream | | | 1089 +---------------------------+----------+--------------+-------------+ 1091 7. References 1093 7.1. Normative References 1095 [I-D.ietf-secevent-token] 1096 Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security 1097 Event Token (SET)", draft-ietf-secevent-token-00 (work in 1098 progress), January 2017. 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", BCP 14, RFC 2119, 1102 DOI 10.17487/RFC2119, March 1997, 1103 . 1105 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1106 Resource Identifier (URI): Generic Syntax", STD 66, 1107 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1108 . 1110 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1111 DOI 10.17487/RFC5988, October 2010, 1112 . 1114 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1115 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1116 DOI 10.17487/RFC7231, June 2014, 1117 . 1119 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1120 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1121 . 1123 7.2. Informative References 1125 [idevent-scim] 1126 Oracle Corporation, "SCIM Event Extensions (work in 1127 progress)". 1129 [openid-connect-core] 1130 NRI, "OpenID Connect Core 1.0", Nov 2014. 1132 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1133 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1134 2015, . 1136 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1137 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1138 . 1140 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1141 DOI 10.17487/RFC7517, May 2015, 1142 . 1144 [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. 1145 Mortimore, "System for Cross-domain Identity Management: 1146 Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 1147 2015, . 1149 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 1150 and C. Mortimore, "System for Cross-domain Identity 1151 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 1152 September 2015, . 1154 [saml-core-2.0] 1155 Internet2, "Assertions and Protocols for the OASIS 1156 Security Assertion Markup Language (SAML) V2.0", March 1157 2005. 1159 Appendix A. Acknowledgments 1161 The editors would like to thanks the members of the SCIM WG which 1162 began discussions of provisioning events starting with: draft-hunt- 1163 scim-notify-00 in 2015. 1165 The editor would like to thank the participants in the the SECEVENTS 1166 working group for their support of this specification. 1168 Appendix B. Change Log 1170 Draft 00 - PH - First Draft based on reduced version of draft-hunt- 1171 idevent-distribution 1173 Draft 01 - PH - 1175 o Reworked terminology to match new WG Transmitter/Receiver terms 1177 o Reworked sections into Data Plane vs. Control Plane 1179 o Removed method transmission registry in order to simplify the 1180 specification 1182 o Made Create, Update operations optional for Control Plane (Read is 1183 MTI) 1185 Authors' Addresses 1187 Phil Hunt (editor) 1188 Oracle Corporation 1190 Email: phil.hunt@yahoo.com 1192 Marius Scurtescu 1193 Google 1195 Email: mscurtescu@google.com