idnits 2.17.1 draft-hunt-secevent-usecases-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 : ---------------------------------------------------------------------------- == 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 (June 30, 2017) is 2484 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) == Missing Reference: 'P0' is mentioned on line 542, but not defined == Missing Reference: 'P2' is mentioned on line 710, but not defined == Unused Reference: 'RFC3339' is defined on line 773, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-secevent-token-00 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 761 (Obsoleted by RFC 793, RFC 7805) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). 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. Ansari 5 Expires: January 1, 2018 Cisco 6 June 30, 2017 8 SCIM Use Cases for SECEVENTS 9 draft-hunt-secevent-usecases-00 11 Abstract 13 This specification defines the SCIM use cases for the SECEVENTs 14 working group. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 1, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 52 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. SCIM Background . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. High-Level Requirements . . . . . . . . . . . . . . . . . . . 5 55 3.1. SCIM Event Trigger Requirements . . . . . . . . . . . . . 5 56 3.2. SCIM Security Model Considerations . . . . . . . . . . . 5 57 3.3. Control Plane Assumptions . . . . . . . . . . . . . . . . 6 58 3.4. Network and Protocol Operational Considerations . . . . . 8 59 3.5. Dynamic Filtering Considerations . . . . . . . . . . . . 8 60 3.6. Directory and Application Provisioning . . . . . . . . . 8 61 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Scenario 1[P0]: Cloud-to-Enterprise PUSH and Cloud-to- 63 Cloud PUSH . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Scenario 2[P0]: Cloud-to-Enterprise POLLING . . . . . . . 12 65 4.3. Scenario 3[P2]: Cloud-to-Mobile Application PUSH . . . . 16 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 71 8.2. Informative References . . . . . . . . . . . . . . . . . 17 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 73 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction and Overview 78 SCIM is a system intended for provisioning identities (such as 79 enterprise users or consumers) and other objects across security 80 domains to a cloud based service providers. SCIM defines an 81 extensible JSON [RFC7643] document format and profiles HTTP protocol 82 [RFC7644]. In practice, SCIM service providers are applications 83 supporting pre-provisioning support, or may be a service provider 84 directory upon which applications are integrated. 86 This document defines the operational requirements SCIM deployers 87 have for the use of triggers, as defined in the SCIM Use Cases 88 specification [RFC7642], and used in the form of security events and 89 the requirements for management based on SCIM architectural 90 assumptions. 92 1.1. Notational Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119] . These 97 keywords are capitalized when used to unambiguously specify 98 requirements of the protocol or application features and behavior 99 that affect the inter-operability and security of implementations. 100 When these words are not capitalized, they are meant in their 101 natural-language sense. 103 For purposes of readability examples are not URL encoded. 104 Implementers MUST percent encode URLs as described in Section 2.1 of 105 [RFC3986] . 107 Throughout this documents all figures MAY contain spaces and extra 108 line-wrapping for readability and space limitations. Similarly, some 109 URI's contained within examples, have been shortened for space and 110 readability reasons. 112 1.2. Definitions 114 This specification assumes terminology defined in the Security Event 115 Token specification[I-D.ietf-secevent-token] . 117 This specification assumes terminology defined in the SCIM 118 specifications, specifically [RFC7643] and [RFC7644] 120 This specification defines the following terms: 122 Directory 123 Defined as any centralized repository of security objects shared 124 by multiple applications. A SCIM Directory, though not formally 125 defined is simply a directory that supports SCIM protocol. 127 2. SCIM Background 129 The SCIM Core Schema specification [RFC7643] is a profile of JSON 130 [RFC7159] that defines attribute types, mutability, data formats, 131 composites, and multi-value attributes as well as SCIM Service 132 Provider feature and schema discovery metadata. As core schema 133 defines standard resource types: Users and Groups which are common to 134 most service providers. Each resource type establishes a common set 135 of attribute definitions that can be mapped to SAML [saml-core-2.0] 136 and to OpenID Connect [openid-connect-core] as well as application 137 specific attributes. The core schema specification provides an 138 extension mechanism which has been popular in: 140 o Being extended to describe many security objects such as OAuth 141 Clients, Applications, IoT objects, among others. 143 o Enabling localized extensions to standard resource types (e.g. 144 Users) without compromising inter-operability of existing 145 implementations. 147 The SCIM Protocol specification [RFC7644] describes a RESTful profile 148 of HTTP [RFC7231] that defines create, read, update and delete life- 149 cycle for resources. The processing rules follow Jon Postel's 150 "Robustness Principle" (see Section 2.10 [RFC761]) which help avoid 151 many of the failings of previous XML based approaches. In particular 152 the use of robust RESTful JSON helped ensure client and server 153 ability to deal with inter-domain differences in schema, data, and 154 implementation avoiding a lot of per implementation/deployment custom 155 connector approaches. 157 SCIM clients use HTTP requests to SCIM service providers as follows 158 to: 160 o Query for resources (users and groups) based on filters using HTTP 161 GET or confidentially using HTTP POST. 163 o Retrieve specific resources using HTTP GET. 165 o Create new resources using HTTP POST. 167 o Replace a resource using HTTP PUT. 169 o Update a resource using HTTP PATCH. And, 171 o Delete a resource using HTTP DELETE. 173 The SCIM Protocol defines capabilities for: 175 o Complex or composite attributes that contain multiple values and 176 the need to select and update specific values. This includes how 177 to express sub-attributes and values in filters and the ability to 178 change them as part of a resource. An example of a composite 179 attribute in SCIM is: addresses (e.g. street name, city, country). 180 Note: In SECEVENTs a corresponding example complex/composite 181 attribute is an OpenID Connect user which is identified by both 182 'sub' and 'iss'. 184 o How to handle attributes that are immutable or read-only in the 185 context of operations like PUT. How to handle attributes that are 186 hashed or write-only and cannot be retrieved. 188 o Flexibility for web applications to take what they want without 189 having traditional schema enforcement as with XML Schema. 191 o How to handle identifiers between clients and service providers 192 and across domains. 194 o Referential stability of resources over time. 196 Some other relevant information: 198 o SCIM Polling Draft form Craig McMurtry [I-D.mcmurtry-scim-polling] 200 o Early SCIM Events proposal [I-D.hunt-idevent-scim] 202 3. High-Level Requirements 204 3.1. SCIM Event Trigger Requirements 206 SCIM's need for Security Events arises from a requirement for 207 triggers identified in the SCIM Use Case specification [RFC7642]. 208 Clients and service providers that operate across security domains 209 have independent resource management that causes co-ordination and 210 governance challenges between domains. The use of triggers is 211 intended to alert clients (e.g. enterprises) of state changes within 212 service providers that may be of interest to SCIM clients that may 213 need to be co-ordinated or reconciled across domains. 215 As a general example, a change to a resource that occurs within a 216 cloud software as a service (SaaS) provider generates an Event to be 217 sent to a registered recipient via an Event Stream. Upon receipt of 218 the event, the receiver performs a SCIM GET to obtain additional 219 information and then decide if a local update or other action is 220 required. 222 3.2. SCIM Security Model Considerations 224 Authentication and Authorization 225 SCIM follows normal authentication and authorization practices for 226 HTTP (See Sections 2 and 7 [RFC7644]). In typical deployed cases, 227 access to SCIM endpoints is managed by OAuth authorization in both 228 cross-domain provisioning, delegated administration, and self- 229 service applications. Many integrators also support basic 230 authentication, and TLS mutual authentication. SCIM is often 231 accessed in a couple of ways: 233 * End-user servers (e.g. as facilitated via a /Me endpoint) via a 234 self-service web application or Javascript client. 236 * Administrative - where an administrator identity has access to 237 groups of objects they are entitled to administer. 239 * Server-to-server, where identity provisioning systems 240 implementing management workflows initiate commands across 241 domains using OAuth enabled authorization. 243 PII Confidentiality 244 Querying using personally identifiable information (PII) causes 245 privacy concerns when using HTTP GET. In typical HTTP usage, 246 since HTTP [RFC7231] does not allow for query payloads on an HTTP 247 GET, query parameters and filters are typically passed as part of 248 the URL. When queries contain PII (most will in the case of 249 RISC), there are security issues (e.g. leakage via audit logs and 250 browser histories) relating to passing filter terms that contain 251 PII in URLs. See [RFC7642] Security Considerations, section 252 7.5.2. From the perspective of SECEVENTs, the SCIM community has 253 the same PII requirement that the management of SECEVENT streams 254 and delivery not pass PII in request URIs. 256 Scale, PII, and Multi-Valued Data 257 One of the concerns the SCIM working group had when developing 258 SCIM was the challenge that Groups (e.g. a group of users) will 259 tend to get very big at Internet scale. The bigger a Group gets, 260 the more expensive it is to enumerate. With a high change rate it 261 quickly become impractical to do a simple PUT to replace an entire 262 Group object due to the likely number of independent update 263 conflicts that would occur. To avoid this, implementers often: 265 * Severely restrict when clients are actually authorized to 266 return large objects (million member groups). 268 * Set access policy to allow search filters that confirm 269 membership but avoid returning the members attribute (to avoid 270 enumeration of all values). 272 * Use HTTP PATCH (a derivative of JSON Patch) to remove or add 273 specific subjects without having to know the entire contents 274 (e.g. the group). 276 3.3. Control Plane Assumptions 278 In the original SCIM identity event proposals, "Control Plane" 279 functionality was accomplished by SCIM. SCIM protocol was proposed 280 to configure and provision "streams" that deliver events via other 281 protocols or profiles. The SCIM proposal allowed Event Receivers to 282 check for delivery problems by retrieving Stream "resources" (which 283 contain the stream configuration attributes) of which "status" is an 284 attribute that could be used to report operational state of a stream. 285 Updates to Stream resource enable Event Recipients to do things like 286 rotate credentials, or suspend streams. To initiate a verification 287 to test a stream is functional, the Receiver or an authorized 288 administrator can modify the Stream resource to "request" a verify by 289 changing the value of "status" to "verify". In SCIM the subjects in 290 a stream can be identified by a number of methods: 292 o Members of a Group 294 o The addition of a "streams" attribute to Users and other objects 295 that may be part of a stream. 297 o An attribute or filter condition. E.g. the members of a Stream 298 are defined by those Users with entitlements or roles containing a 299 specific value (e.g. "entitlements" eq "CRM"). 301 The SCIM WG in re-using SCIM as the control plane had assumed the 302 following is already defined (and any alternative proposal would have 303 to support): 305 o Defined processing of attributes based on type, mutability, etc 306 for each HTTP method. For example, the handling of omitted 307 attributes in a PUT or POST operation. Is a value intended to be 308 defaulted or set to null? 310 o Handling of extensibility semantics as defined in the SCIM 311 specifications such as the definition of new resource types 312 (objects) and addition of new attributes by other profiling 313 specifications. 315 o The ability of a service provider to override or modify client 316 provider asserted values. 318 o Identifier and resource URI stability and referential integrity. 320 o Querying of subjects using various standard identifiers such as 321 "id", "emails", "telephoneNumbers", etc. The ability to express 322 composite queries such as "sub" and "iss" in a query. 324 o Ability to add and remove subjects from a group while keeping 325 enumeration of that group from the client. Ability to confirm 326 membership in a group without enumeration (facilitated through 327 support for write-only/compare-only schema or access control). 329 o Standardized error control, handling and processing rules. See 330 Section 3.12 [RFC7644] and [RFC7231]. 332 3.4. Network and Protocol Operational Considerations 334 The SCIM WG discussed that transmission (now called data-plane or 335 stream) can have much simpler semantics and error conditions and thus 336 did not need to profile JSON beyond simple SET transfer (no need for 337 attribute types, filters, etc). The SCIM WG also anticipated some 338 varied requirements for delivery that include: 340 o PUSH delivery via HTTP POST (the generally preferred ideal 341 solution). 343 o POLLING (to enable delivery across firewalls) using HTTP GET. 345 o PUSH delivery via messaging systems like APNS, GMS, SMS, etc - 346 many of these had to do with provisioning and entitlement signals 347 for mobile applications (e.g. WebEx). For example user contacts 348 synchronization where after a change to a user's contact list, an 349 application can receive an Event notification through the mobile 350 platform's messaging solution as a trigger to fetch changes. 352 3.5. Dynamic Filtering Considerations 354 When defining filtered Streams, SCIM has to consider some special 355 cases when the contents of a Stream is based upon a filter (query) to 356 define which affected resources are included. For example, if the 357 contents of a Stream is defined as Events related to resources where 358 "emails.value sw "A"" and a resource is deleted, then the deleted 359 resource won't match the filter anymore but notification may still 360 need to be sent. 362 3.6. Directory and Application Provisioning 364 Network relationships for connections are typically: 366 o Enterprise Directory to Cloud Directory. 368 o Cloud Directory to Cloud Directory. 370 o Enterprise or Cloud to Cloud Application (applications used by 371 many users). 373 o Enterprise or Cloud to Mobile Application (applications running on 374 a device controlled by a single user). 376 An enterprise directory is typically (but not always) legacy-LDAP. 377 In the cloud, a directory is simply any shared centralized profile 378 store (e.g. Google Dir, Azure Directory/OpenGraph, SCIM Directory, 379 etc). Important: While for many organizations LDAP remains the 380 center of administrative control, it is important to note that cloud 381 directories and applications hold significantly more PII than 382 enterprise directories. This creates a challenge for enterprise 383 organizations to ensure proper governance and management of data 384 given that a lot of cloud data is independently managed and updated. 386 As with an enterprise directory, a cloud directory is often shared by 387 multiple applications. Cloud directories not only contain 388 entitlement information but now also contain CRM data, contact, 389 credentials, personalization and localization data, social network 390 data, etc (the list goes on). While some cloud providers centralize 391 others are tenancy structured with different directory endpoints per 392 tenancy (e.g. Oracle). 394 As described above, because data, particularly PII, is being 395 independently managed across multiple domains, there is a need to 396 generate change signals (events) from cloud based directories and 397 applications back to the enterprise. This was originally identified 398 in the SCIM Use Cases (see Section 2.2.1 [RFC7642]). 400 4. Use Cases 402 The following use cases are expressed in terms of the direction of 403 flow of events. In typical SCIM cases, there is only 1-way event 404 exchange. Typical usage of events is to act as a "trigger" (see 405 [RFC7642]) to let a receiver know that an event has occurred in the 406 transmitter's domain that may require action on the part of the 407 receiver. Events can be simple resource changed events, to higher 408 level account status and change events (e.g. account or password 409 reset). While many events are similar to OpenID RISC proposed 410 events, a major distinction is that SCIM events are often triggered 411 by user, administrative, or workflow provisioning action rather than 412 a risk analytical engine (e.g. that might detect suspicious 413 activity). 415 4.1. Scenario 1[P0]: Cloud-to-Enterprise PUSH and Cloud-to-Cloud PUSH 417 Pre-conditions: 419 The Event Receiver already has SCIM access to the Event 420 Transmitter service provider. This includes HTTP credentials and 421 endpoint. 423 Event Receivers and Transmitters can agree out-of-band on SET/JWT 424 security requirements including use of signing and/or encryption 425 to be documented in a Stream Configuration. 427 +----------------+--------+ 428 | SCIM | SCIM | 429 |Service Provider| Events | 430 | | Stream | 431 +--------^-------+--------+ 432 SCIM| |Events via 433 Commands| |HTTP POST 434 | | 435 | | 436 | | 437 | | 438 +-+----------v-+ 439 | SCIM Client | 440 | Provisioning | 441 | Controller | 442 +--------------+ 444 Figure 1: SCIM Provisioining with PUSH Triggers 446 In Figure 1, the SCIM client initiates RESTful SCIM commands to a 447 SCIM service provider. In addition to provisioning security objects 448 such as Users and Groups, the client also uses SCIM to provision 449 Event Streams in order to receive Events to an endpoint the 450 provisioning controller requests. The service provider MUST be able 451 to POST to the client's domain. Usually this means the client is 452 able to have a public HTTP endpoint available to receive SET events. 454 Stream Creation Flow: 456 To create a Stream, the Event Receiver (or an administrator) uses 457 their SCIM access credential to access the SCIM endpoint and creates 458 a Stream resource configuration: 460 POST /Streams 461 Host: scim.bighost.com 462 Authorization: Bearer h480djs93hd8 463 { "receiverId":"", 464 "method":"webCallBack", 465 "receiverUri":"https://set.example.com/events/", 466 "aud":"", 467 "type":"SCIM", 468 "receiverJwkUri":"", 469 "authorization":"" 470 } 472 Figure 2: Stream Creation Operation 474 Note: If the Transmitter does not have an HTTP credential to send 475 events, the receiver should include one in its registration POST 476 request or negotiate one out-of-band. 478 In the stream configuration there is likely a definition as to what 479 types of events (event families) and which subjects constitute the 480 feed. In SCIM this will likely be a group of objects, or filter 481 condition such as "roles" eq "CRM_Users". This is likely based on 482 the relationship between parties that determines which entities are 483 provisioned between domains. 485 Upon successful creation of the Stream, the SCIM Event Transmitter 486 Responds with: 488 HTTP/1.1 201 Created 489 Location: https://events.bighost.com/Streams/2819c223-7f76-453a 490 { "receiverId":"", 491 "method":"webCallBack", 492 "receiverUri":"https://set.example.com/events/", 493 "aud":"", 494 "type":"SCIM", 495 "receiverJwkUri":"", 496 "authorization":"", 497 "status":"on" 498 } 500 Note that in the above figure, the Location URI is the fixed 501 reference to the Stream for as long as it exists. Administrative 502 users and Event Receiver entities MAY use the location to check 503 status or update configuration as needed. 505 Figure 3: Stream Creation Response 507 [[TBD, the event receiver, needs to issue the event transmitter a 508 credential in order for it to issue HTTP POSTs to the Event Receivers 509 callback endpoint. In some cases there may be an existing OpenID 510 Connect relationship but in most cases this not expected - especially 511 in directory-to-directory synchronization scenarios.]] 513 Stream Verification: 515 During the initial stream creation request and at any point the 516 transmitter deems appropriate (e.g. as a ping), the transmitter 517 verifies configuration by sending a verification event to the 518 receiver that demonstrates the receiver: 520 o is willing accept the event, and 521 o is able to parse the event - especially if encrypted. 523 Conversely an Event Receiver should be able to initiate a 524 verification request and may provide a confirmation challenge and 525 nonce to verify the relationship from the Event Receiver's 526 perspective. 528 Delivery: 530 Delivery is accomplished by doing a simple HTTP POST to the 531 registered endpoint of the receiver. The payload of the POST is 532 application/jwt and contains a single JWT (which is actually a SET). 534 Before responding with a 2xx success message, the receiver should 535 ensure it was able to read and validate the SET. If the transmitter 536 receives a 2xx response, the transmitter may assume the event was 537 successfully delivered. 539 A set of Status 400 error conditions are defined which the receiver 540 can use to indicate various JWT validation conditions. 542 4.2. Scenario 2[P0]: Cloud-to-Enterprise POLLING 544 Pre-conditions: 546 The Event Receiver already has SCIM access to the Event 547 Transmitter service provider. This includes HTTP credentials and 548 endpoint. 550 Event Receivers and Transmitters can agree out-of-band on SET/JWT 551 security requirements including use of signing and/or encryption 552 to be documented in a Stream Configuration. 554 The Event Receiver is unable to open an endpoint to receive SETs 555 inside the firewall. 557 +----------------+--------+ 558 | SCIM | SCIM | 559 |Service Provider| Events | 560 | | | 561 +--------^-------+--^-----+ 562 SCIM| |Events via 563 Commands| |HTTP GET Long Poll 564 | |& POST Acks 565 Firewall | | 566 +---------------------------------------+ 567 | | 568 +-+----------+-+ 569 | SCIM Client | 570 | Provisioning | 571 | Controller | 572 +--------------+ 574 Figure 4: Event Delivery with Firewall 576 In Figure 4, the SCIM client initiates RESTful SCIM commands to a 577 SCIM service provider. In addition to provisioning security objects 578 such as Users and Groups, the client also uses SCIM to provision 579 Event Streams in order to receive Events to an endpoint the 580 provisioning controller requests. In this case, the SCIM Client 581 "polls" for events using HTTP GET. The client MAY request immediate 582 response based on a timed schedule, or the client MAY use HTTP Long 583 Polling to wait for SETs as they become available. 585 Stream Creation Flow: 587 The Event Receiver uses their SCIM credential to access the SCIM 588 service provider endpoint to create a Stream resource by performing a 589 POST 591 POST /Streams 592 Host: scim.bighost.com 593 Authorization: Bearer h480djs93hd8 594 { "receiverId":"", 595 "method":"POLLING", 596 "aud":"", 597 "type":"SCIM", 598 "receiverJwkUri":"" 599 } 601 Figure 5: Create Polling Stream 603 It is assumed, but may not always be true. that the POLLING receiver 604 can simply use their SCIM credential to perform HTTP GETs to the 605 polling endpoint. Additional parameters will likely need to be 606 defined to control polling rate, number of events in a message, etc. 608 Note, in the stream configuration there is likely a definition as to 609 what types of events (event families) and which subjects constitute 610 the feed. In SCIM this will likely be a group of objects, or filter 611 condition such as "roles" eq "CRM_Users". This is likely based on 612 the relationship between parties that determines which entities are 613 provisioned between domains. 615 Upon successful creation of the stream, the transmitter responds to 616 the receiver with: 618 HTTP/1.1 201 Created 619 Location: https://events.bighost.com/Streams/2819c223-7f76-453a 620 { "receiverId":"", 621 "method":"POLLING", 622 "receiverUri":"https://set.bighost.com/Events/2819c223-7f76-453a", 623 "aud":"", 624 "type":"SCIM", 625 "receiverJwkUri":"", 626 "status":"on" 627 } 629 Figure 6: Polling Stream Creation Response 631 In the above response, the transmitter indicates to the receiver 632 where to poll for events by setting a value for "receiverUri". This 633 endpoint does not need to be SCIM compliant and can be a generic 634 (e.g. shared by all polliers) endpoint such as 635 "https://events.bighost.com". 637 Stream Verification: 639 Same requirements are for Scenario 1 (see Section 4.1). 641 Delivery: 643 Delivery is accomplished by having the Event Receiver initiate an 644 HTTP request that causes a response such as: 646 { 647 "sets":{ 648 "4d3559ec67504aaba65d40b0363faad8": 649 "eyJhbGciOiJub25lIn0 650 . 651 e3sgIAogICJqdGkiOiAiNGQzNTU5ZWM2NzUwNGFhYmE2NWQ0MGIwMzYzZmFhZDgiLAog 652 ICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUu 653 Y29tIiwgIAogICJhdWQiOiBbCiAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVl 654 ZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsCiAgICJodHRwczovL3NjaW0uZXhh 655 bXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIKICBdLCAgCiAg 656 CiAgImV2ZW50cyI6IHsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVh 657 dGUiOiB7CiAgICAgICJyZWYiOgogICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5j 658 b20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsCiAgICAgICJhdHRyaWJ1 659 dGVzIjpbImlkIiwgIm5hbWUiLCAidXNlck5hbWUiLCAicGFzc3dvcmQiLCAiZW1haWxz 660 Il0KICAgIH0KICB9Cn0", 661 "":"" 662 }, 663 "since":1458496025 664 } 666 Figure 7: Example Polling Response 668 In the above JSON object is a JSON attribute "sets" whose value is a 669 JSON object that contains a set of JSON attributes that correspond to 670 each event's JTI value. the value for each attribute is the actual 671 encoded SET. 673 In addition to the "sets" attribute, a "since" attribute indicates 674 the timestamp of either the last event previously transmitted or 675 potentially oldest event in the current payload (To be discussed). 677 In order to acknowledge receipt, the receiver must successfully parse 678 each message and respond by doing an HTTP POST back to the events 679 endpoint using something along the lines of the following JSON 680 structure: 682 { 683 "ack":[ 684 "39e48e70e9f84d90b5fdbf2fbd826219", 685 "8e1ed13b871547ffa332f7027a0fdd91", 686 "0a02c62529e34541a8b3c5c7941fa545" 687 ] 688 "setErrs":{ 689 "3d0c3cf797584bd193bd0fb1bd4e7d30":{ 690 "err":"dup", 691 "description":"SET already received. Ignored." 692 } 693 } 694 } 696 Figure 8: Poll Acknowledgement Response 698 In the payload above the receiver indicates which SET event JTIs have 699 been accepted, and which SETs had errors using "accepts" and 700 "setErrs". 702 It is expected that because most errors are due to JWT crypto 703 configuration errors, that most responses will tend to be all errors 704 or all accepts. 706 If a transmitter receives what it deems an unrecoverable error, or a 707 receiver fails to poll for events, the transmitter can set the stream 708 state to "failed" with an appropriate error indicator. 710 4.3. Scenario 3[P2]: Cloud-to-Mobile Application PUSH 712 This scenario is a hybrid of scenario 1 and 2. The scenario uses 713 mobile message delivery services (APNS, GMS, SMS) to deliver events. 714 Typically a stream has only one subject in its feed. The events are 715 used to notify client applications about changes to entitlements, or 716 other configuration (e.g. new tenancy endpoints)that might be useful 717 to user experience. 719 As in the polling method in Scenario 2, to acknowledge events, the 720 mobile app will need to use the POST (as defined in Scenario 2) to 721 acknowledge SET delivery. To be discussed, this might not be 722 necessary if assured delivery is not required. 724 5. Security Considerations 726 None as this is a use case document to describe considerations. 728 6. Privacy Considerations 730 None as this is a use case document to describe considerations. 732 7. IANA Considerations 734 There are no IANA considerations. 736 8. References 738 8.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, 742 DOI 10.17487/RFC2119, March 1997, 743 . 745 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 746 Resource Identifier (URI): Generic Syntax", STD 66, 747 RFC 3986, DOI 10.17487/RFC3986, January 2005, 748 . 750 8.2. Informative References 752 [I-D.hunt-idevent-scim] 753 Hunt, P., Denniss, W., and M. Ansari, "SCIM Event 754 Extension", draft-hunt-idevent-scim-00 (work in progress), 755 March 2016. 757 [I-D.ietf-secevent-token] 758 Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security 759 Event Token (SET)", draft-ietf-secevent-token-00 (work in 760 progress), January 2017. 762 [I-D.mcmurtry-scim-polling] 763 McMurtry, C., "SCIM Polling Protocol", draft-mcmurtry- 764 scim-polling-01 (work in progress), April 2016. 766 [idevent-scim] 767 Oracle Corporation, "SCIM Event Extensions (work in 768 progress)". 770 [openid-connect-core] 771 NRI, "OpenID Connect Core 1.0", Nov 2014. 773 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 774 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 775 . 777 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 778 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 779 2014, . 781 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 782 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 783 DOI 10.17487/RFC7231, June 2014, 784 . 786 [RFC761] USC, "TRANSMISSION CONTROL PROTOCOL", January 1980. 788 [RFC7642] LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z. 789 Zeltsan, "System for Cross-domain Identity Management: 790 Definitions, Overview, Concepts, and Requirements", 791 RFC 7642, DOI 10.17487/RFC7642, September 2015, 792 . 794 [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. 795 Mortimore, "System for Cross-domain Identity Management: 796 Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 797 2015, . 799 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 800 and C. Mortimore, "System for Cross-domain Identity 801 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 802 September 2015, . 804 [saml-core-2.0] 805 Internet2, "Assertions and Protocols for the OASIS 806 Security Assertion Markup Language (SAML) V2.0", March 807 2005. 809 Appendix A. Acknowledgments 811 The editors would like to thanks the members of the SCIM WG which 812 began discussions of provisioning events starting with: draft-hunt- 813 scim-notify-00 in 2015. 815 The editor would like to thank the participants in the the SECEVENTS 816 working group for their support of this specification. 818 Appendix B. Change Log 820 Draft 00 - PH - Initial draft 822 Authors' Addresses 824 Phil Hunt (editor) 825 Oracle Corporation 827 Email: phil.hunt@yahoo.com 829 Morteza Ansari 830 Cisco 832 Email: moransar@cisco.com