idnits 2.17.1 draft-hunt-scim-events-01.txt: -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(200): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(213): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(250): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(252): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(253): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(256): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(259): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(260): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(263): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(264): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(265): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(267): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(273): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(355): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(356): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(357): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(361): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(365): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(370): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(373): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 70 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes draft-hunt-idevent-scim-00, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfcdraft-hunt-idevent-scim-00 - is the name correct? -- The document date (3 March 2022) is 778 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7520 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSWG' -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SCIM P. Hunt, Ed. 3 Internet-Draft IndependentId Inc 4 Obsoletes: draft-hunt-idevent-scim-00 (if 3 March 2022 5 approved) 6 Intended status: Standards Track 7 Expires: 4 September 2022 9 SCIM Profile for Security Event Tokens 10 draft-hunt-scim-events-01 12 Abstract 14 This specification profiles the Security Event Token specification, 15 to define a set of events for SCIM Protocol servers that can be used 16 for asynchronous transaction confirmations, replication, cross-domain 17 provisioning co-ordination, and security signals. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 4 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Processing Modes for Events . . . . . . . . . . . . . . . . . 4 57 2.1. Domain Based Replication . . . . . . . . . . . . . . . . 5 58 2.2. Co-ordinated Provisioning . . . . . . . . . . . . . . . . 5 59 2.3. Risk Signals . . . . . . . . . . . . . . . . . . . . . . 7 60 2.4. Async Requests . . . . . . . . . . . . . . . . . . . . . 8 61 3. SCIM Events . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. Common Event Attributes . . . . . . . . . . . . . . . . . 9 63 3.2. SCIM Feed Events . . . . . . . . . . . . . . . . . . . . 10 64 3.2.1. urn:ietf:params:event:SCIM:feed:add . . . . . . . . . 10 65 3.2.2. urn:ietf:params:event:SCIM:feed:remove . . . . . . . 11 66 3.3. SCIM Provisioning Events . . . . . . . . . . . . . . . . 11 67 3.3.1. urn:ietf:params:event:SCIM:prov:create . . . . . . . 12 68 3.3.2. urn:ietf:params:event:SCIM:prov:patch . . . . . . . . 13 69 3.3.3. urn:ietf:params:event:SCIM:prov:put . . . . . . . . . 15 70 3.3.4. urn:ietf:params:event:SCIM:prov:delete . . . . . . . 17 71 3.3.5. urn:ietf:params:event:SCIM:prov:activate . . . . . . 18 72 3.3.6. urn:ietf:params:event:SCIM:prov:deactivate . . . . . 18 73 3.4. SCIM Signals Events . . . . . . . . . . . . . . . . . . . 18 74 3.4.1. urn:ietf:params:event:SCIM:sig:authMethod . . . . . . 18 75 3.4.2. urn:ietf:params:event:SCIM:sig:pwdReset . . . . . . . 19 76 3.5. Miscellaneous Events . . . . . . . . . . . . . . . . . . 19 77 3.5.1. urn:ietf:params:event:SCIM:misc:asyncResp . . . . . . 20 78 4. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 20 79 4.1. Security Event Token Signing and Encryption . . . . . . . 20 80 4.2. Point-to-Point Delivery Over HTTP . . . . . . . . . . . . 21 81 4.3. Using Message Bus Delivery . . . . . . . . . . . . . . . 22 82 5. Event Handling . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 23 84 5.2. Optimizing Events . . . . . . . . . . . . . . . . . . . . 23 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 9.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 27 92 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction and Overview 97 This specification profiles Security Event Tokens (SET) [RFC8417] to 98 define Security Events and mechanisms for delivery with SCIM Protocol 99 [RFC7644] systems that can be used for asynchronous transaction 100 confirmations, replication, cross-domain provisioning co-ordination, 101 and security signals. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 1.2. Notational Conventions 113 For purposes of readability examples are not URL encoded. 114 Implementers MUST percent encode URLs as described in Section 2.1 of 115 [RFC3986]. 117 Throughout this documents all figures MAY contain spaces and extra 118 line-wrapping for readability and space limitations. Similarly, some 119 URI's contained within examples, have been shortened for space and 120 readability reasons. 122 1.3. Definitions 124 This specification uses definitions from the following 125 specifications: 127 * Security Event Tokens [RFC8417], and 129 * System for Cross-Domain Identity Management Protocol [RFC7644]. 131 Additionally, the following terms are defined: 133 Attributes and Claims 134 The JWT specification [RFC7519] upon which SET is based uses the 135 term "claims" to refer to attributes in a JSON token. SCIM in 136 contrast uses the term "attributes" to refer to JSON attributes. 137 For the purposes of this draft, the terms "attributes" and 138 "claims" are equivalent. 140 CP 141 Abbreviation for "Co-ordinated Provisioning" as defined in 142 Section 2.2. 144 DBR 145 Abbreviation for "Domain Based Replication" as defined in 146 Section 2.1. 148 Event Feed 149 This describes the notion that a feed MAY be individualized per 150 client. A service provider MAY offer to allow Event Receiver's to 151 "subscribe" to specific event types or events about specific 152 resources. If no option is offered, it is assumed the client will 153 receive all events about all resources. 155 Event Receiver 156 A system that receives events for the purpose of subsequent action 157 (e.g. such as replication), co-ordination of workflow, or 158 signalling. 160 Event Publisher 161 A system that issues SETs based on a change that has occurred at a 162 SCIM Service Provider. For example, events MAY originate from a 163 SCIM Create, Modify, or Delete per [RFC7644] request. A SCIM 164 Service Provider MAY be an Event Publisher or an independent 165 service that aggregates events into Event Receiver feeds. 167 Message Bus 168 Any communications protocol or system that enables a message (e.g. 169 a SET) to be sent to one or more receivers at the same time. 170 Typically participants connect to a "bus" rather than in point-to- 171 point transfer such as SET HTTP Push [RFC8935]. The "bus" takes 172 care of fault-tolerance, routing, and delivery to recipients. 174 RS 175 Abbreviation for "Risk Signals" as defined in Section 2.3. 177 SCIM Service Provider 178 An HTTP server that implements SCIM Protocol [RFC7644] and SCIM 179 Schema [RFC7643]. 181 SET 182 Abbreviation for "Security Event Token" as defined in [RFC8417] 184 2. Processing Modes for Events 186 This specification defines 4 processing modes for SCIM Security 187 Events that have different objectives, data requirements, and 188 considerations for using Security Event Tokens. 190 2.1. Domain Based Replication 192 The objective of DBR is to synchronize resource changes between SCIM 193 replicas in a common administrative domain. In this mode, 194 information about changes for resources are shared between replicas 195 for immediate processing. The intention is that every replica node 196 contains the same information content in a timely fashion. 198 ┌────────────────┐ 199 ┌────────┐ │SCIM │ ┌────────────────────────┐ 200 │Client A│ │Service Provider│ │Service Provider Replica│ 201 └───┬────┘ └───────┬────────┘ └───────────┬────────────┘ 202 │ "SCIM Operation" ┌┴┐ │ 203 │ ────────────────────>│ │ │ 204 │ │ │ │ 205 │ "SCIM Response" │ │ ┌┴┐ 206 │ <────────────────────│ │ │ │ 207 │ └┬┘ │ │ 208 │ │ "Event SCIM:prov:│ │ 209 │ │ id:xyz" │ │ 210 │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─>│ │ 211 │ │ │ │ 212 │ │ │ │ 213 │ │ │ │────┐ 214 "Update local node"│ │ │ 215 │ │<───┘ 216 └┬┘ 218 Figure 1: Domain Based Replication Sequence 220 In this mode, replication is a server-to-server process and it is 221 assumed that access rights between servers is identical. Access to 222 these messages MUST be limited to communication between replicating 223 nodes with appropriate authorization. From a Privacy Perspective, it 224 is assumed that all replicas of the server are in the same 225 administrative domain and that the sharing of information is 226 primarily for performance and availability reasons and the sharing 227 information between replicas does not by itself enable access to new 228 parties (e.g. where a user may not have consented). 230 2.2. Co-ordinated Provisioning 232 In "Co-ordinated Provisioning" (CP), SCIM resource change events are 233 shared between domains with the restriction that the actual attribute 234 value data is omitted. In any Event Publisher and Receiver 235 relationship, the set of SCIM resources that are co-ordinated is 236 managed within the context of a "Feed" and MAY be a subset of the 237 total set of resources on either side. To support this, "feed" 238 events are defined that indicate the addition and removal of SCIM 239 resources from a feed. For example, when a user consents to the 240 sharing of information between domains, events about the User MAY be 241 added to the feed between the Event Publisher and Receiver. 243 ┌────────────────┐ ┌──────────────┐ ┌─────────────┐ 244 ┌───────────┐ │SCIM │ │Client A │ │Co-op Action │ 245 │SCIM Client│ │Service Provider│ │Co-op Receiver│ │Endpoint │ 246 └─────┬─────┘ └───────┬────────┘ └──────┬───────┘ └───────┬─────┘ 247 │ "SCIM Ope" ┌┴┐ │ │ 248 │──────────────>│ │ │ │ 249 │ │ │ │ │ 250 │ "SCIM Resp" │ │ ┌┴┐ │ 251 │<──────────────│ │ │ │ │ 252 │ │ │ │ │ │ 253 │ │ │ │ │ │ 254 │ ╔═══════╤╪═╪════════════════╪═╪═════════════════╪════╗ 255 │ ║ LOOP ││ │ │ │ │ ║ 256 │ ╟───────┘└┬┘ Event: │ │ │ ║ 257 │ ║ │ SCIM:prov:│ │ │ ║ 258 │ ║ │ id:xyz │ │ │ ║ 259 │ ║ │ ─ ─ ─ ─ ─ ─ ─ >│ │ │ ║ 260 │ ║ │ │ │ │ ║ 261 │ ║ │ ╔════════════╧═╧══════════════╗ │ ║ 262 │ ║ │ ║Receiver may accumulate ║ │ ║ 263 │ ║ │ ║events for periodic action. ║ │ ║ 264 │ ║ │ ╚════════════╤═╤══════════════╝ │ ║ 265 │ ║ │ SCIM GET │ │ │ ║ 266 │ ║ │ <───────────────│ │ │ ║ 267 │ ║ │ │ │ │ ║ 268 │ ║ │ Filtered │ │ │ ║ 269 │ ║ │ Resource Resp │ │ │ ║ 270 │ ║ │ ───────────────>│ │ │ ║ 271 │ ║ │ │ │ │ ║ 272 │ ║ │ │ │ "Co-ord Action" │ ║ 273 │ ║ │ │ │ ───────────────>│ ║ 274 │ ╚═════════╪═════════════════╪═╪═════════════════╪════╝ 276 Figure 2: Co-Ordinated Provisioning Sequence 278 In CP mode, the receiver of an event must call back to the 279 originating SCIM Service Provider (e.g. using a SCIM GET request) to 280 reconcile the newly changed resource in order to obtain the changes. 282 Co-ordinated provisioning has the following benefits: 284 * Differences in schema (e.g. attributes) between domains. For 285 example, a receiving domain may only be interested or only be 286 allowed access to a few attributes (e.g. role based access data) 287 to enable access to an application. 289 * Different Event Receivers MAY have differing needs access to 290 information and thus be assigned varying access rights. Minimal 291 information events combined with call-backs for data allows data 292 filtering to be applied. 294 * Receivers can take independent action. For example deciding which 295 attributes or resource lifecycle changes to accept. For example, 296 in the case of a conflict, a receiver can prioritize one domain 297 source over another. 299 * A receiver MAY throttle or buffer changes rather than act 300 immediately on a notification. For example, for a frequently 301 changing resource, the receiver MAY choose to make scheduled SCIM 302 GET for resources that have been marked "dirty" by events received 303 in the last scheduled cycle. 305 A disadvantage of the CP approach is that it may be considered costly 306 in the sense that each event received might trigger a call back to 307 the event issuer. This cost should be weighed against the cost 308 producing filtered information in each event for each receiver. 309 Further a receiver is not required to make a call-back on every 310 provisioning event. 312 It is assumed that an underlying relationship between domains exists 313 that permits the exchange of personal information and credentials. 314 For example the decision to perform SCIM provisioning operations at 315 the SCIM Service Provider issuing change events, was previously 316 authorized and appropriate confidentiality and privacy agreements 317 have been met in cross-domain scenarios. Examples of this might be 318 services for hire by an employer or a specific consent from an end- 319 user as part of a online authorization where individual consent was 320 obtained. 322 2.3. Risk Signals 324 The sharing of risk signals (RS) is intended for the purpose of co- 325 ordinating change events between a SCIM Service Provider and another 326 related security service. For example, when a password or other 327 authentication factor has changed, a receiving security system can 328 choose to terminate current User sessions to force a re- 329 authentication against the modified User resource. 331 These signals MAY also include those described in the OpenID Shared 332 Signals Working Group Specifications [SSWG]. 334 These events are intended for receivers where there is a prior 335 relationship on behalf of the users described in the SCIM Service 336 Provider. The intent of sharing information about security events is 337 for the purpose of securing a user account and ensuring privacy. 339 2.4. Async Requests 341 A SCIM provisioning client MAY wish to request "asynchronous" 342 processing using the "Prefer Header for HTTP", Section 4.1 [RFC7240]. 343 In this mode, a normal SCIM protocol POST, PUT, PATCH, or DELETE 344 request is made, and the HTTP Header Prefer is included with the 345 value respond-async. When a SCIM Client signals respond-async, the 346 SCIM server response changes to HTTP Status 202 Accepted as defined 347 in [RFC7231]. The Location header returned is the final resource 348 location and no payload is present. Following acceptance of an 349 asynchronous request, a notification of completion can be issued 350 using the Async Event Notification per Section 3.5.1. The location 351 returned SHALL correspond to the sub claim in the future Async Event 352 SET message. 354 { 355 ┌──────────────┐ ┌────────────────┐ 356 ┌────────┐ │Client A │ │SCIM │ 357 │Client A│ │Event Receiver│ │Service Provider│ 358 └───┬────┘ └──────┬───────┘ └───────┬────────┘ 359 │ "SCIM Modify ┌┴┐ 360 │ w/Respond Async" │ │ 361 │ ──────────────────────────────────────────────────>│ │ 362 │ │ │ │ 363 │ "Accepted Status 202" │ │ 364 │ "Location: /Users/xyz" │ │ 365 │ <──────────────────────────────────────────────────│ │ 366 │ │ │ └┬┘ 367 │ │ │ "Event SCIM:misc:asyncResp │ 368 │ │ │ sub: /Users/xyz │ 369 │ │ │ id:xyz, method: PUT" │ 370 │ │ │ <─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│ 371 │ └┬┘ │ 372 │ "ID: xyz created" │ │ 373 │ <─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ 375 Figure 3: Asychronous Request Sequence 377 3. SCIM Events 379 A SCIM event is a message, in the form of a Security Event Token 380 [RFC8417], that conveys information about changes that have occurred 381 at a SCIM Service Provider that may be of interest to a receiving 382 system. Examples of events include: 384 * Resource lifecycle events including creation, activation, 385 deactivation, and removal of a resource. 387 * Risk signal events (e.g. password reset, authentication factor 388 change) which may be used by a receiver to take a security 389 response such as resetting or revoking current user sessions and 390 tokens. 392 * A Password update event is used to securely distribute a hashed 393 value in an administrative domain. 395 * A Async Event is used to acknowledge completion status of an 396 Asynchronous SCIM Request. 398 3.1. Common Event Attributes 400 The following attributes are available for all events defined. The 401 values are contained within the event payload per Section 2 402 [RFC8417]. 404 id 405 A SCIM id attribute identifying the SCIM Service Provider's 406 resource that was modified. This value is required. 408 externalId 409 If known, the externalId value of the SCIM Resource that MAY be 410 used by a receiver to identify the corresponding resource in the 411 Event Receiver's domain. 413 txn 414 For the purposes of SCIM, this SET claim should be used to 415 identify unique transactions originating at a SCIM Service 416 Provider. The purpose is to detect duplicate transactions that 417 may have been received. If not provided, the SET jti claim MAY be 418 used. The difference is that txn identifies uniqueness within a 419 SCIM Service Provider whereas JTI only identifies a unique JWT 420 token. 422 data 423 Defined in SCIM Bulk Operations, Section 3.7 [RFC7644], contains 424 the information necessary to propagate the transaction to the 425 receiving node. For example, after processing a SCIM Create 426 operation, the data contained includes the final representation of 427 the created entity by the SCIM Service Provider including the 428 assigned id value. 430 attributes 431 An array of attributes that were added, revised, or removed. For 432 example: 433 "attributes": ["username","emails"] 435 Depending on the Processing Mode or Event definition, usually only 436 one of data or attributes is provided. 438 The sub claim SHALL hold the SCIM Service Provider's Resource URI 439 value of the affected object. Note: that the SCIM Bulk path 440 attribute is SHALL NOT be used as this duplicates the sub claim. 442 This specifications defines a new schema URI prefix 443 urn:ietf:params:event:SCIM which is used as the prefix for the 444 following defined SCIM Events. 446 3.2. SCIM Feed Events 448 This section defines events related to notices about which resources 449 are being added or removed from an event feed. These events are used 450 in Co-operative Provisioning scenarios where only a sub-set of 451 entities are shared across an Event Feed. The URI prefix for these 452 events is: urn:ietf:params:event:SCIM:feed 454 3.2.1. urn:ietf:params:event:SCIM:feed:add 456 The specified resource was added to the Event Feed. A feed:add does 457 not indicate a resource is new or has been recently created. For 458 example, an existing user has had a new role (e.g. CRM_User) added 459 to their profile which has caused their resource to join a feed. 461 { 462 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 463 "sub": "/Users/2b2f880af6674ac284bae9381673d462", 464 "txn": "b7b953f11cc6489bbfb87834747cc4c1", 465 "events":{ 466 "urn:ietf:params:event:SCIM:feed:add": { 467 "id":"2b2f880af6674ac284bae9381673d462" 468 } 469 }, 470 "iat": 1458505044, 471 "iss":"https://scim.example.com", 472 "aud":[ 473 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 474 ] 475 } 477 Figure 4: Example SCIM Feed Add Event 479 3.2.2. urn:ietf:params:event:SCIM:feed:remove 481 The specified resource has been removed from the feed. Removal does 482 not indicate that the resource was deleted or otherwise deactivated. 483 This event has minimal disclosure. 485 { 486 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 487 "sub": "/Users/2b2f880af6674ac284bae9381673d462", 488 "events":{ 489 "urn:ietf:params:event:SCIM:feed:remove": { 490 "id": "2b2f880af6674ac284bae9381673d462" 491 } 492 }, 493 "iat": 1458505044, 494 "iss":"https://scim.example.com", 495 "aud":[ 496 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 497 ] 498 } 500 Figure 5: Example SCIM Feed Remove Event 502 3.3. SCIM Provisioning Events 504 This section defines provisioning events that have occurred within a 505 SCIM Service Provider. These events are used in both Domain Based 506 Replication (DBR) and Co-operative Provisioning (CP) mode. The URI 507 prefix for these events is: urn:ietf:params:event:SCIM:prov 509 3.3.1. urn:ietf:params:event:SCIM:prov:create 511 Indicates a new SCIM resource has been created by the SCIM Service 512 Provider and has been added to the Event Feed. Note that when a 513 create event is sent, a corresponding 514 urn:ietf:params:event:SCIM:feed:add event SHOULD NOT be issued in the 515 same feed. In DBR mode mode, all claims of the new resource are 516 included. In CP mode, the attributes returned discloses what 517 attributes were created at the publisher. In DBR mode, the set of 518 values reflecting the final state of the resource at the service 519 provider are provided using the "data" attribute. Note that because 520 this is a replication request, the id attribute that was assigned by 521 the SCIM Service Provider is shared so that all replicas in the 522 domain use the same resource identifier. 524 { 525 "jti": "4d3559ec67504aaba65d40b0363faad8", 527 "iat": 1458496404, 528 "iss":"https://scim.example.com", 529 "aud":[ 530 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 531 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 532 ], 533 "sub": "/Users/44f6142df96bd6ab61e7521d9", 534 "events":{ 535 "urn:ietf:params:event:SCIM:prov:create":{ 536 "id":"44f6142df96bd6ab61e7521d9", 537 "externalId":"jdoe", 538 "data":{ 539 "schemas":[ "urn:ietf:params:scim:schemas:core:2.0:User"], 540 "emails":[ 541 {"type":"work","value":"jdoe@example.com"} 542 ], 543 "userName":"jdoe", 544 "name":{ 545 "givenName":"John", 546 "familyName":"Doe" 547 } 548 } 549 } 550 } 551 } 553 Figure 6: Example SCIM Create (Domain Replication Mode) 555 { 556 "jti": "4d3559ec67504aaba65d40b0363faad8", 557 "iat": 1458496404, 558 "iss":"https://scim.example.com", 559 "aud":[ 560 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 561 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 562 ], 563 "sub": "/Users/44f6142df96bd6ab61e7521d9", 564 "events": { 565 "urn:ietf:params:event:SCIM:prov:create": { 566 "id": "44f6142df96bd6ab61e7521d9", 567 "externalId": "jdoe", 568 "attributes": [ 569 "id", 570 "name", 571 "userName", 572 "password", 573 "emails" 574 ] 575 } 576 } 577 } 579 Figure 7: Example SCIM Create Event (CP Mode) 581 The event above notifies the Event Receiver which attributes have 582 changed but does not convey the actual information. The Event 583 Receiver MAY retrieve that information by performing a SCIM GET to 584 the sub value specified. 586 3.3.2. urn:ietf:params:event:SCIM:prov:patch 588 The specified resource has been updated using SCIM PATCH. When in 589 DBR mode, the data attribute contains the PATCH Request body. In CP 590 mode, only the modified attribute name is included. 592 { 593 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 594 "sub": "/Groups/acbf3ae7-8463-...-9b4da3f908ce", 595 "events":{ 596 "urn:ietf:params:event:SCIM:prov:patch": { 597 "id": "acbf3ae7-8463-...-9b4da3f908ce", 598 "externalId":"crmUsers", 599 "version": "a330bc54f0671c9", 600 "data": { 601 "schemas": 602 ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], 603 "Operations":[{ 604 "op":"add", 605 "path":"members", 606 "value":[{ 607 "display": "Babs Jensen", 608 "$ref": "/Users/2819c223...413861904646", 609 "value": "2819c223-7f76-453a-919d-413861904646" 610 }] 611 }] 612 } 613 } 614 }, 615 "iat": 1458505044, 616 "iss":"https://scim.example.com", 617 "aud":[ 618 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 619 ] 620 } 622 Figure 8: Example SCIM Patch Event (DBR Mode) 624 { 625 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 626 "sub": "/Groups/acbf3ae7-8463-...-9b4da3f908ce", 627 "events":{ 628 "urn:ietf:params:event:SCIM:prov:patch": { 629 "id": "acbf3ae7-8463-...-9b4da3f908ce", 630 "externalId":"crmUsers", 631 "attributes": ["members"], 632 "version": "a330bc54f0671c9" 633 } 634 }, 635 "iat": 1458505044, 636 "iss":"https://scim.example.com", 637 "aud":[ 638 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 639 ] 640 } 642 Figure 9: Example SCIM Patch Event (CP Mode) 644 3.3.3. urn:ietf:params:event:SCIM:prov:put 646 The specified resource has been updated (e.g. one or more attributes 647 has changed). In DBR mode, the SCIM PUT request body is included in 648 the data attribute; or, In CP mode the modified attributes are listed 649 using attributes. 651 { 652 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 653 "sub": "/Users/2819c223-7f76-453a-919d-413861904646", 654 "events":{ 655 "urn:ietf:params:event:SCIM:prov:patch": { 656 "id": "2819c223-7f76-453a-919d-413861904646", 657 "version": "a330bc54f0671c9", 658 "data": { 659 "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"], 660 "id":"2819c223-7f76-453a-919d-413861904646", 661 "userName":"jdoe", 662 "externalId":"jdoe", 663 "name":{ 664 "formatted":"Mr. Jon Jack Doe III", 665 "familyName":"Doe", 666 "givenName":"Jon", 667 "middleName":"Jack" 668 }, 669 "roles":[], 670 "emails":[ 671 {"value":"jdoe@example.com"}, 672 {"value":"anon@jdoe.org"} 673 ] 674 } 675 } 676 }, 677 "iat": 1458505044, 678 "iss":"https://scim.example.com", 679 "aud":[ 680 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 681 ] 682 } 684 Figure 10: Example SCIM Put Event (DBR Mode) 686 { 687 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 688 "sub": "/Users/2819c223-7f76-453a-919d-413861904646", 689 "events":{ 690 "urn:ietf:params:event:SCIM:prov:patch": { 691 "id": "2819c223-7f76-453a-919d-413861904646", 692 "version": "a330bc54f0671c9", 693 "attributes": ["userName","externalId","name","roles","emails"] 694 } 695 }, 696 "iat": 1458505044, 697 "iss":"https://scim.example.com", 698 "aud":[ 699 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 700 ] 701 } 703 Figure 11: Example SCIM Put Event (CP Mode) 705 3.3.4. urn:ietf:params:event:SCIM:prov:delete 707 The specified resource has been deleted from the SCIM publisher. The 708 resource is also removed from the feed. When a DELETE is sent, a 709 corresponding feedRemove is not issued. A delete event has minimal 710 disclosure profile only. 712 { 713 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 714 "sub": "/Users/2b2f880af6674ac284bae9381673d462", 715 "events":{ 716 "urn:ietf:params:event:SCIM:prov:delete": { 717 "id": "2b2f880af6674ac284bae9381673d462", 718 "externalId": "jDoe" 719 } 720 }, 721 "iat": 1458505044, 722 "iss":"https://scim.example.com", 723 "aud":[ 724 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 725 ] 726 } 728 Figure 12: Example SCIM Delete Event 730 3.3.5. urn:ietf:params:event:SCIM:prov:activate 732 The specified resource (e.g. User) has been activated. This event 733 indicates a high-level change in state as agreed between the Event 734 Publisher and Event Receiver. For example, an activated resource is 735 one that can now have an active session (may log in) from a security 736 perspective. 738 { 739 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 740 "sub": "/Users/2b2f880af6674ac284bae9381673d462", 741 "events":{ 742 "urn:ietf:params:event:SCIM:prov:activate": { 743 "id": "2b2f880af6674ac284bae9381673d462" 744 } 745 }, 746 "iat": 1458505044, 747 "iss":"https://scim.example.com", 748 "aud":[ 749 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 750 ] 751 } 753 Figure 13: Example SCIM Activate Event 755 3.3.6. urn:ietf:params:event:SCIM:prov:deactivate 757 The specified resource (e.g. User) has been deactivated and 758 disabled. The exact meaning must be agreed to by the Event Publisher 759 and its corresponding Event Receiver. Typically this means the sub 760 may no longer have an active security session. As with the activate 761 event, this event has minimal disclosure requirements. 763 3.4. SCIM Signals Events 765 This section defines security signal events that have occured within 766 a SCIM Service Provider.The URI prefix for these events is: 767 urn:ietf:params:event:SCIM:signal 769 3.4.1. urn:ietf:params:event:SCIM:sig:authMethod 771 A new authentication method has been added to the User profile. As 772 attackers often use new authentication methods to lock-out Users from 773 their account, this signal can be used by the receiver that the 774 chance of account them may be temporarily elevated. The receiver MAY 775 also wish to take action such as resetting current authorizations or 776 sessions. 778 { 779 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 780 "sub": "/Users/44f6142df96bd6ab61e7521d9", 781 "events":{ 782 "urn:ietf:params:event:SCIM:sig:authMethod": { 783 "id": "44f6142df96bd6ab61e7521d9" 784 } 785 }, 786 "iat": 1458496025, 787 "iss": "https://scim.example.com" 788 } 790 Figure 14: Example SCIM Authentication Factor Change Event 792 3.4.2. urn:ietf:params:event:SCIM:sig:pwdReset 794 The specified resource (e.g. User) has changed its password or the 795 password has been reset. When the password has changed, the 796 attributes attribute is supplied with the value "password". 798 { 799 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 800 "sub": "/Users/44f6142df96bd6ab61e7521d9", 801 "events": { 802 "urn:ietf:params:event:SCIM:sig:pwdReset": { 803 "id": "44f6142df96bd6ab61e7521d9" 804 } 805 }, 806 "iat": 1458496025, 807 "iss": "https://scim.example.com", 808 "aud":[ 809 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", 810 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" 811 ] 812 } 814 Figure 15: Example SCIM Password Change Event 816 3.5. Miscellaneous Events 818 This section defines events related miscellaneous events such as 819 Asynchronous Request complettion that have occured within a SCIM 820 Service Provider. The URI prefix for these events is: 821 urn:ietf:params:event:SCIM:misc 823 3.5.1. urn:ietf:params:event:SCIM:misc:asyncResp 825 This event signals the completion of a SCIM request. The payload 826 contains the attributes defined in SCIM Bulk Section 3.7 [RFC7644] 827 and is the same a single SCIM Bulk Response Operation as per 828 Section 3.7.3. 830 { 831 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8", 832 "sub": "/Users/b7c14771-226c-4d05-8860-134711653041", 833 "txn": "7880fc68a2f0428ebbb5a906e5aeae53", 834 "events":{ 835 "urn:ietf:params:event:SCIM:misc:asyncResp": { 836 "id":"b7c14771-226c-4d05-8860-134711653041", 837 "method": "PUT", 838 "version": "W\/\"huJj29dMNgu3WXPD\"", 839 "status": "200" 840 } 841 }, 842 "iat": 1458505044, 843 "iss":"https://scim.example.com", 844 "aud":[ 845 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" 846 ] 847 } 849 Figure 16: Example SCIM Async Response Event 851 4. Event Delivery 853 As Security Event Tokens are based on JWT tokens, it is possible to 854 exchange events by a number of transfer mechanisms such as: XMPP 855 [RFC6120], HTTP [RFC7540], and Message Buses (e.g. [RFC3259], Apache 856 Kafka [Kafka]). This draft discusses 2 general delivery methods: 857 Message Bus and Point-to-Point. 859 4.1. Security Event Token Signing and Encryption 861 This specification uses Security Event Tokens as the message format 862 for SCIM Events. As SETs are based on JWT tokens [RFC7519], they can 863 be transmitted unsecurity, signed, or encrypted. For more 864 information see the JWT Cookbook specification [RFC7520] for 865 examples. The decision on whether to use JWS and JWE depends on 866 operational considerations. For each SCIM Feed relationship, it is 867 up to deployers to decide on signing, encryption and algorithm 868 requirements. Deployers SHOULD be aware that too much emphasis on 869 turning on every possible encryption feature may cause operational 870 performance to suffer. Deployers MUST weigh the security trade-offs 871 of up-to-date SCIM services, vs. the potential information loss of an 872 event. 874 Unsecured 875 Per Section 6 [RFC7519], tokens MAY be generated with 876 {"alg":"none"}. This mode speeds up processing and is best used 877 in DBR scenarios. Unencrypted tokens MUST be transferred over 878 authenticated TLS layer encryption and SHOULD only be used in a 879 restricted network environment. 881 Signed 882 JWS ([RFC7515]) signed SETs are useful when it is important to be 883 able to verify the issuer of a SET as valid. In addition, some 884 systems MAY wish to validate the authenticity of the event in a 885 review process which may occur at a later date. While the content 886 can be validated as originating from the correct issuer and is 887 unmodified, the message contents remain unsecure. Signed SETs 888 MUST be transferred over encrypted transport. 890 Encrypted 891 JWE ([RFC7516]) are encrypted SETs and are useful when the 892 transport mechanism is not fully securable (e.g. messages carried 893 by a third party). The use of JWEs ensures only the designated 894 receiver can read the event and provides mutual authentication 895 within the SET mesage itself. 897 4.2. Point-to-Point Delivery Over HTTP 899 Security Event Tokens MAY be delivered using push-based HTTP delivery 900 [RFC8935], or pull-based HTTP Polling [RFC8936]. Both of these 901 protocols define a method of transfer and acknowledgement to prevent 902 loss-of-information and to provide re-transmission and recover. The 903 method of transfer is best decided by considering the following 904 advantages and disadvantages in a production scenario: 906 Push-based delivery has the following advantages: 908 * Message transfer is instant (when compared to using a common Event 909 Publisher acting as a relay), and in high event frequency 910 scenarios, HTTP connections can be kept open. 912 * Scales well when an SCIM Event Publisher has thousands of event 913 receivers and TCP resources may be limited. 915 * Does not require events to be routed to a single publisher node. 916 SCIM Events may be issued by SCIM Service Provider nodes where the 917 transaction occurred. 919 * SCIM Events only need to be retained until they have been 920 delivered to designated receivers. 922 Push-delivery has the following disadvantages: 924 * A SCIM Event Publisher system needs authorization credentials 925 enabling it to access the HTTP SCIM Event delivery endpoint. 927 * When synchronizing business data that is behind protected 928 firewalls, a virtual network or other firewall policy may be 929 required to allow external network based SCIM providers to deliver 930 SCIM Events to internally hosted systems. 932 Delivery by HTTP Polling has the following advantages: 934 * It is possible for a SCIM Event Receiver to use the same SCIM 935 credentials it uses when access the normal SCIM Service Provider 936 service defined by [RFC7644]. 938 * Systems behind protected network boundaries can reach externally 939 hosted systems without requiring special firewall or network 940 configuration. 942 * Instantaneous transfer can be used using HTTP Long-polling as 943 described Section 2.1 of [RFC8936]. 945 Polling-based delivery has the following disadvantages: 947 * Long-polling requires the use of persistent connections for which 948 TCP resources may be limited. HTTP Long-polling is best used in 949 scenarios when there are relatively few Event Receivers. 951 * The SCIM Event Publisher MUST retain events for the Event Receiver 952 until delivered. 954 4.3. Using Message Bus Delivery 956 Security Event Tokens MAY be delivered using a message bus. While 957 this draft will not talk about any particular message bus, it will 958 discuss the pros and cons for message buses in general and any 959 anticipated issues and requirements. 961 Message buses have the following advantages: 963 * Connection management and credentials may be greatly simplified as 964 participants only need to authenticate to the "bus" to issue and 965 receive events. 967 * Message buses can have "broadcast" features that are able to 968 deliver the same event to many recipients such as in a global 969 deployment of replicated SCIM servers. Issuers save resources by 970 only having to publish once to a bus rather than to each receiver 971 directly. 973 * Depending on the implementation, a Message Bus can be used as a 974 buffer and in some cases for data recovery. For example, some 975 buses may have infinite retention of events. 977 * Message-buses can support bi-directional and other more complex 978 flow relationships (e.g. sharding). 980 Message buses may have following disadvantages: 982 * A message bus may have some delivery delays (seconds to minutes) 983 when compared to point-to-point systems. 985 * Message buses may require significant infrastructure commitments 986 in order to meet delivery reliability. However it may also be 987 true that a point-to-point system may also impose significant 988 resource requirements requiring a SCIM service provider to assume 989 the same work. 991 * Multi-issuer scenarios may require more conflict resolution 992 processing. E.g. such as prioritizing specific nodes as "masters" 993 for specific SCIM attributes. 995 5. Event Handling 997 5.1. Conflict Resolution 999 In scenarios where there may be multiple issuers of SCIM Events, it 1000 becomes possible that conflicts can arise when the same version of a 1001 resource is modified by multiple parties. 1003 Editors note: TO BE COMPLETED 1005 5.2. Optimizing Events 1007 In cases where resources change frequently, SCIM Service Providers 1008 MAY choose to release events on an interval basis in order to reduce 1009 traffic. For example, a large Group with millions of members may 1010 have hundreds of changes per minute. For optimization, a SCIM 1011 Service Provider MAY choose to issue a cumulative event once per 1012 minute instead of for each change event. 1014 Editors note: TO BE COMPLETED 1016 6. Security Considerations 1018 [[TO BE COMPLETED]] 1020 7. Privacy Considerations 1022 [[TO BE COMPLETED]] 1024 8. IANA Considerations 1026 This section registers the schema extensions found in Section 3 in 1027 the "Event" registry as per Section 4.2 [RFC8417]. 1029 Schema URI: SeeSection 3. 1031 Schema Name: See corresponding names underSection 3. 1033 Intented ResourceType: N/A. Events are not intended to be persisted 1034 in SCIM. 1036 Purpose: See each description inSection 3. 1038 Single-valued Attributes: None. 1040 Multi-valued Attributes: All schemas in this specification share the 1041 same attributes. SeeSection 3.1. 1043 Summary of schema URI registrations: 1045 +==========================================+==============+=========+ 1046 |Schema URI |Name |Reference| 1047 +==========================================+==============+=========+ 1048 |urn:ietf:params:event:SCIM:feed:add |Resource added|Section | 1049 | |to Feed Event |3.2.1 | 1050 +------------------------------------------+--------------+---------+ 1051 |urn:ietf:params:event:SCIM:feed:remove |Remove resouce|Section | 1052 | |From Feed |3.2.2 | 1053 | |Event | | 1054 +------------------------------------------+--------------+---------+ 1055 |urn:ietf:params:event:SCIM:prov:create |New Resource |Section | 1056 | |Event |3.3.1 | 1057 +------------------------------------------+--------------+---------+ 1058 |urn:ietf:params:event:SCIM:prov:patch |Resource Patch|Section | 1059 | |Event |3.3.2 | 1060 +------------------------------------------+--------------+---------+ 1061 |urn:ietf:params:event:SCIM:prov:put |Resource Put |Section | 1062 | |Event |3.3.3 | 1063 +------------------------------------------+--------------+---------+ 1064 |urn:ietf:params:event:SCIM:prov:delete |Resource |Section | 1065 | |Deleted Event |3.3.4 | 1066 +------------------------------------------+--------------+---------+ 1067 |urn:ietf:params:event:SCIM:prov:activate |Resource |Section | 1068 | |Activated |3.3.5 | 1069 | |Event | | 1070 +------------------------------------------+--------------+---------+ 1071 |urn:ietf:params:event:SCIM:prov:deactivate|Resource |Section | 1072 | |Deactivated |3.3.6 | 1073 | |Event | | 1074 +------------------------------------------+--------------+---------+ 1075 |urn:ietf:params:event:SCIM:sig:authMethod |New |Section | 1076 | |authentication|3.4.1 | 1077 | |method added | | 1078 +------------------------------------------+--------------+---------+ 1079 |urn:ietf:params:event:SCIM:sig:pwdReset |Password Reset|Section | 1080 | |Event |3.4.2 | 1081 +------------------------------------------+--------------+---------+ 1083 Table 1 1085 9. References 1087 9.1. Normative References 1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", BCP 14, RFC 2119, 1091 DOI 10.17487/RFC2119, March 1997, 1092 . 1094 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1095 Resource Identifier (URI): Generic Syntax", STD 66, 1096 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1097 . 1099 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1100 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1101 DOI 10.17487/RFC7231, June 2014, 1102 . 1104 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 1105 DOI 10.17487/RFC7240, June 2014, 1106 . 1108 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1109 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1110 2015, . 1112 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1113 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1114 . 1116 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1117 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1118 . 1120 [RFC7520] Miller, M., "Examples of Protecting Content Using JSON 1121 Object Signing and Encryption (JOSE)", RFC 7520, 1122 DOI 10.17487/RFC7520, May 2015, 1123 . 1125 [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. 1126 Mortimore, "System for Cross-domain Identity Management: 1127 Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 1128 2015, . 1130 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 1131 and C. Mortimore, "System for Cross-domain Identity 1132 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 1133 September 2015, . 1135 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1136 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1137 May 2017, . 1139 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 1140 "Security Event Token (SET)", RFC 8417, 1141 DOI 10.17487/RFC8417, July 2018, 1142 . 1144 [SSWG] Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, 1145 A., and J. Bradley, "OpenID Shared Signals and Events 1146 Framework Specification 1.0 - draft 01", 8 June 2021. 1148 Cappalli, T. and A. Tulshibagwale, "OpenID Continuous 1149 Access Evaluation Profile 1.0 - draft 02", 8 June 2021. 1151 9.2. Informative References 1153 [Kafka] Apache Software Foundation, "Apache Kafka", 2017. 1155 [RFC3259] Ott, J., Perkins, C., and D. Kutscher, "A Message Bus for 1156 Local Coordination", RFC 3259, DOI 10.17487/RFC3259, April 1157 2002, . 1159 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1160 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1161 March 2011, . 1163 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1164 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1165 DOI 10.17487/RFC7540, May 2015, 1166 . 1168 [RFC8935] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, 1169 M., and A. Nadalin, "Push-Based Security Event Token (SET) 1170 Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, 1171 November 2020, . 1173 [RFC8936] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, 1174 M., and A. Nadalin, "Poll-Based Security Event Token (SET) 1175 Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936, 1176 November 2020, . 1178 Appendix A. Acknowledgments 1180 Thanks to Morteza Ansari who contributed significantly to draft-hunt- 1181 idevent-scim-00, upon which this draft is based. 1183 The editor would like to thank the participants in the the SCIM 1184 working group and the id-event list for their support of this 1185 specification. 1187 Appendix B. Change Log 1189 Draft 00 - PH - First Draft 1191 Author's Address 1193 Phil Hunt (editor) 1194 Independent Identity Inc 1195 Email: phil.hunt@independentid.com