rfc9967.original   rfc9967.txt 
SCIM P. Hunt, Ed. Internet Engineering Task Force (IETF) P. Hunt, Ed.
Internet-Draft Independent Id Request for Comments: 0000 Independent Id
Updates: 7643, 7644 (if approved) N. Cam-Winget Updates: 7643, 7644 N. Cam-Winget
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: 6 May 2026 M. Kiser ISSN: 2070-1721 M. Kiser
Sailpoint Sailpoint
J. Schreiber J. Schreiber
Workday Workday
2 November 2025 May 2026
SCIM Profile for Security Event Tokens System for Cross-Domain Identity Management (SCIM) Profile for Security
draft-ietf-scim-events-16 Event Tokens (SETs)
Abstract Abstract
This specification defines a set of System for Cross-domain Identity This specification defines a set of System for Cross-domain Identity
Management (SCIM) Security Events using the Security Event Token Management (SCIM) Security Events using the Security Event Token
Specification to enable the asynchronous exchange of messages between (SET) specification (RFC 8417) to enable the asynchronous exchange of
SCIM Service Providers and receivers. messages between SCIM Service Providers and receivers.
This draft updates RFC7643 defining additional attributes for This specification updates RFC 7643 by defining additional attributes
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"
and updates RFC7644 with optional new Asynchronous SCIM Request schema, and it updates RFC 7644 with an optional new Asynchronous
capability. SCIM Request capability.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 May 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc0000.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.2. Notational Conventions
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Definitions
2. SCIM Events . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. SCIM Events
2.1. Identifying the Subject of an Event . . . . . . . . . . . 6 2.1. Identifying the Subject of an Event
2.2. Common Event Attributes . . . . . . . . . . . . . . . . . 7 2.2. Common Event Attributes
2.3. SCIM Feed Events . . . . . . . . . . . . . . . . . . . . 8 2.3. SCIM Feed Events
2.3.1. urn:ietf:params:scim:event:feed:add . . . . . . . . . 8 2.3.1. urn:ietf:params:scim:event:feed:add
2.3.2. urn:ietf:params:scim:event:feed:remove . . . . . . . 9 2.3.2. urn:ietf:params:scim:event:feed:remove
2.4. SCIM Provisioning Events . . . . . . . . . . . . . . . . 10 2.4. SCIM Provisioning Events
2.4.1. 2.4.1. urn:ietf:params:scim:event:prov:create:{notice|full}
urn:ietf:params:scim:event:prov:create:{notice|full} 10 2.4.2. urn:ietf:params:scim:event:prov:patch:{notice|full}
2.4.2. 2.4.3. urn:ietf:params:scim:event:prov:put:{notice|full}
urn:ietf:params:scim:event:prov:patch:{notice|full} . 12 2.4.4. urn:ietf:params:scim:event:prov:delete
2.4.3. urn:ietf:params:scim:event:prov:put:{notice|full} . . 14 2.4.5. urn:ietf:params:scim:event:prov:activate
2.4.4. urn:ietf:params:scim:event:prov:delete . . . . . . . 16 2.4.6. urn:ietf:params:scim:event:prov:deactivate
2.4.5. urn:ietf:params:scim:event:prov:activate . . . . . . 17 2.5. Miscellaneous Events
2.4.6. urn:ietf:params:scim:event:prov:deactivate . . . . . 17 2.5.1. Asynchronous Events
2.5. Miscellaneous Events . . . . . . . . . . . . . . . . . . 17 3. Set-Txn HTTP Response Header for Asynchronous Requests
2.5.1. Asynchronous Events . . . . . . . . . . . . . . . . . 17 4. Events Discovery Schema for Service Provider Configuration
3. Set-Txn HTTP Response Header for Asynchronous Requests . . . 25 5. Security Considerations
4. Events Discovery Schema for Service Provider Configuration . 25 6. Privacy Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 7.1. SCIM Asynchronous Set-Txn Header Registration
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.2. Registering Event Capability with SCIM Service Provider
7.1. SCIM Asynchronous Txn Header Registration . . . . . . . . 28 Configuration
7.2. Registering Event Capability with Scim Service Provider 7.3. Creation of the SCIM Event URIs Registry
Config . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4. Initial Contents of the SCIM Event URIs Registry
7.3. Registration of the SCIM Event URIs Registry . . . . . . 29 8. References
7.4. Initial Events Registry . . . . . . . . . . . . . . . . . 30 8.1. Normative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Use Cases
8.2. Informative References . . . . . . . . . . . . . . . . . 33 A.1. Domain-Based Replication
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 33 A.2. Co-ordinated Provisioning
A.1. Domain Based Replication . . . . . . . . . . . . . . . . 34 Acknowledgements
A.2. Co-ordinated Provisioning . . . . . . . . . . . . . . . . 35 Authors' Addresses
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction and Overview 1. Introduction and Overview
This specification defines Security Events for SCIM Service Providers This specification defines Security Events for SCIM Service Providers
and receivers as specified by the Security Event Tokens (SET) and receivers as specified by Security Event Tokens (SETs) [RFC8417].
[RFC8417]. SCIM Security Events in this specification include: In this specification, SCIM Security Events include asynchronous
asynchronous request completion, resource replication, and request completion, resource replication, and provisioning co-
provisioning co-ordination. ordination.
This specification defines the use of the HTTP Header "Prefer: This specification defines the use of the HTTP header "Prefer:
respond-async" [RFC7240] to allow a SCIM Protocol Client [RFC7644] to respond-async" [RFC7240] to allow a SCIM Protocol Client [RFC7644] to
request an asynchronous response (see Section 2.5.1.1). request an asynchronous response (see Section 2.5.1.1).
Using HTTP protocol, a SCIM Protocol Client issues commands to a SCIM Using the HTTP protocol, a SCIM Protocol Client issues commands to a
Service Provider using HTTP methods such as POST, PATCH, and DELETE SCIM Service Provider using HTTP methods such as POST, PATCH, and
[RFC7644] that cause a state change to a SCIM Resource. When DELETE [RFC7644] that cause a state change to a SCIM Resource. When
multiple independent SCIM Clients update SCIM Resources, individual multiple independent SCIM Clients update SCIM Resources, individual
clients become out of date as state changes occur. Some clients may clients become out of date as state changes occur. Some clients may
need to be informed of these changes for co-ordination or need to be informed of these changes for co-ordination or
reconciliation purposes. This could be done using periodic SCIM GET reconciliation purposes. This could be done using periodic SCIM GET
requests over time, but this rapidly becomes problematic as the requests over time, but this rapidly becomes problematic as the
number of changes and the number of resources increases. number of changes and the number of resources increases.
SCIM Events can be shared over an established Event Feed enabling SCIM Events can be shared over an established Event Feed enabling
receivers to monitor and trigger independent asynchronous action. receivers to monitor and trigger independent asynchronous action.
This approach enables greater scale and timeliness, where only This approach enables greater scale and timeliness, where only
skipping to change at page 3, line 47 skipping to change at line 134
SCIM Service Provider. That SET may be of interest to one or more SCIM Service Provider. That SET may be of interest to one or more
receivers. But instead of interpreting SETs as commands, each Event receivers. But instead of interpreting SETs as commands, each Event
Receiver is able to determine the best local follow-up action to take Receiver is able to determine the best local follow-up action to take
within its own context. For example, a receiver can reconcile schema within its own context. For example, a receiver can reconcile schema
and resource type differences between domains. and resource type differences between domains.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Notational Conventions 1.2. Notational Conventions
Throughout this document all figures may contain spaces and extra Throughout this document, all figures may contain spaces and extra
line-wrapping for readability and space limitations. Similarly, some line wrapping for readability and space limitations. Similarly, some
URIs contained within examples, have been shortened for space and URIs contained within examples have been shortened for space and
readability reasons. readability reasons.
1.3. Definitions 1.3. Definitions
This specification uses definitions from the following This specification uses definitions from the following
specifications: specifications:
* JSON Web Tokens (JWT) [RFC7519], * "JSON Web Token (JWT)" [RFC7519],
* Security Event Tokens (SET) [RFC8417], and * "Security Event Token (SET)" [RFC8417], and
* System for Cross-Domain Identity Management Protocol [RFC7644]. * "System for Cross-domain Identity Management: Protocol" [RFC7644].
In JSON Web Tokens and Security Event Tokens, the term "claim" refers In JSON Web Tokens (JWTs) and Security Event Tokens, the term "claim"
to JSON attribute values contained in a JSON Web Token [RFC7519] refers to JSON attribute values contained in a JWT [RFC7519]
structure. The term "claim" in tokens is used to indicate that an structure. The term "claim" in tokens is used to indicate that an
attribute value may not be verified and its accuracy can be attribute value may not be verified and its accuracy can be
questioned. In the context of SCIM, this distinction is not made. questioned. In the context of SCIM, this distinction is not made.
For this specification the terms "claims" and "attributes" are inter- For this specification, the terms "claims" and "attributes" are
changeable. For consistency, JWT and SET IANA registered attributes interchangeable. For consistency, JWT and SET attributes registered
will continue to be called claims, while event information attributes by IANA will continue to be called "claims", while event information
(i.e., those in an event payload) will be referred to as attributes. attributes (i.e., those in an event payload) will be referred to as
"attributes".
Additionally, the following terms are defined: Additionally, the following terms are defined:
Attributes and Claims Attributes and Claims:
The JWT specification [RFC7519] upon which SET is based uses the The JWT specification [RFC7519], upon which SET is based, uses the
term "claims" to refer to attributes in a JSON token. SCIM in term "claims" to refer to attributes in a JSON token. In
contrast uses the term "attributes" to refer to JSON attributes. contrast, SCIM uses the term "attributes" to refer to JSON
For the purposes of this draft, the terms "attributes" and attributes. For the purposes of this document, the terms
"claims" are equivalent. "attributes" and "claims" are equivalent.
Co-ordinated Provisioning (CP) Co-ordinated Provisioning (CP):
Defined in Appendix A.2, in co-ordinated provisioning As defined in Appendix A.2, in CP relationships, an Event
relationships, an Event Publisher and Receiver typically exchange Publisher and Receiver typically exchange resource change events
resource change events without exchanging data (see Section 2.4). without exchanging data (see Section 2.4). For a receiver to know
For a receiver to know the value of the data, the Event Receiver the value of the data, the Event Receiver usually calls back to
usually calls back to the SCIM Event Publisher domain to receive a the SCIM Event Publisher domain to receive a new copy of data
new copy of data (e.g., Uses a SCIM GET request). (e.g., uses a SCIM GET request).
Domain Based Replication (DBR) Domain-Based Replication (DBR):
Defined in Appendix A.1, in this domain-based replication mode As defined in Appendix A.1, in the DBR mode, there is an
there is an administrative relationship spanning multiple administrative relationship spanning multiple operational domains;
operational domains, data shared in Events typically uses the data shared in Events typically uses the "full" mode variation of
"full" mode variation of change events (see Section 2.4) including change events (see Section 2.4) including the "data" payload
the "data" payload attribute. This eliminates the need for a attribute. This eliminates the need for a callback to retrieve
callback to retrieve additional data. additional data.
Event Feed / Event Stream Event Feed / Event Stream:
An Event Feed (equivalently Event Stream) is a logical series of An Event Feed (or equivalently an Event Stream) is a logical
events shared with a unique receiving client. A SET transfer (see series of events shared with a unique receiving client. A SET
[RFC8935] and [RFC8936]) Service Provider may offer to allow Event transfer (see [RFC8935] and [RFC8936]) Service Provider may offer
Receivers to "subscribe" to specific event types or events about to allow Event Receivers to "subscribe" to specific event types or
specific resources (see Feed Management events in Section 2.3). events about specific resources (see Feed Management events in
Section 2.3).
Event Receiver Event Receiver:
An entity receives events typically via [RFC8935], [RFC8936], or An entity typically receives events as described in [RFC8935] and
HTTP GET (see Section 2.5.1.1). In the case of SET Push Transfer [RFC8936] or via HTTP GET (see Section 2.5.1.1). In the case of
[RFC8935], the Event Receiver is an HTTP Service Endpoint that SET Push Transfer [RFC8935], the Event Receiver is an HTTP Service
receives requests. In the case of SET Poll-Based Transfer Endpoint that receives requests. In the case of SET Poll-based
[RFC8936], the receiver is an HTTP client that initiates HTTP Transfer [RFC8936], the receiver is an HTTP client that initiates
request to an Event Publisher endpoint. an HTTP request to an Event Publisher endpoint.
Event Publisher Event Publisher:
A system that issues SETs based on a resource state change that A system that issues SETs based on a resource state change that
has occurred at a SCIM Service Provider. For example, events may has occurred at a SCIM Service Provider. For example, events may
be the result of a SCIM Create, Modify, or Delete as defined in be the result of a SCIM Create, Modify, or Delete operation as
Section 3 of [RFC7644]. A SCIM Service Provider may be an Event defined in Section 3 of [RFC7644]. A SCIM Service Provider may be
Publisher or an independent service that aggregates events into an Event Publisher or an independent service that aggregates
Event Receiver feeds. As described above, when using [RFC8935], events into Event Receiver feeds. As described above, when using
the Event Publisher is an HTTP Client that initiates HTTP POST [RFC8935], the Event Publisher is an HTTP client that initiates
requests to a defined Event Receiver endpoint. When using HTTP POST requests to a defined Event Receiver endpoint. When
[RFC8936], the Event Publisher provides an HTTP endpoint which a using [RFC8936], the Event Publisher provides an HTTP endpoint,
receiver may use to "poll" for Security Events. which a receiver may use to "poll" for Security Events.
SCIM Client SCIM Client:
Refers to an HTTP client that initiates SCIM Protocol [RFC7644] An HTTP client that initiates SCIM protocol [RFC7644] requests and
requests and receives responses which may cause SCIM Events to be receives responses that may cause SCIM Events to be issued by the
issued by the SCIM Service Provider. A SCIM Client may also be an SCIM Service Provider. A SCIM Client may also be an Event
Event Receiver, typically when making an asynchronous SCIM request Receiver, typically when making an asynchronous SCIM request (see
(see Section 2.5.1.1). Section 2.5.1.1).
SCIM Service Provider SCIM Service Provider:
An HTTP server that implements SCIM Protocol [RFC7644] and SCIM An HTTP server that implements the SCIM protocol [RFC7644] and
Schema [RFC7643]. Upon processing a state change to a SCIM SCIM schema [RFC7643]. Upon processing a state change to a SCIM
Resource, issues a SCIM Event or causes an Event Publisher to Resource, it issues a SCIM Event or causes an Event Publisher to
issue a SCIM Event. issue a SCIM Event.
SET Security Event Token (SET):
Abbreviation for "Security Event Token" as defined in [RFC8417] As defined in [RFC8417].
2. SCIM Events 2. SCIM Events
A SCIM event is a signal, in the form of a Security Event Token A SCIM Event is a signal, in the form of a Security Event Token
[RFC8417], that describes some event that has occurred. A SET event [RFC8417], that describes some event that has occurred. A SET event
consists of a set of standard JWT "top-level" claims and an "events" consists of a set of standard JWT "top-level" claims and an "events"
claim that contains one or more event URI subclaims (JSON attributes) claim that contains one or more event URI subclaims (JSON attributes)
each with a JSON object containing relevant event information. each with a JSON object containing relevant event information.
This specification defines a new URI prefix This specification defines the new URI prefix
"urn:ietf:params:scim:event" which is used as the prefix for the "urn:ietf:params:scim:event", which is used as the prefix for the
following defined SCIM Events (see Section 7.3). Events are grouped defined SCIM Events (see Section 7.3). Events are grouped into one
into one of two sub-namespaces: "feed" (feed control notices) or of two sub-namespaces: "feed" (feed control notices) or "prov"
"prov" (provisioning). (provisioning).
2.1. Identifying the Subject of an Event 2.1. Identifying the Subject of an Event
SCIM Events MUST use the "sub_id" claim, defined by [RFC9493], to SCIM Events MUST use the "sub_id" claim, defined by [RFC9493], to
identify the subject of events. The "sub_id" claim MUST be contained identify the subject of events. The "sub_id" claim MUST be contained
within the main JWT claims body and MUST NOT be located within an within the main JWT claims body and MUST NOT be located within an
event payload within the "events" claim. A SET with multiple event event payload within the "events" claim. A SET with multiple event
URIs indicates that the events arise from the same transaction or URIs indicates that the events arise from the same transaction or
resource state change for a single resource or subject. resource state change for a single resource or subject.
skipping to change at page 6, line 46 skipping to change at line 277
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "alice@example.com" "externalId": "alice@example.com"
}, },
"events": { "events": {
... ...
} }
} }
Figure 1: SCIM Subject Id Example Figure 1: Example SCIM Subject Id
Instead of "sub", the top-level claim "sub_id" SHALL be used. Instead of "sub", the top-level claim "sub_id" SHALL be used.
"sub_id" contains the subclaim attribute "format" set to "scim" to "sub_id" contains the subclaim attribute "format" set to "scim" to
indicate the attributes present in the "sub_id" object are SCIM indicate that the attributes present in the "sub_id" object are SCIM
attributes. The following "sub_id" attributes are defined: attributes. The following "sub_id" attributes are defined:
uri uri
The SCIM relative path for the resource which usually consists of The SCIM relative path for the resource that usually consists of
the resource type endpoint plus the resource "id" (see Section 3.2 the resource type endpoint plus the resource "id" (see Section 3.2
of [RFC7644]). For example of [RFC7644]), for example,
"/Users/2b2f880af6674ac284bae9381673d462". This attribute MUST be "/Users/2b2f880af6674ac284bae9381673d462". This attribute MUST be
provided in a SCIM Event "sub_id" claim. Note the relative path provided in a SCIM Event "sub_id" claim. Note that the relative
is the path component after the SCIM Service Provider Base URI as path is the path component after the SCIM Service Provider Base
defined in Section 1.3 of [RFC7644]. In cases where the Event URI as defined in Section 1.3 of [RFC7644]. In cases where the
Receiver is unable to match a URI, the Event Receiver MAY issue a Event Receiver is unable to match a URI, the Event Receiver MAY
callback to a previously agreed SCIM Service Provider Base URI issue a callback to a previously agreed SCIM Service Provider Base
plus the relative "uri" value and perform a SCIM GET request per URI plus the relative "uri" value and perform a SCIM GET request
Section 3.4.1 of [RFC7644]. per Section 3.4.1 of [RFC7644].
externalId externalId
If known, the "externalId" value (defined in Section 3.1 of If known, the "externalId" value (defined in Section 3.1 of
[RFC7643]) of the SCIM Resource that MAY be used by a receiver to [RFC7643]) of the SCIM Resource that MAY be used by a receiver to
identify the corresponding resource in the Event Receiver's identify the corresponding resource in the Event Receiver's
domain. domain.
id id
The SCIM Id attribute (defined in Section 3.1 of [RFC7643]) MAY be The SCIM Id attribute (defined in Section 3.1 of [RFC7643]) MAY be
used for backwards compatibility reasons in addition to the "uri" used for backwards compatibility reasons in addition to the "uri"
claim. claim.
In cases where SCIM identifiers ("id" and "externalId") are not In cases where SCIM identifiers ("id" and "externalId") are not
enough to identify a common resource between an Event Publisher and enough to identify a common resource between an Event Publisher and
Event Receiver, the "sub_id" object MAY contain attributes whose SCIM Event Receiver, the "sub_id" object MAY contain attributes whose SCIM
attribute types have "uniqueness" set to "server" or "global" as per attribute types have "uniqueness" set to "server" or "global" as per
Section 7 of [RFC7643]. For example, attributes such as "emails" or Section 7 of [RFC7643]. For example, attributes such as "emails" or
"username" (defined in Section 4 of [RFC7643]) are unique with in a "username" (defined in Section 4 of [RFC7643]) are unique within a
SCIM Service Provider. Such attributes should allow an Event SCIM Service Provider. Such attributes should allow an Event
Publisher and Event Receiver to identify a commonly understood Publisher and Event Receiver to identify a commonly understood
subject resource of an event. subject resource of an event.
2.2. Common Event Attributes 2.2. Common Event Attributes
The following attributes are available for all events defined. Some The following attributes are available for all events defined. Some
attributes are defined as SET/JWT claims, while others are "Event attributes are defined as SET/JWT claims, while others are "Event
Payload" claims as defined in Section 1.2 of [RFC8417]. Only one of Payload" claims as defined in Section 1.2 of [RFC8417]. Only one of
"data" or "attributes" claims MUST be provided depending on the event the claims, "data" or "attributes", MUST be provided depending on the
definition. event definition.
txn txn
"txn" is a SET-defined claim with a STRING value (see Section 2.2 A SET-defined claim with a STRING value (see Section 2.2 of
of [RFC8417]) that uniquely identifies a transaction originating [RFC8417]) that uniquely identifies a transaction originating at a
at a SCIM Service Provider and/or its underlying data repository SCIM Service Provider and/or its underlying data repository or
or database where one or more SCIM Events may be subsequently database where one or more SCIM Events may be subsequently issued.
issued. In contrast to a "jti" claim (see Section 4.1.7 of In contrast to a "jti" claim (see Section 4.1.7 of [RFC7519]),
which uniquely identifies a token, the "txn" remains the same when
[RFC7519]), which uniquely identifies a token, the "txn" remains one or more SETs are generated for various purposes such as
the same when one or more SETs are generated for various purposes retransmission, publication to multiple receivers, etc. A
such as re-transmission, publication to multiple receivers etc. A
distinct state change or transaction within a SCIM Service distinct state change or transaction within a SCIM Service
Provider MAY result in multiple SETs issued each with distinct Provider MAY result in multiple SETs issued each with distinct
"jit" values an a common "txn" value. "txn" is REQUIRED to support "jit" values and a common "txn" value. "txn" is REQUIRED to
asynchronous SCIM requests, co-ordinated provisioning, and support asynchronous SCIM requests, CP, and replication to
replication to disambiguate or detect duplicate SETs regarding the disambiguate or detect duplicate SETs regarding the same
same underlying transaction. underlying transaction.
version version
The Etag version of the resource as a result of the event and The ETag version of the resource as a result of the event.
corresponds to the Etag response header described in Section 3.14 Corresponds to the ETag response header described in Section 3.14
of [RFC7644]. of [RFC7644].
data data
This event payload attribute contains information described in the An event payload attribute that contains information described in
SCIM Bulk Operations "data" attribute in Section 3.7 of [RFC7644]. the SCIM Bulk Operations "data" attribute in Section 3.7 of
The JSON object contains the equivalent SCIM command processed by [RFC7644]. The JSON object contains the equivalent SCIM command
the SCIM Service Provider. For example, after processing a SCIM processed by the SCIM Service Provider. For example, after
Create operation, the data contained includes the final processing a SCIM Create operation, the data contained includes
representation of the created entity by the SCIM Service Provider the final representation of the entity created by the SCIM Service
including the assigned "id" value. Provider including the assigned "id" value.
attributes attributes
This payload contains an array of attributes that were added, A payload that contains an array of attributes that were added,
revised, or removed. Names of modified attributes SHOULD conform revised, or removed. Names of modified attributes SHOULD conform
to the ABNF syntax rule for "path"> (Section 3.5.2 of [RFC7644]). to the ABNF syntax rule for "path" (Section 3.5.2 of [RFC7644]).
For example: For example: "attributes":
"attributes": ["username","emails","name.familyName"] ["username","emails","name.familyName"].
2.3. SCIM Feed Events 2.3. SCIM Feed Events
This section defines events related to changes in the content of an This section defines events related to changes in the content of an
event feed. Such as, SCIM Resources that are being added or removed event feed such as SCIM Resources that are being added or removed
from an event feed or events used in Co-operative Provisioning from an event feed or events used in Co-operative Provisioning
scenarios where only a sub-set of entities are shared across an Event scenarios where only a subset of entities are shared across an Event
Feed. The URI prefix for these events is Feed. The URI prefix for these events is
"urn:ietf:params:scim:event:feed" "urn:ietf:params:scim:event:feed".
2.3.1. urn:ietf:params:scim:event:feed:add 2.3.1. urn:ietf:params:scim:event:feed:add
The specified resource has been added to the Event Feed. A The specified resource has been added to the Event Feed. A
"feed:add" does not indicate a resource is new or has been recently "feed:add" does not indicate that a resource is new or has been
created. For example, an existing user has had a new role (e.g., recently created. For example, an existing user has had a new role
CRM_User) added to their profile which has caused their resource to (e.g., CRM_User) added to their profile, which has caused their
join a feed. resource to join a feed.
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"txn": "b7b953f11cc6489bbfb87834747cc4c1", "txn": "b7b953f11cc6489bbfb87834747cc4c1",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe" "externalId": "jdoe"
}, },
"events":{ "events":{
skipping to change at page 10, line 8 skipping to change at line 427
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 3: Example SCIM Feed Remove Event Figure 3: Example SCIM Feed Remove Event
2.4. SCIM Provisioning Events 2.4. SCIM Provisioning Events
This section defines resource changes that have occurred within a This section defines resource changes that have occurred within a
SCIM Service Provider. These events are used in both Domain Based SCIM Service Provider. These events are used in both Domain-Based
Replication (DBR) and Co-operative Provisioning (CP) mode. The URI Replication (DBR) and Co-operative Provisioning (CP) mode. The URI
prefix for these events is "urn:ietf:params:scim:event:prov". prefix for these events is "urn:ietf:params:scim:event:prov".
For each of the following events when the "data" payload attribute is When the "data" payload attribute is included for each of the
included, the event URI MUST end with "full", otherwise the event URI following events, the event URI MUST end with "full"; otherwise, the
ends with "notice". In "full" mode, the set of values reflecting the event URI ends with "notice". In "full" mode, the set of values
final representation of the resource (such as would be returned in a reflecting the final representation of the resource (such as would be
SCIM protocol response) at the Service Provider are provided using returned in a SCIM protocol response) at the Service Provider are
the "data" attribute (see Figure 4). In "notice" mode, the provided using the "data" attribute (see Figure 4). In "notice"
"attributes" attribute is returned listing the set of attributes mode, the "attributes" attribute is returned and lists the set of
created or modified in the request (see Figure 5). Exactly one of attributes created or modified in the request (see Figure 5).
the payload attributes "data" or "attributes", MUST be present. Both Exactly one of the payload attributes, "data" or "attributes", MUST
MUST NOT be present simultaneously. be present. Both MUST NOT be present simultaneously.
2.4.1. urn:ietf:params:scim:event:prov:create:{notice|full} 2.4.1. urn:ietf:params:scim:event:prov:create:{notice|full}
Indicates a new SCIM resource has been created by the SCIM Service The specified resource indicates that a new SCIM resource has been
Provider and has been added to the Event Feed. Note that because the created by the SCIM Service Provider and has been added to the Event
event may be used for replication, the "id" attribute that was Feed. Note that because the event may be used for replication, the
assigned by the SCIM Service Provider is shared so that all replicas "id" attribute that was assigned by the SCIM Service Provider is
in the domain MAY use the same resource identifier. shared so that all replicas in the domain MAY use the same resource
identifier.
{ {
"jti": "4d3559ec67504aaba65d40b0363faad8", "jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404, "iat": 1458496404,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"sub_id": { "sub_id": {
skipping to change at page 12, line 33 skipping to change at line 511
"userName", "userName",
"password", "password",
"emails" "emails"
] ]
} }
} }
} }
Figure 5: Example SCIM Create Event (Notice) Figure 5: Example SCIM Create Event (Notice)
The event shown in Figure 5 notifies the Event Receiver which The event shown in Figure 5 notifies the Event Receiver of which
attributes have changed but does not convey the actual information. attributes have changed, but it does not convey the actual
The Event Receiver MAY retrieve that information by performing a SCIM information. The Event Receiver MAY retrieve that information by
GET based on the "sub_id" value provided. performing a SCIM GET based on the "sub_id" value provided.
2.4.2. urn:ietf:params:scim:event:prov:patch:{notice|full} 2.4.2. urn:ietf:params:scim:event:prov:patch:{notice|full}
The specified resource has been updated using SCIM PATCH. In "full" The specified resource has been updated using SCIM PATCH. In "full"
mode, the "data" payload attribute is included (see Figure 6). When mode, the "data" payload attribute is included (see Figure 6). When
the event URI ends with "notice", the list of modified attributes is the event URI ends with "notice", the list of modified attributes is
provided (see Figure 7). provided (see Figure 7).
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
skipping to change at page 17, line 9 skipping to change at line 675
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 10: Example SCIM Delete Event Figure 10: Example SCIM Delete Event
2.4.5. urn:ietf:params:scim:event:prov:activate 2.4.5. urn:ietf:params:scim:event:prov:activate
The specified resource (e.g., User) has been "activated". This does The specified resource (e.g., User) has been "activated". This does
not necessarily reflect any particular state change at the SCIM not necessarily reflect any particular state change at the SCIM
Service Provider but may simply indicate the account defined by the Service Provider but may simply indicate that the account defined by
SCIM resource is ready for use as agreed upon by the Event Publisher the SCIM resource is ready for use as agreed upon by the Event
and Event Receiver. For example, an activated resource can represent Publisher and Event Receiver. For example, an activated resource can
an account that may be logged in. represent an account that may be logged in.
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462" "uri": "/Users/2b2f880af6674ac284bae9381673d462"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:activate": {} "urn:ietf:params:scim:event:prov:activate": {}
}, },
skipping to change at page 18, line 4 skipping to change at line 713
means the subject may no longer have an active security session. means the subject may no longer have an active security session.
2.5. Miscellaneous Events 2.5. Miscellaneous Events
This section defines related miscellaneous events such as This section defines related miscellaneous events such as
Asynchronous Request completion that has occurred within a SCIM Asynchronous Request completion that has occurred within a SCIM
Service Provider. The URI prefix for these events is Service Provider. The URI prefix for these events is
"urn:ietf:params:scim:event:misc". "urn:ietf:params:scim:event:misc".
2.5.1. Asynchronous Events 2.5.1. Asynchronous Events
2.5.1.1. Making an Asynchronous SCIM Request 2.5.1.1. Making an Asynchronous SCIM Request
A SCIM Client making SCIM HTTP requests defined in Section 3 of A SCIM Client making SCIM HTTP requests defined in Section 3 of
[RFC7644] MAY request asynchronous processing using the "Prefer" HTTP [RFC7644] MAY request asynchronous processing using the "Prefer" HTTP
Header as defined in Section 4.1 of [RFC7240]. The client may do header as defined in Section 4.1 of [RFC7240]. The client may do
this for a number of reasons such as avoiding holding HTTP this for a number of reasons such as avoiding holding HTTP
connections open during long requests, because the result of the connections open during long requests because the result of the
request is not needed, or for co-ordination reasons where the result request is not needed or the result is delivered to another entity
is delivered to another entity for further action. for further action for co-ordination reasons.
To initiate an asynchronous SCIM request, a normal SCIM protocol To initiate an asynchronous SCIM request, a normal SCIM protocol
POST, PUT, PATCH, or DELETE request is performed with the HTTP POST, PUT, PATCH, or DELETE request is performed with the HTTP
"Prefer" Header set to "respond-async" (Section 4.1 of [RFC7240]). "Prefer" header set to "respond-async" (Section 4.1 of [RFC7240]).
The HTTP "Accept" header MUST be ignored for purposes of an The HTTP "Accept" header MUST be ignored for purposes of an
asynchronous response. Additionally, per Section 4.3 of [RFC7240], asynchronous response. Additionally, per Section 4.3 of [RFC7240],
the "wait" preference SHOULD be supported to establish a maximum time the "wait" preference SHOULD be supported to establish a maximum time
before a SCIM Service Provider MAY choose to respond asynchronously. before a SCIM Service Provider MAY choose to respond asynchronously.
In response, the SCIM Service Provider either returns a normal SCIM In response, the SCIM Service Provider returns either a normal SCIM
response or returns HTTP Status 202 (Accepted). The asynchronous response or HTTP Status 202 (Accepted). The asynchronous response
response MUST contain no response body. To enable correlation of the MUST contain no response body. To enable correlation of the future
future event, the HTTP response header "Set-Txn" (see Section 3) is event, the HTTP response header "Set-Txn" (see Section 3) is returned
returned with a value that MUST match the "txn" claim in a subsequent with a value that MUST match the "txn" claim in a subsequent Security
Security Event Token. Per [RFC7240], Section 3, the response will Event Token. Per [RFC7240], Section 3, the response will also
also include the "Preference-Applied" header. The "Location" header include the "Preference-Applied" header. The "Location" header value
value MUST be one of the following: (a) a URI where the completion MUST be one of the following: (a) a URI where the completion SCIM
SCIM Event Token MAY be retrieved using HTTP GET, or (b) the normal Event Token MAY be retrieved using HTTP GET or (b) the normal SCIM
SCIM location header response specified by [RFC7644]. location header response specified by [RFC7644].
In the following non-normative example, a "Prefer" header is set to In the following non-normative example, a "Prefer" header is set to
"respond-async": "respond-async":
PUT /Users/2819c223-7f76-453a-919d-413861904646 PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: scim.example.com Host: scim.example.com
Prefer: respond-async Prefer: respond-async
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
skipping to change at page 19, line 47 skipping to change at line 788
Figure 13 Figure 13
2.5.1.2. Asynchronous Bulk Endpoint Requests 2.5.1.2. Asynchronous Bulk Endpoint Requests
Section 3.7 of [RFC7644] provides the ability to submit multiple SCIM Section 3.7 of [RFC7644] provides the ability to submit multiple SCIM
operations in a single "bulk" request. When an asynchronous response operations in a single "bulk" request. When an asynchronous response
is requested, a single Asynchronous Request Completion Event MUST be is requested, a single Asynchronous Request Completion Event MUST be
generated for each requested operation. For example, if a single generated for each requested operation. For example, if a single
"bulk" request had 10 operations, then 10 Asynchronous Event "bulk" request had 10 operations, then 10 Asynchronous Event
completions events would be generated. completion events would be generated.
The "txn" claim MUST be set to the value originally returned to the The "txn" claim MUST be set to the value originally returned to the
requesting SCIM Client (see Section 2.5.1.1) appended with a colon requesting SCIM Client (see Section 2.5.1.1) appended with a colon
":" and the zero-based array index of the operation expressed in the ":" and the zero-based array index of the operation expressed in the
"Operations" attribute of the original bulk request. The "bulkId" "Operations" attribute of the original bulk request. The "bulkId"
parameter MUST NOT be used for this purpose as it is a temporary parameter MUST NOT be used for this purpose as it is a temporary
identifier and is not required for every operation. identifier and is not required for every operation.
For example, if a SCIM Service Provider received a Bulk request with For example, if a SCIM Service Provider received a bulk request with
two or more operations, and had a "txn" claim value of two or more operations, and had a "txn" claim value of
"2d80e537a3f64622b0347b641ebc8f44", then the first Asynchronous "2d80e537a3f64622b0347b641ebc8f44", then the first Asynchronous
Response Event Token representing the first operation has a "txn" Response Event Token representing the first operation has a "txn"
claim value of "2d80e537a3f64622b0347b641ebc8f44:0", the second claim value of "2d80e537a3f64622b0347b641ebc8f44:0", the second
operation has a value of "2d80e537a3f64622b0347b641ebc8f44:1", and so operation has a value of "2d80e537a3f64622b0347b641ebc8f44:1", and so
on. on.
If a SCIM Service Provider optimizes the sequence of operations (per If a SCIM Service Provider optimizes the sequence of operations (per
Section 3.7 of [RFC7644]), the Asynchronous Request Completion events Section 3.7 of [RFC7644]), the Asynchronous Request Completion events
generated MAY be generated out of sequence from the original request. MAY be generated out of sequence from the original request. In this
In this case, the "txn" claims in those events MUST use operation case, the "txn" claims in those events MUST use operation numbers
numbers that correspond to the order in the original request. that correspond to the order in the original request.
2.5.1.3. urn:ietf:params:scim:event:misc:asyncresp 2.5.1.3. urn:ietf:params:scim:event:misc:asyncresp
The Asynchronous Response event signals the completion of a SCIM The Asynchronous Response event signals the completion of a SCIM
request. The event payload contains the attributes defined in request. The event payload contains the attributes defined in
Section 3.7 of [RFC7644] and is the same as a single SCIM Bulk Section 3.7 of [RFC7644] and is the same as a single SCIM Bulk
Response Operation as per Section 3.7.3. In the event, the "txn" Response Operation as per Section 3.7.3 of [RFC7644]. In the event,
claim MUST be set to the value originally returned to the requesting the "txn" claim MUST be set to the value originally returned to the
SCIM Client (see Section 2.5.1.1). requesting SCIM Client (see Section 2.5.1.1).
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646" "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
}, },
"txn": "734f0614e3274f288f93ac74119dcf78", "txn": "734f0614e3274f288f93ac74119dcf78",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
skipping to change at page 22, line 36 skipping to change at line 881
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 15: Example SCIM Asynchronous Error Response Event Figure 15: Example SCIM Asynchronous Error Response Event
The following 4 figures show Asynchronous Completion events for the The following four figures show Asynchronous Completion events for
example in Section 3.7.3 of [RFC7644]. the example in Section 3.7.3 of [RFC7644].
{ {
"jti": "dbae9d7506b34329aa7f2f0d3827848b", "jti": "dbae9d7506b34329aa7f2f0d3827848b",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a" "uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:1", "txn": "2d80e537a3f64622b0347b641ebc8f44:1",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
skipping to change at page 23, line 27 skipping to change at line 906
"status": "201" "status": "201"
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 16: Example SCIM Asynchronous Response Event Operation 1/4 Figure 16: Example SCIM Asynchronous Response Event Operation (1
of 4)
{ {
"jti": "ca977d05ba5c43929e3a69023d5392a9", "jti": "ca977d05ba5c43929e3a69023d5392a9",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/b7c14771-226c-4d05-8860-134711653041" "uri": "/Users/b7c14771-226c-4d05-8860-134711653041"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:2", "txn": "2d80e537a3f64622b0347b641ebc8f44:2",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
skipping to change at page 23, line 50 skipping to change at line 930
"status": "200" "status": "200"
} }
}, },
"iat": 1458505045, "iat": 1458505045,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 17: Example SCIM Asynchronous Response Event Operation 2/4 Figure 17: Example SCIM Asynchronous Response Event Operation (2
of 4)
{ {
"jti": "4bb87d70a4ab463bbdcd1f99111cbbf1", "jti": "4bb87d70a4ab463bbdcd1f99111cbbf1",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc" "uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:3", "txn": "2d80e537a3f64622b0347b641ebc8f44:3",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
skipping to change at page 24, line 26 skipping to change at line 954
"status": "200" "status": "200"
} }
}, },
"iat": 1458505046, "iat": 1458505046,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 18: Example SCIM Asynchronous Response Event Operation 3/4 Figure 18: Example SCIM Asynchronous Response Event Operation (3
of 4)
{ {
"jti": "6a7843a7f5244d0eb62ca38b641d9139", "jti": "6a7843a7f5244d0eb62ca38b641d9139",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b" "uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:4", "txn": "2d80e537a3f64622b0347b641ebc8f44:4",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
skipping to change at page 24, line 48 skipping to change at line 977
"status": "204" "status": "204"
} }
}, },
"iat": 1458505047, "iat": 1458505047,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
} }
Figure 19: Example SCIM Asynchronous Response Event Operation 4/4 Figure 19: Example SCIM Asynchronous Response Event Operation (4
of 4)
3. Set-Txn HTTP Response Header for Asynchronous Requests 3. Set-Txn HTTP Response Header for Asynchronous Requests
This specification defines a new HTTP Header field "Set-Txn" which This specification defines a new HTTP header field, "Set-Txn", which
serves the purpose of conveying request completion information to serves the purpose of conveying request completion information to
SCIM HTTP clients that request an asynchronous response as described SCIM HTTP clients that request an asynchronous response as described
in Section 2.5.1.1. The header field MUST be used in SCIM Responses in Section 2.5.1.1. The header field MUST be used in SCIM Responses
when HTTP Status 202 Accepted is being returned with no message body. when HTTP Status 202 Accepted is being returned with no message body.
The "Set-Txn" HTTP Header field value is a unique STRING (e.g., a The "Set-Txn" HTTP header field value is a unique STRING (e.g., a
GUID) used by the SCIM HTTP client to look for a matching SET event Globally Unique Identifier (GUID)) used by the SCIM HTTP client to
with a matching "txn" claim (see Section 2 of [RFC8417]) confirming look for a matching SET event with a matching "txn" claim (see
the request completion status as described in Section 2.5.1.1. Section 2 of [RFC8417]) confirming the request completion status as
described in Section 2.5.1.1.
Intermediaries SHOULD NOT insert, modify, or delete the field's Intermediaries SHOULD NOT insert, modify, or delete the field's
value. value.
SCIM clients MAY ignore the header in cases where confirmation of SCIM clients MAY ignore the header in cases where confirmation of
completion is not required. For example a SCIM client may simply not completion is not required. For example, a SCIM client may simply
want to wait for synchronous completion. not want to wait for synchronous completion.
4. Events Discovery Schema for Service Provider Configuration 4. Events Discovery Schema for Service Provider Configuration
Section 5 of [RFC7643] defines SCIM Service Provider configuration Section 5 of [RFC7643] defines SCIM Service Provider configuration
schemas. This section defines additional attributes that enable a schemas. This section defines additional attributes that enable a
SCIM Client to discover the additional capabilities defined by this SCIM Client to discover the additional capabilities defined by this
specification. specification.
securityEvents securityEvents
A SCIM Complex attribute that specifies the available capabilities A SCIM Complex attribute that specifies the available capabilities
related to asynchronous Security Events based on [RFC8417]. This related to asynchronous Security Events based on [RFC8417]. This
attribute is OPTIONAL and when absent indicates the SCIM Service attribute is OPTIONAL, and when absent, it indicates the SCIM
Provider does not support or is not currently configured for Service Provider does not support or is not currently configured
Security Events. The following sub-attributes are defined: for Security Events. The following sub-attributes are defined:
asyncRequest asyncRequest
A case-insensitive string value specifying one of the A case-insensitive string value specifying one of the
following: following:
* "none" indicates asynchronous SCIM requests defined in * "none" indicates that asynchronous SCIM requests defined in
Section 2.5.1.1 are not supported; Section 2.5.1.1 are not supported;
* "long" indicates the server completes requests * "long" indicates that the server completes requests
asynchronously at server discretion (e.g. based on a max asynchronously at the server's discretion (e.g., based on a
wait time); max wait time); and
* "request" indicates the server completes requests * "request" indicates that the server completes requests
asynchronously when requested by the SCIM Client. asynchronously when requested by the SCIM Client.
eventUris eventUris
A multivalued string listing the SET Event URIs (defined in A multivalued string listing the SET Event URIs (defined in
[RFC8417]) that the server is capable of generating and [RFC8417]) that the server is capable of generating and
deliverable via a SET Stream (see [RFC8935] and [RFC8936]). delivering via a SET Stream (see [RFC8935] and [RFC8936]).
This information is informational only. Stream registration This information is informational only. Stream registration
and configuration are out of scope of this specification. and configuration are out of scope of this specification.
5. Security Considerations 5. Security Considerations
As this specification is based upon the Security Event Tokens As this specification is based upon the SETs specification and the
specification and the associated delivery specifications the associated delivery specifications, the following security
following Security Considerations are also applicable to this considerations are also applicable to this specification:
specification:
* Section 5 of [RFC8417] (Security Event Token) * Section 5 of [RFC8417] (Security Event Token)
* Section 5 of [RFC8935] (Push-based Delivery Using HTTP) * Section 5 of [RFC8935] (Push-Based SET Delivery Using HTTP)
* Section 4 of [RFC8936] (Poll-Based Delivery Using HTTP) * Section 4 of [RFC8936] (Poll-Based SET Delivery Using HTTP)
SETs may contain sensitive information, including Personally SETs may contain sensitive information, including Personally
Identifiable Information (PII). In such cases, SET Transmitters and Identifiable Information (PII). In such cases, SET Transmitters and
SET Recipients MUST protect the confidentiality of the SET contents SET Recipients MUST protect the confidentiality of the SET contents
in transit using TLS [BCP195]. in transit using TLS [BCP195].
When co-ordinating provisioning between entities, the long-term When co-ordinating provisioning between entities, the long-term
series of changes may be critical to the information integrity and series of changes may be critical to the information integrity and
recovery requirements of both sides. To address this, Event recovery requirements of both sides. To address this, Event
Publishers can make events available for receivers for longer periods Publishers can make events available for receivers for longer periods
of time than might typically be used for recovering from momentary of time than might typically be used for recovering from momentary
delivery failures and retries per [RFC8935] or [RFC8936]. Similarly, delivery failures and retries per [RFC8935] or [RFC8936]. Similarly,
Event Receivers MUST ensure events are persisted directly or Event Receivers MUST ensure events are persisted directly or
indirectly to meet local recovery needs before acknowledging the SET indirectly to meet local recovery needs before acknowledging the SET
Events were received. Events were received.
An attacker might leverage transaction and/or signal information An attacker might leverage transaction and/or signal information
contained in SET Event Publisher or Receiver system. To mitigate contained in a SET Event Publisher or Receiver system. To mitigate
this, access to event recovery and forwarding MUST be limited to the this, access to event recovery and forwarding MUST be limited to the
parties needed to support recovery or SET forwarding. parties needed to support recovery or SET forwarding.
When SET Events are transferred in such a way as the Event Publisher When SET Events are transferred in such a way that the Event
is not communicating directly to the Event Receiver, it may become Publisher is not communicating directly to the Event Receiver, it may
possible for an attacker or other system to insert an event. To become possible for an attacker or other system to insert an event.
mitigate, Event Receivers MUST verify the originator of a SET using To mitigate, Event Receivers MUST verify the originator of a SET
JWS [RFC7515] signatures when the Event Publisher is not using JSON Web Signature (JWS) [RFC7515] signatures when the Event
communicating directly with the Event Receiver. Validating event Publisher is not communicating directly with the Event Receiver.
signatures may also be useful for auditing purposes as signed SET Validating event signatures may also be useful for auditing purposes
Events are protected from tampering in the event that an intermediate as signed SET Events are protected from tampering in the event that
system, such as a TLS-terminating proxy, decrypts the SET payload an intermediate system, such as a TLS-terminating proxy, decrypts the
before sending it onward to its intended recipient. SET payload before sending it onward to its intended recipient.
In operation, some SCIM Resources such as SCIM Groups may have a high In operation, some SCIM Resources such as SCIM Groups may have a high
rate of change. For examples groups with more than a few thousand rate of change. For example, groups with more than a few thousand
member values could lead to excessive change rates that could lead to member values could lead to excessive change rates, which could lead
a loss of SET Events between Event Publishers and Event Receivers. to a loss of SET Events between Event Publishers and Event Receivers.
To mitigate this risk, consider the following to help mitigate To mitigate this risk, consider the following to help with throughput
throughput issues: issues:
* The use of SCIM PUT (Section 3.5.1 of [RFC7644]), particularly * The use of SCIM PUT (Section 3.5.1 of [RFC7644]), particularly
with large SCIM Groups, can result in excessive data being with large SCIM Groups, can result in excessive data being
conveyed in Security Event payloads. Instead, it is RECOMMENDED conveyed in Security Event payloads. Instead, it is RECOMMENDED
to use SCIM PATCH (Section 3.5.2 of [RFC7644]) to focus on to use SCIM PATCH (Section 3.5.2 of [RFC7644]) to focus on
updating and notifying about changed information. Alternatively, updating and notifying about changed information. Alternatively,
use SCIM PUT Event Notice use SCIM PUT Event Notice
(urn:ietf:params:scim:event:prov:put:notice) as a trigger to later (urn:ietf:params:scim:event:prov:put:notice) as a trigger to later
retrieve the full information when needed. retrieve the full information when needed.
* Use SCIM Patch Event Notice * Use SCIM Patch Event Notice
(urn:ietf:params:scim:event:prov:patch:notice) to reduce event (urn:ietf:params:scim:event:prov:patch:notice) to reduce event
content combined with periodic SCIM GETs (see section 3.4 of content combined with periodic SCIM GETs (see Section 3.4 of
[RFC7644]) to retrieve current group state. [RFC7644]) to retrieve current group state.
* Aggregate multiple PATCH Events into a single event. Providing * Aggregate multiple PATCH Events into a single event. Providing
the exact date of each membership change is not critical but the exact date of each membership change is not critical but
instead that the information content remains intact. instead that the information content remains intact.
When using Asynchronous SCIM Requests (see Section 2.5.1.1), a SCIM When using Asynchronous SCIM Requests (see Section 2.5.1.1), a SCIM
Service provider returns a SCIM Accepted response with a URI for Service Provider returns a SCIM Accepted response with a URI for
retrieving the event result. An unauthorized entity or attacker retrieving the event result. An unauthorized entity or attacker
could obtain asynchronous request completion event information by could obtain asynchronous request completion event information by
querying the asynchronous operation result endpoint used by a SCIM querying the asynchronous operation result endpoint used by a SCIM
Service Provider. To mitigate, the returned URI endpoint MUST be Service Provider. To mitigate, the returned URI endpoint MUST be
protected requiring an HTTP Authorization header or some other form protected and requires an HTTP Authorization header or some other
of client authentication. form of client authentication.
6. Privacy Considerations 6. Privacy Considerations
As this specification is based upon the Security Event Tokens and the As this specification is based upon the SET specification and the
associated delivery specifications the following Privacy associated delivery specifications, the following privacy
Considerations are also applicable to this specification: considerations are also applicable to this specification:
* Section 6 of [RFC8417] (Security Event Token) * Section 6 of [RFC8417] (Security Event Token)
* Section 6 of [RFC8935] (Push-based Delivery Using HTTP) * Section 6 of [RFC8935] (Push-Based SET Delivery Using HTTP)
* Section 5 of [RFC8936] (Poll-Based Delivery Using HTTP) * Section 5 of [RFC8936] (Poll-Based SET Delivery Using HTTP)
This specification enables the sharing of information between This specification enables the sharing of information between
domains. The specification assumes that implementers and deployers domains; therefore, it is assumed that implementers and deployers are
are operating under one of the following scenarios: operating under one of the following scenarios:
* A common administrative domain where there is one administrative * A common administrative domain where there is one administrative
owner of the data. In these cases, the goal is to protect privacy owner of the data. In these cases, the goal is to protect privacy
and security of the owner and user data by keeping information and security of the owner and user data by keeping information
systems co-ordinated and up-to-date. For example, the domains systems co-ordinated and up to date. For example, the domains
decide to use Domain Based Replication mode to keep employee decide to use DBR mode to keep employee information synchronized.
information synchronized.
* In a co-operative or co-ordinated relationship, parties have * In a co-operative or co-ordinated relationship, parties have
decided to share a limited amount of data and/or signals for the decided to share a limited amount of data and/or signals for the
benefits of their users. Depending on end-user consent, benefits of their users. Depending on end-user consent,
information is shared on an as-authorized and/or as-needed basis. information is shared on an as-authorized and/or as-needed basis.
For example, the domains agree to use Co-ordinated Provision mode For example, the domains agree to use CP mode that exchanges
that exchanges things like account status or specific minimal things such as account status or specific minimal attribute
attribute information that must be fetched on request after information that must be fetched on request after receiving notice
receiving notice of a change. This enables authorization to be of a change. This enables authorization to be verified each time
verified each time data is transferred. data is transferred.
In general, the sharing of SCIM Event information falls within a pre- In general, the sharing of SCIM Event information falls within a pre-
existing SCIM Client and Service Provider relationship and carry no existing SCIM Client and Service Provider relationship and carries no
additional personal information. additional personal information.
7. IANA Considerations 7. IANA Considerations
7.1. SCIM Asynchronous Txn Header Registration 7.1. SCIM Asynchronous Set-Txn Header Registration
This specification registers the HTTP "Set-Txn" field name in the This specification registers the HTTP "Set-Txn" field name in the
"HTTP Field Name Registry" defined in Section 16.3.1 of [RFC9110]. "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in
Section 16.3.1 of [RFC9110].
Field name:
Set-Txn
Status:
Permanent
Reference: Field name: Set-Txn
See Section Section 3 of this document. Status: permanent
Reference: See Section 3 of RFC 9967.
7.2. Registering Event Capability with Scim Service Provider Config 7.2. Registering Event Capability with SCIM Service Provider
Configuration
For the SCIM Schema Registry Section 10.4 of [RFC7643], under Service A reference to Section 4 of this document has been added to the
Provider Configuration Schema "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" entry
("urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"), add in the "SCIM Server-Related Schema URIs" registry (Section 10.4 of
Section 4 of this document to the Reference column. [RFC7643]) under the "System for Cross-domain Identity Management
(SCIM) Schema URIs" registry group.
7.3. Registration of the SCIM Event URIs Registry 7.3. Creation of the SCIM Event URIs Registry
IANA will add a new registry called “SCIM Event URIs” to the “System IANA has created a new registry called "SCIM Event URIs" under the
for Cross-domain Identity Management (SCIM) Schema URIs” registry "System for Cross-domain Identity Management (SCIM) Schema URIs"
group define by Section 10.1 of [RFC7643] at registry group (Section 10.1 of [RFC7643]) at
https://www.iana.org/assignments/scim. <https://www.iana.org/assignments/scim>.
New registrations for this registry are evaluated by a designated New registrations for this registry are evaluated by a designated
expert(s) for relevance to SCIM-based systems, and, to avoid possible expert(s) for relevance to SCIM-based systems and to avoid possible
duplication or conflict with other event definitions that may lie duplication or conflict with other event definitions that may lie
outside SCIM (e.g., Shared Signals [SSF]). outside SCIM (e.g., Shared Signals [SSF]).
Namespace ID: Namespace ID:
The sub-namespace ID of "event" is assigned within the "scim" The sub-namespace ID of "event" is assigned within the "scim"
namespace. namespace.
Syntactic Structure: Syntactic Structure:
The Namespace Specific String (NSS) of all URNs that use the The Namespace Specific String (NSS) of all URNs that use the
"event" Namespace ID has the following structure: "event" Namespace ID has the following structure:
"urn:ietf:params:scim:event:{class}:{name}:{other} "urn:ietf:params:scim:event:{class}:{name}:{other}"
The keywords have the following meaning: The keywords have the following meaning:
class class
The class of events which is one of: "feed", "prov" or "misc". The class of events, which is one of: "feed", "prov", or
"misc".
name name
A US-ASCII string that conforms to URN syntax requirements (see A US-ASCII string that conforms to URN syntax requirements (see
[RFC8141]) and defines a descriptive event name (e.g., [RFC8141]) and defines a descriptive event name (e.g.,
"create"). "create").
other other
An optional US-ASCII string that conforms to URN syntax An optional US-ASCII string that conforms to URN syntax
requirements (see [RFC8141]) and serves as an additional sub- requirements (see [RFC8141]) and serves as an additional sub-
category or qualifier. For example "full" and "notice". category or qualifier, for example, "full" and "notice".
Identifier Uniqueness Considerations: Identifier Uniqueness Considerations:
The designated contact is responsible for reviewing and enforcing The designated contact is responsible for reviewing and enforcing
uniqueness. uniqueness.
Identifier Persistence Considerations: Identifier Persistence Considerations:
Once a name has been allocated it MUST NOT be re-allocated for a Once a name has been allocated, it MUST NOT be reallocated for a
different purpose. The rules provided for assignments of values different purpose. The rules provided for the assignment of
within a sub-namespace MUST be constructed so that the meaning of values within a sub-namespace MUST be constructed so that the
values cannot change. This registration mechanism is not meaning of values cannot change. This registration mechanism is
appropriate for naming values whose meaning may change over time. not appropriate for naming values whose meaning may change over
time.
Registration format: Registration Format:
An event registration MUST include the following fields: An event registration MUST include the following fields:
* Event Uri * Event Uri
* Descriptive Name * Descriptive name
* Reference to event definition * Reference to event definition
Initial values to be added to the SCIM Events Registry are listed 7.4. Initial Contents of the SCIM Event URIs Registry
in Section 7.4.
7.4. Initial Events Registry IANA has added the following initial entries to the "SCIM Event URIs"
registry:
Summary of Event URI registrations: +==========================================+==============+=========+
|Event URI |Name |Reference|
+==========================================+==============+=========+
|urn:ietf:params:scim:event:feed:add |Resource |Section |
| |added to Feed |2.3.1 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:feed:remove |Remove |Section |
| |resource from |2.3.2 of |
| |Feed Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource |Section |
|notice |Event (notice |2.4.1 of |
| |only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource |Section |
|full |Event (full |2.4.1 of |
| |data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|notice |Patch Event |2.4.2 of |
| |(notice only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|full |Patch Event |2.4.2 of |
| |(full data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:put: |Resource Put |Section |
|notice |Event (notice |2.4.3 of |
| |only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:put:full |Resource Put |Section |
| |Event (full |2.4.3 of |
| |data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:delete |Resource |Section |
| |Deleted Event |2.4.4 of |
| | |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:activate |Resource |Section |
| |Activated |2.4.5 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:deactivate|Resource |Section |
| |Deactivated |2.4.6 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:misc:asyncresp |Asynchronous |Section |
| |Request |2.5.1 of |
| |Completion |RFC 9967 |
+------------------------------------------+--------------+---------+
+==========================================+============+=========+
|Event URI |Name |Ref. |
+==========================================+============+=========+
|urn:ietf:params:scim:event:feed:add |Resource |Section |
| |added to |2.3.1 of |
| |Feed Event |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:feed:remove |Remove |Section |
| |resource |2.3.2 of |
| |From Feed |this |
| |Event |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource|Section |
|notice |Event |2.4.1 of |
| |(notice |this |
| |only) |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource|Section |
|full |Event (full |2.4.1 of |
| |data) |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|notice |Patch Event |2.4.2 of |
| |(notice |this |
| |only) |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|full |Patch Event |2.4.2 of |
| |(full data) |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:put: |Resource Put|Section |
|notice |Event |2.4.3 of |
| |(notice |this |
| |only) |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:put:full |Resource Put|Section |
| |Event (full |2.4.3 of |
| |data) |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:delete |Resource |Section |
| |Deleted |2.4.4 of |
| |Event |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:activate |Resource |Section |
| |Activated |2.4.5 of |
| |Event |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:prov:deactivate|Resource |Section |
| |Deactivated |2.4.6 of |
| |Event |this |
| | |document.|
+------------------------------------------+------------+---------+
|urn:ietf:params:scim:event:misc:asyncresp |Asynchronous|Section |
| |Request |2.5.1 of |
| |Completion |this |
| | |document.|
+------------------------------------------+------------+---------+
Table 1 Table 1
8. References 8. References
8.1. Normative References 8.1. Normative References
[BCP195] Best Current Practice 195, [BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>. <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
skipping to change at page 33, line 40 skipping to change at line 1368
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject [RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens", RFC 9493, Identifiers for Security Event Tokens", RFC 9493,
DOI 10.17487/RFC9493, December 2023, DOI 10.17487/RFC9493, December 2023,
<https://www.rfc-editor.org/info/rfc9493>. <https://www.rfc-editor.org/info/rfc9493>.
8.2. Informative References 8.2. Informative References
[I-D.hunt-idevent-scim] [SCIM-EVENT-EXT]
Hunt, P., Denniss, W., and M. Ansari, "SCIM Event Hunt, P., Ed., Denniss, W., and M. Ansari, "SCIM Event
Extension", Work in Progress, Internet-Draft, draft-hunt- Extension", Work in Progress, Internet-Draft, draft-hunt-
idevent-scim-00, 20 March 2016, idevent-scim-00, 20 March 2016,
<https://datatracker.ietf.org/doc/html/draft-hunt-idevent- <https://datatracker.ietf.org/doc/html/draft-hunt-idevent-
scim-00>. scim-00>.
[SSF] OpenID Foundation, "Shared Signals Framework". [SSF] Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman,
A., Bradley, J., and S. Miel, "OpenID Shared Signals
Framework Specification 1.0", 29 August 2025,
<https://openid.net/specs/openid-sharedsignals-framework-
1_0.html>.
Appendix A. Use Cases Appendix A. Use Cases
SCIM Events may be used in a number of ways. The following non- SCIM Events may be used in a number of ways. The following non-
normative sections describe some of the expected uses. normative sections describe some of the expected uses.
A.1. Domain Based Replication A.1. Domain-Based Replication
The objective of "Domain Based Replication" events (DBR) is to The objective of DBR events is to synchronize resource changes
synchronize resource changes between SCIM Service Providers in a between SCIM Service Providers in a common administrative domain. In
common administrative domain. In this mode, complete information this mode, complete information about modified resources are shared
about modified resources are shared between replicas for immediate between replicas for immediate processing.
processing.
+----------------+ +----------------+
| SCIM Client A | | SCIM Client A |
+----------------+ +----------------+
| |
[1] SCIM Operation [1] SCIM Operation
| |
v v
+----------------+ +----------------+
| Service | | Service |
skipping to change at page 34, line 42 skipping to change at line 1422
+------------------------+ +------------------------+
| |
[3] Event SCIM:prov:<op> id=xyz [3] Event SCIM:prov:<op> id=xyz
| |
v v
+----------------+ +----------------+
| Update local | | Update local |
| node [4] | | node [4] |
+----------------+ +----------------+
Figure 20: Domain Based Replication Sequence Figure 20: Domain-Based Replication Sequence
From a security perspective, it is assumed that servers sharing DBR From a security perspective, it is assumed that servers sharing DBR
events are secured by a common access policy and all servers are events are secured by a common access policy and all servers are
required to be up-to-date. From a privacy perspective, because all required to be up to date. From a privacy perspective, because all
servers are in the same administrative domain, the primary objective servers are in the same administrative domain, the primary objective
is to keep individual Service Provider nodes or cluster synchronized. is to keep individual Service Provider nodes or clusters
synchronized.
A.2. Co-ordinated Provisioning A.2. Co-ordinated Provisioning
In "Co-ordinated Provisioning" (CP), SCIM resource change events In CP, SCIM resource change events perform the function of change
perform the function of change notification without the need to notification without the need to provide raw data. In any Event
provide raw data. In any Event Publisher and Receiver relationship, Publisher and Receiver relationship, the set of SCIM Resources (e.g.,
the set of SCIM Resources (e.g., Users) that are linked or co- Users) that are linked or co-ordinated is managed within the context
ordinated is managed within the context of an event feed and may be a of an event feed and may be a subset of the total set of resources on
subset of the total set of resources on either side. For example, an either side. For example, an event feed could be limited to users
event feed could be limited to users who have consented to the who have consented to the sharing of information between domains. To
sharing of information between domains. To support capability, support capability, "feed" specific events are defined to indicate
"feed" specific events are defined to indicate the addition and the addition and removal of SCIM Resources from a feed. For example,
removal of SCIM Resources from a feed. For example, when a user when a user consents to the sharing of information between domains,
consents to the sharing of information between domains, events about events about the User may be added to the feed between the Event
the User may be added to the feed between the Event Publisher and Publisher and Receiver.
Receiver.
+-----------+ +---------------+ +---------------+ +---------------+ +-----------+ +---------------+ +---------------+ +---------------+
| SCIM Clnt | | SCIM Service | | Client A Co-op| | Co-op Action | | SCIM Clnt | | SCIM Service | | Client A Co-op| | Co-op Action |
| (CA) | | Provider (SP) | | Receiver (ER) | | Endpoint(LEP) | | (CA) | | Provider (SP) | | Receiver (ER) | | Endpoint(LEP) |
+-----------+ +---------------+ +---------------+ +---------------+ +-----------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| "SCIM Operation" | | | | "SCIM Operation" | | |
+----------------->| | | +----------------->| | |
|<-----------------+ "SCIM Response" | | |<-----------------+ "SCIM Response" | |
| | | | | | | |
skipping to change at page 35, line 44 skipping to change at line 1469
| | | events for | | | | events for |
| | | periodic action | | | | periodic action |
| |<------------------+ "SCIM GET <id>" | | |<------------------+ "SCIM GET <id>" |
| |------------------>| "Filtered | | |------------------>| "Filtered |
| | | Resource Resp." | | | | Resource Resp." |
| | | | | | | |
| | +------------------>| | | +------------------>|
| | | "Co-ord Action" | | | | "Co-ord Action" |
| | | | | | | |
Figure 21: Co-Ordinated Provisioning Sequence Figure 21: Co-ordinated Provisioning Sequence
In CP mode, the receiver of an event must call back to the In CP mode, the receiver of an event must call back to the
originating SCIM Service Provider (e.g., using a SCIM GET request) to originating SCIM Service Provider (e.g., using a SCIM GET request) to
reconcile the newly changed resource in order to obtain the changes. reconcile the newly changed resource in order to obtain the changes.
Co-ordinated provisioning has the following benefits: CP has the following benefits:
* Differences in schema (e.g., attributes) between domains. For * Differences in schema (e.g., attributes) between domains. For
example, a receiving domain may only be interested in or allowed example, a receiving domain may only be interested in or allowed
to access to a few attributes (e.g., role-based access data) to to access to a few attributes (e.g., role-based access data) to
enable access to an application. enable access to an application.
* Different Event Receivers may have differing needs when accessing * Different Event Receivers may have differing needs when accessing
information and thus be assigned varying access rights. Minimal information and thus may be assigned varying access rights.
information events combined with callbacks for data allows data Minimal information events combined with callbacks for data allows
filtering to be applied. data filtering to be applied.
* Receivers can take independent action. Such as deciding which * Receivers can take independent action such as deciding which
attributes or resource lifecycle changes to accept. For example, attributes or resource life cycle changes to accept. For example,
in the case of a conflict, a receiver can prioritize one domain in the case of a conflict, a receiver can prioritize one domain
source over another. source over another.
* A receiver may throttle or buffer changes rather than act * A receiver may throttle or buffer changes rather than act
immediately on a notification. For example, for a frequently immediately on a notification. For example, for a frequently
changing resource, the receiver may choose to make a scheduled changing resource, the receiver may choose to make a scheduled
SCIM GET for resources that have been marked "dirty" by events SCIM GET for resources that have been marked "dirty" by events
received in the last scheduled cycle. received in the last scheduled cycle.
A disadvantage of the CP approach is that it may be considered costly A disadvantage of the CP approach is that it may be considered costly
in the sense that each event received might trigger a callback to the in the sense that each event received might trigger a callback to the
event issuer. This cost should be weighed against the cost producing event issuer. This cost should be weighed against the cost producing
filtered information in each event for each receiver. Furthermore, a filtered information in each event for each receiver. Furthermore, a
receiver is not required to make a callback on every provisioning receiver is not required to make a callback on every provisioning
event. event.
It is assumed that an underlying relationship between domains exists It is assumed that an underlying relationship between domains exists
that permits the exchange of personal information and credentials. that permits the exchange of personal information and credentials.
For example, in a cross-domain scenario a SCIM Service Provider would For example, in a cross-domain scenario, a SCIM Service Provider
have been previously authorized to perform SCIM provisioning would have been previously authorized to perform SCIM provisioning
operations and publish change events. As such, appropriate operations and publish change events. As such, appropriate
confidentiality and privacy agreements should be in place between the confidentiality and privacy agreements should be in place between the
domains. domains.
When sharing information between parties, CP Events minimize the When sharing information between parties, CP Events minimize the
information shared in each message and require the Security Event information shared in each message and require the Security Event
Receiver to receive more information from the Event Publisher as Receiver to receive more information from the Event Publisher as
needed. In this way, the Event Receiver is able to have regular needed. In this way, the Event Receiver is able to have regular
access to information through normal SCIM protocol access access to information through normal SCIM protocol access
restrictions. The Event Receiver and Publisher may agree to restrictions. The Event Receiver and Publisher may agree to
communicate these updates through a variety of transmission methods communicate these updates through a variety of transmission methods
such as push and pull based HTTP like in [RFC8935], [RFC8936], or such as push- and pull-based HTTP [RFC8935] [RFC8936] or HTTP GET
HTTP GET (see Section 2.5.1.1), streaming technologies (e.g., Kafka (see Section 2.5.1.1); streaming technologies (e.g., Kafka or
or Kinesis), or via webhooks as in the Shared Signals Framework Kinesis); or webhooks such as in the Shared Signals Framework [SSF].
[SSF].
Acknowledgements Acknowledgements
The authors would like to thank the following contributors: The authors would like to thank the following contributors:
* Morteza Ansari and William Denniss, who contributed significantly * Morteza Ansari and William Denniss, who contributed significantly
to [I-D.hunt-idevent-scim], upon which this draft is based. to [SCIM-EVENT-EXT] upon which this document is based.
* The participants of the SCIM working group and the id-event list * The participants of the SCIM Working Group and the IETF id-event
for their support of this specification. mailing list for their support of this specification.
* Thanks to Deb Cooley, Dean Saxe, Elliot Lear, Pamela Dingle, Mark * Deb Cooley, Dean Saxe, Elliot Lear, Pamela Dingle, Mark
Nottingham, R Gideon, Paulo Jorge Correia, Shuping Peng, Elwyn Nottingham, R Gideon, Paulo Jorge Correia, Shuping Peng, Elwyn
Davies, Luigi Lannone, Mohamed Boucadair, Roman Danyliw, Ketan Davies, Luigi Lannone, Mohamed Boucadair, Roman Danyliw, Ketan
Talaulikar, Mahesh Jethanandani, and Mike Bishop for their write- Talaulikar, Mahesh Jethanandani, and Mike Bishop for their write-
ups and reviews ups and reviews.
Change Log
This section is to be removed before publishing as an RFC.
Draft 00 - PH - First WG Draft
Draft 01 - PH - Moved non-normative sections to Appendix, Security,
and Privacy Considerations
Draft 02 - PH - Clarifications on Async Events, IANA Considerations
Draft 03 - PH - Fixed Header Field registration to
RFC9110."Preference-Applied" header in async response. Support for
Async Bulk requests. Added IANA SCIM Event Registry
Draft 04 - PH - Removed Event Delivery Feeds and Appendix A(not
normative), Removed "sig" events, change bulk txn separator to ":",
Updated SubId Reference to RFC9493, other comments, fixed IANA
registry paragraph, SCIM Signals Removed
Draft 05 - PH - Removed Signals Events, Removed Delivery Section (not
normative), Version(etag) definition added, Security Considerations
revisions, Syntax for Attributes
Draft 06 - PH - Editorial edits and clarifications, add SSF reference
Draft 07 - PH - Document date update only
Draft 08 - PH - Update to Security Considerations to frame as risk/
correction
Draft 09 - PH - Incorporating feedback from AD
Draft 10 - PH - IANA and ARTART Feedback
Draft 11 - PH - GenArt, OpsDir Feedback including new section on set-
txn header, removed unicode art characters.
Draft 12 - PH - Update reference to Shared Signals to stable, IESG
feedback
Draft 13 - PH - Tweaked usage of normative language
Draft 14 - PH - Modified IANA procedures for event registry
Draft 15 - PH - Replace tt elements with plain quotes
Draft 16 - PH - IANA Revisions
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Independent Identity Inc Independent Identity Inc
Email: phil.hunt@independentid.com Email: phil.hunt@independentid.com
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
 End of changes. 129 change blocks. 
504 lines changed or deleted 445 lines changed or added

This html diff was produced by rfcdiff 1.48.