rfc9967v2.txt		rfc9967.txt
	skipping to change at line 20 ¶		skipping to change at line 20 ¶
	May 2026		May 2026
	System for Cross-Domain Identity Management (SCIM) Profile for Security		System for Cross-Domain Identity Management (SCIM) Profile for Security
	Event Tokens (SETs)		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
	(SET) specification (RFC 8417) to enable the asynchronous exchange of		(SET) specification (RFC 8417) to enable the asynchronous exchange of
	messages between SCIM Service Providers and receivers.		messages between SCIM service providers and receivers.
	This specification updates RFC 7643 by defining additional attributes		This specification updates RFC 7643 by defining additional attributes
	for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"		for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"
	schema, and it updates RFC 7644 with an optional new Asynchronous		schema, and it updates RFC 7644 with an optional new asynchronous
	SCIM Request capability.		SCIM request capability.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 98 ¶		skipping to change at line 98 ¶
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Appendix A. Use Cases		Appendix A. Use Cases
	A.1. Domain-Based Replication		A.1. Domain-Based Replication
	A.2. Coordinated Provisioning		A.2. Coordinated Provisioning
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	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 Security Event Tokens (SETs) [RFC8417].		and receivers as specified by Security Event Tokens (SETs) [RFC8417].
	In this specification, SCIM Security Events include asynchronous		In this specification, SCIM Security Events include asynchronous
	request completion, resource replication, and provisioning		request completion, resource replication, and provisioning
	coordination.		coordination.
	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 client [RFC7644] to request		respond-async" [RFC7240] to allow a SCIM client [RFC7644] to request
	an asynchronous response (see Section 2.5.1.1).		an asynchronous response (see Section 2.5.1.1).
	Using the HTTP protocol, a SCIM client issues commands to a SCIM		Using the HTTP protocol, a SCIM client issues commands to a SCIM
	Service Provider using HTTP methods such as POST, PATCH, and DELETE		service provider using HTTP methods such as POST, PATCH, and DELETE
	[RFC7644] that cause a state change to a SCIM Resource. When		[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 coordination or		need to be informed of these changes for coordination 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
	changed information is exchanged between parties.		changed information is exchanged between parties.
	A SET conveys information about a state change that has occurred at a		A SET conveys information about a state change that has occurred at a
	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		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at line 193 ¶		skipping to change at line 193 ¶
	Domain-Based Replication (DBR):		Domain-Based Replication (DBR):
	As defined in Appendix A.1, in the DBR mode, there is an		As defined in Appendix A.1, in the DBR mode, there is an
	administrative relationship spanning multiple operational domains;		administrative relationship spanning multiple operational domains;
	data shared in Events typically uses the "full" mode variation of		data shared in Events typically uses the "full" mode variation of
	change events (see Section 2.4) including the "data" payload		change events (see Section 2.4) including the "data" payload
	attribute. This eliminates the need for a callback to retrieve		attribute. This eliminates the need for a callback to retrieve
	additional data.		additional data.
	Event Feed / Event Stream:		Event Feed / Event Stream:
	An Event Feed (or equivalently an Event Stream) is a logical		An event feed (or equivalently an event stream) is a logical
	series of events shared with a unique receiving client. A SET		series of events shared with a unique receiving client. A SET
	transfer (see [RFC8935] and [RFC8936]) Service Provider may offer		transfer (see [RFC8935] and [RFC8936]) service provider may offer
	to allow Event Receivers to "subscribe" to specific event types or		to allow Event Receivers to "subscribe" to specific event types or
	events about specific resources (see Feed Management events in		events about specific resources (see feed events in Section 2.3).
	Section 2.3).
	Event Receiver:		Event Receiver:
	An entity typically receives events as described in [RFC8935] and		An entity typically receives events as described in [RFC8935] and
	[RFC8936] or via HTTP GET (see Section 2.5.1.1). In the case of		[RFC8936] or via HTTP GET (see Section 2.5.1.1). In the case of
	push-based SET delivery [RFC8935], the Event Receiver is an HTTP		push-based SET delivery [RFC8935], the Event Receiver is an HTTP
	endpoint that receives requests. In the case of poll-based SET		endpoint that receives requests. In the case of poll-based SET
	delivery [RFC8936], the receiver is an HTTP client that initiates		delivery [RFC8936], the receiver is an HTTP client that initiates
	HTTP requests to an Event Publisher endpoint.		HTTP requests 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 operation as		be the result of a SCIM Create, Modify, or Delete operation as
	defined in Section 3 of [RFC7644]. A SCIM Service Provider may be		defined in Section 3 of [RFC7644]. A SCIM service provider may be
	an Event Publisher or an independent service that aggregates		an Event Publisher or an independent service that aggregates
	events into Event Receiver feeds. As described above, when using		events into Event Receiver feeds. As described above, when using
	[RFC8935], the Event Publisher is an HTTP client that initiates		[RFC8935], the Event Publisher is an HTTP client that initiates
	HTTP POST requests to a defined Event Receiver endpoint. When		HTTP POST requests to a defined Event Receiver endpoint. When
	using [RFC8936], the Event Publisher provides an HTTP endpoint,		using [RFC8936], the Event Publisher provides an HTTP endpoint,
	which a receiver may use to "poll" for Security Events.		which a receiver may use to "poll" for Security Events.
	SCIM Client:		SCIM Client:
	An HTTP client that initiates SCIM protocol [RFC7644] requests and		An HTTP client that initiates SCIM protocol [RFC7644] requests and
	receives responses that may cause SCIM Events to be issued by the		receives responses that may cause SCIM Events to be issued by the
	SCIM Service Provider. A SCIM Client may also be an Event		SCIM service provider. A SCIM client may also be an Event
	Receiver, typically when making an asynchronous SCIM request (see		Receiver, typically when making an asynchronous SCIM request (see
	Section 2.5.1.1).		Section 2.5.1.1).
	SCIM Service Provider:		SCIM Service Provider:
	An HTTP server that implements the SCIM protocol [RFC7644] and		An HTTP server that implements the SCIM protocol [RFC7644] and
	SCIM schema [RFC7643]. Upon processing a state change to a SCIM		SCIM schema [RFC7643]. Upon processing a state change to a SCIM
	Resource, it 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.
	Security Event Token (SET):		Security Event Token (SET):
	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"
	skipping to change at line 290 ¶		skipping to change at line 289 ¶
	"sub_id" contains the subclaim attribute "format" set to "scim" to		"sub_id" contains the subclaim attribute "format" set to "scim" to
	indicate that 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 that 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 that the relative		provided in a SCIM Event "sub_id" claim. Note that the relative
	path is the path component after the SCIM Service Provider Base		path is the path component after the SCIM service provider Base
	URI as defined in Section 1.3 of [RFC7644]. In cases where the		URI as defined in Section 1.3 of [RFC7644]. In cases where the
	Event Receiver is unable to match a URI, the Event Receiver MAY		Event Receiver is unable to match a URI, the Event Receiver MAY
	issue a callback to a previously agreed SCIM Service Provider Base		issue a callback to a previously agreed SCIM service provider Base
	URI plus the relative "uri" value and perform a SCIM GET request		URI plus the relative "uri" value and perform a SCIM GET request
	per 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		The SCIM "id" attribute (defined in Section 3.1 of [RFC7643]) MAY
	be used for backwards compatibility reasons in addition to the		be used for backwards compatibility reasons in addition to the
	"uri" claim.		"uri" 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 within 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
	the claims, "data" or "attributes", MUST be provided depending on the		the claims, "data" or "attributes", MUST be provided depending on the
	event definition.		event definition.
	txn:		txn:
	A SET-defined claim with a STRING value (see Section 2.2 of		A SET-defined claim with a STRING value (see Section 2.2 of
	[RFC8417]) that uniquely identifies a transaction originating at a		[RFC8417]) that uniquely identifies a transaction originating at a
	SCIM Service Provider and/or its underlying data repository or		SCIM service provider and/or its underlying data repository or
	database where one or more SCIM Events may be subsequently issued.		database where one or more SCIM Events may be subsequently issued.
	In contrast to a "jti" claim (see Section 4.1.7 of [RFC7519]),		In contrast to a "jti" claim (see Section 4.1.7 of [RFC7519]),
	which uniquely identifies a token, the "txn" remains the same when		which uniquely identifies a token, the "txn" remains the same when
	one or more SETs are generated for various purposes such as		one or more SETs are generated for various purposes such as
	retransmission, publication to multiple receivers, etc. A		retransmission, 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 and a common "txn" value. "txn" is REQUIRED to		"jit" values and a common "txn" value. "txn" is REQUIRED to
	support asynchronous SCIM requests, CP, and replication to		support asynchronous SCIM requests, CP, and replication to
	disambiguate or detect duplicate SETs regarding the same		disambiguate or detect duplicate SETs regarding the same
	underlying transaction.		underlying transaction.
	version:		version:
	The ETag version of the resource as a result of the event.		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:
	An event payload attribute that contains information described in		An event payload attribute that contains information described in
	the SCIM Bulk Operations "data" attribute in Section 3.7 of		the SCIM Bulk Operations "data" attribute in Section 3.7 of
	[RFC7644]. The JSON object contains the equivalent SCIM command		[RFC7644]. The JSON object contains the equivalent SCIM command
	processed by the SCIM Service Provider. For example, after		processed by the SCIM service provider. For example, after
	processing a SCIM Create operation, the data contained includes		processing a SCIM Create operation, the data contained includes
	the final representation of the entity created by the SCIM Service		the final representation of the entity created by the SCIM service
	Provider including the assigned "id" value.		provider including the assigned "id" value.
	attributes:		attributes:
	A payload that 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: "attributes":		For example: "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 Coordinated Provisioning		from an event feed or events used in Coordinated Provisioning
	scenarios where only a subset 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 that a resource is new or has been		"feed:add" does not indicate that a resource is new or has been
	recently created. For example, an existing user has had a new role		recently created. For example, an existing user has had a new role
	(e.g., CRM_User) added to their profile, which has caused their		(e.g., CRM_User) added to their profile, which has caused their
	resource to join a feed.		resource to join a feed.
	{		{
	"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",		"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
	"txn": "b7b953f11cc6489bbfb87834747cc4c1",		"txn": "b7b953f11cc6489bbfb87834747cc4c1",
	"sub_id": {		"sub_id": {
	"format": "scim",		"format": "scim",
	skipping to change at line 427 ¶		skipping to change at line 426 ¶
	"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 Coordinated Provisioning (CP) mode. The URI		Replication (DBR) and Coordinated 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".
	When the "data" payload attribute is included for each of the		When the "data" payload attribute is included for each of the
	following events, the event URI MUST end with "full"; otherwise, the		following events, the event URI MUST end with "full"; otherwise, the
	event URI ends with "notice". In "full" mode, the set of values		event URI ends with "notice". In "full" mode, the set of values
	reflecting the final representation of the resource (such as would be		reflecting the final representation of the resource (such as would be
	returned in a SCIM protocol response) at the Service Provider are		returned in a SCIM protocol response) at the service provider are
	provided using the "data" attribute (see Figure 4). In "notice"		provided using the "data" attribute (see Figure 4). In "notice"
	mode, the "attributes" attribute is returned and lists the set of		mode, the "attributes" attribute is returned and lists the set of
	attributes created or modified in the request (see Figure 5).		attributes created or modified in the request (see Figure 5).
	Exactly one of the payload attributes, "data" or "attributes", MUST		Exactly one of the payload attributes, "data" or "attributes", MUST
	be present. Both 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}
	The specified resource indicates that a new SCIM resource has been		The specified resource indicates that a new SCIM resource has been
	created by the SCIM Service Provider and has been added to the Event		created by the SCIM service provider and has been added to the event
	Feed. Note that because the event may be used for replication, the		feed. Note that because the event may be used for replication, the
	"id" attribute that was assigned by the SCIM Service Provider is		"id" attribute that was assigned by the SCIM service provider is
	shared so that all replicas in the domain MAY use the same resource		shared so that all replicas in the domain MAY use the same resource
	identifier.		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"
	skipping to change at line 645 ¶		skipping to change at line 644 ¶
	"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 9: Example SCIM Put Event (Notice)		Figure 9: Example SCIM Put Event (Notice)
	2.4.4. urn:ietf:params:scim:event:prov:delete		2.4.4. urn:ietf:params:scim:event:prov:delete
	The specified resource has been deleted from the SCIM Service		The specified resource has been deleted from the SCIM service
	Provider. The resource is also removed from the feed. When a DELETE		provider. The resource is also removed from the feed. When a DELETE
	is sent, a corresponding "feedRemove" SHALL NOT be issued. A delete		is sent, a corresponding "feedRemove" SHALL NOT be issued. A delete
	event has no payload attributes. Note that because the delete event		event has no payload attributes. Note that because the delete event
	has no attributes, the qualifiers "full" and "notice" SHALL NOT be		has no attributes, the qualifiers "full" and "notice" SHALL NOT be
	used.		used.
	{		{
	"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",		"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
	"sub_id": {		"sub_id": {
	"format": "scim",		"format": "scim",
	"uri": "/Users/2b2f880af6674ac284bae9381673d462",		"uri": "/Users/2b2f880af6674ac284bae9381673d462",
	skipping to change at line 675 ¶		skipping to change at line 674 ¶
	"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 that the account defined by		service provider but may simply indicate that the account defined by
	the SCIM resource is ready for use as agreed upon by the Event		the SCIM resource is ready for use as agreed upon by the Event
	Publisher and Event Receiver. For example, an activated resource can		Publisher and Event Receiver. For example, an activated resource can
	represent 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"
	},		},
	skipping to change at line 708 ¶		skipping to change at line 707 ¶
	2.4.6. urn:ietf:params:scim:event:prov:deactivate		2.4.6. urn:ietf:params:scim:event:prov:deactivate
	The specified resource (e.g., User) has been deactivated and		The specified resource (e.g., User) has been deactivated and
	disabled. The exact meaning SHOULD be agreed to by the Event		disabled. The exact meaning SHOULD be agreed to by the Event
	Publisher and its corresponding Event Receiver. Typically, this		Publisher and its corresponding Event Receiver. Typically, this
	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 the result is delivered to another entity		request is not needed or the result is delivered to another entity
	for further action for coordination reasons.		for further action for coordination 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 returns either a normal SCIM		In response, the SCIM service provider returns either a normal SCIM
	response or HTTP status code 202 (Accepted). The asynchronous		response or HTTP status code 202 (Accepted). The asynchronous
	response MUST contain no response body. To enable correlation of the		response MUST contain no response body. To enable correlation of the
	future event, the HTTP response header "Set-Txn" (see Section 3) is		future event, the HTTP response header "Set-Txn" (see Section 3) is
	returned with a value that MUST match the "txn" claim in a subsequent		returned with a value that MUST match the "txn" claim in a subsequent
	Security Event Token. Per [RFC7240], Section 3, the response will		Security Event Token. Per [RFC7240], Section 3, the response will
	also include the "Preference-Applied" header. The "Location" header		also include the "Preference-Applied" header. The "Location" header
	value MUST be one of the following: (a) a URI where the completion		value MUST be one of the following: (a) a URI where the completion
	SCIM Event Token MAY be retrieved using HTTP GET or (b) the normal		SCIM Event Token MAY be retrieved using HTTP GET or (b) the normal
	SCIM location header response specified by [RFC7644].		SCIM location header response specified by [RFC7644].
	skipping to change at line 770 ¶		skipping to change at line 769 ¶
	"roles":[],		"roles":[],
	"emails":[		"emails":[
	{		{
	"value":"bjensen@example.com"		"value":"bjensen@example.com"
	}		}
	]		]
	}		}
	Figure 12: Example Asynchronous SCIM Protocol Request		Figure 12: Example Asynchronous SCIM Protocol Request
	The SCIM Service Provider responds with HTTP status code 202		The SCIM service provider responds with HTTP status code 202
	(Accepted) and includes the Set-Txn header:		(Accepted) and includes the Set-Txn header:
	HTTP/1.1 202 Accepted		HTTP/1.1 202 Accepted
	Set-Txn: 734f0614e3274f288f93ac74119dcf78		Set-Txn: 734f0614e3274f288f93ac74119dcf78
	Preference-Applied: respond-async		Preference-Applied: respond-async
	Location:		Location:
	"/Users/2819c223-7f76-453a-919d-413861904646"		"/Users/2819c223-7f76-453a-919d-413861904646"
	Figure 13: Async SCIM Request with Prefer Header		Figure 13: Async SCIM Request with Prefer Header
	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
	completion 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
	MAY be generated out of sequence from the original request. In this		MAY be generated out of sequence from the original request. In this
	case, the "txn" claims in those events MUST use operation numbers		case, the "txn" claims in those events MUST use operation 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 of [RFC7644]. In the event,		Response Operation as per Section 3.7.3 of [RFC7644]. In the event,
	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).		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 line 881 ¶		skipping to change at line 880 ¶
	},		},
	"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 four figures show Asynchronous Completion events for		The following four figures show asynchronous completion events for
	the 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":{
	skipping to change at line 985 ¶		skipping to change at line 984 ¶
	}		}
	Figure 19: Example SCIM Asynchronous Response Event Operation (4		Figure 19: Example SCIM Asynchronous Response Event Operation (4
	of 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 code 202 (Accepted) is being returned with no		when HTTP status code 202 (Accepted) is being returned with no
	message body.		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
	Globally Unique Identifier (GUID)) used by the SCIM HTTP client to		Globally Unique Identifier (GUID)) used by the SCIM HTTP client to
	look for a matching SET event with a matching "txn" claim (see		look for a matching SET event with a matching "txn" claim (see
	Section 2 of [RFC8417]) confirming the request completion status as		Section 2 of [RFC8417]) confirming the request completion status as
	described in Section 2.5.1.1.		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		completion is not required. For example, a SCIM client may simply
	not 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, it indicates the SCIM		attribute is OPTIONAL, and when absent, it indicates the SCIM
	Service Provider does not support or is not currently configured		service provider does not support or is not currently configured
	for 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 that 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 that the server completes requests		* "long" indicates that the server completes requests
	asynchronously at the server's discretion (e.g., based on a		asynchronously at the server's discretion (e.g., based on a
	max wait time); and		max wait time); and
	* "request" indicates that 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
	delivering 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
	skipping to change at line 1080 ¶		skipping to change at line 1079 ¶
	Publisher is not communicating directly to the Event Receiver, it may		Publisher is not communicating directly to the Event Receiver, it may
	become possible for an attacker or other system to insert an event.		become possible for an attacker or other system to insert an event.
	To mitigate, Event Receivers MUST verify the originator of a SET		To mitigate, Event Receivers MUST verify the originator of a SET
	using JSON Web Signature (JWS) [RFC7515] signatures when the Event		using JSON Web Signature (JWS) [RFC7515] signatures when the Event
	Publisher is not communicating directly with the Event Receiver.		Publisher is not communicating directly with the Event Receiver.
	Validating event signatures may also be useful for auditing purposes		Validating event signatures may also be useful for auditing purposes
	as signed SET Events are protected from tampering in the event that		as signed SET Events are protected from tampering in the event that
	an intermediate system, such as a TLS-terminating proxy, decrypts the		an intermediate system, such as a TLS-terminating proxy, decrypts the
	SET payload 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 example, 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, which could lead		member values could lead to excessive change rates, which could lead
	to 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 with throughput		To mitigate this risk, consider the following to help with 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
	skipping to change at line 1106 ¶		skipping to change at line 1105 ¶
	* 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. If providing		* Aggregate multiple PATCH Events into a single event. If providing
	the exact date of each membership change is not critical, consider		the exact date of each membership change is not critical, consider
	using a PATCH to aggregate multiple membership changes into a		using a PATCH to aggregate multiple membership changes into a
	single event.		single event.
	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 and requires an HTTP Authorization header or some other		protected and requires an HTTP Authorization header or some other
	form of client authentication.		form of client authentication.
	6. Privacy Considerations		6. Privacy Considerations
	As this specification is based upon the SET specification 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)
	skipping to change at line 1148 ¶		skipping to change at line 1147 ¶
	to share a limited amount of data and/or signals for the benefits		to share a limited amount of data and/or signals for the benefits
	of their users. Depending on end-user consent, information is		of their users. Depending on end-user consent, information is
	shared on an as-authorized and/or as-needed basis. For example,		shared on an as-authorized and/or as-needed basis. For example,
	the domains agree to use CP mode that exchanges things such as		the domains agree to use CP mode that exchanges things such as
	account status or specific minimal attribute information that must		account status or specific minimal attribute information that must
	be fetched on request after receiving notice of a change. This		be fetched on request after receiving notice of a change. This
	enables authorization to be verified each time data is		enables authorization to be verified each time data is
	transferred.		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 carries 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 Set-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
	"Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in		"Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in
	Section 16.3.1 of [RFC9110].		Section 16.3.1 of [RFC9110].
	skipping to change at line 1397 ¶		skipping to change at line 1396 ¶
	1_0.html>.		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 DBR events is to synchronize resource changes		The objective of DBR events is to synchronize resource changes
	between SCIM Service Providers in a common administrative domain. In		between SCIM service providers in a common administrative domain. In
	this mode, complete information about modified resources are shared		this mode, complete information about modified resources are shared
	between replicas for immediate processing.		between replicas for immediate processing.
	+-------------+ +---------------------+ +------------------------+		+-------------+ +---------------------+ +------------------------+
	|SCIM Client A| |SCIM Service Provider| |Service Provider Replica|		|SCIM Client A| |SCIM Service Provider| |Service Provider Replica|
	+-------------+ +---------------------+ +------------------------+		+-------------+ +---------------------+ +------------------------+
	| | |		| | |
	| [1] SCIM Operation | |		| [1] SCIM Operation | |
	|-------------------->| |		|-------------------->| |
	| [2] SCIM Response | |		| [2] SCIM Response | |
	skipping to change at line 1426 ¶		skipping to change at line 1425 ¶
	| | |<-+		| | |<-+
	| | |		| | |
	v v v		v v v
	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 clusters		is to keep individual service provider nodes or clusters
	synchronized.		synchronized.
	A.2. Coordinated Provisioning		A.2. Coordinated Provisioning
	In CP, SCIM resource change events perform the function of change		In CP, SCIM resource change events perform the function of change
	notification without the need to provide raw data. In any Event		notification without the need to provide raw data. In any Event
	Publisher and Receiver relationship, the set of SCIM Resources (e.g.,		Publisher and Receiver relationship, the set of SCIM resources (e.g.,
	Users) that are linked or coordinated is managed within the context		Users) that are linked or coordinated is managed within the context
	of an event feed and may be a subset of the total set of resources on		of an event feed and may be a subset of the total set of resources on
	either side. For example, an event feed could be limited to users		either side. For example, an event feed could be limited to users
	who have consented to the sharing of information between domains. To		who have consented to the sharing of information between domains. To
	support capability, "feed" specific events are defined to indicate		support capability, "feed" specific events are defined to indicate
	the addition and removal of SCIM Resources from a feed. For example,		the addition and removal of SCIM resources from a feed. For example,
	when a user consents to the sharing of information between domains,		when a user consents to the sharing of information between domains,
	events about the User may be added to the feed between the Event		events about the User may be added to the feed between the Event
	Publisher and Receiver.		Publisher and Receiver.
	+-----------+ +---------------+ +-----------------+ +---------------+		+-----------+ +---------------+ +-----------------+ +---------------+
	|SCIM Client| | SCIM Service | | Event Receiver | | Co-op Action |		|SCIM Client| | SCIM Service | | Event Receiver | | Coord. Action |
	| | | Provider | | | | Endpoint |		| | | Provider | | | | Endpoint |
	+-----------+ +---------------+ +-----------------+ +---------------+		+-----------+ +---------------+ +-----------------+ +---------------+
	| | | |		| | | |
	| [1] SCIM | | |		| [1] SCIM | | |
	| Operation | | |		| Operation | | |
	|--------------->| | |		|--------------->| | |
	| | | |		| | | |
	| [2] SCIM | | |		| [2] SCIM | | |
	| Response | | |		| Response | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
			| +=== loop ==========+===================+
			| | | |
	| | [3] Event | |		| | [3] Event | |
	| | SCIM:prov:<op> | |		| | SCIM:prov:<op> | |
	| | id:xyz | |		| | id:xyz | |
	| |- - - - - - - - - >| |		| |- - - - - - - - - >| |
	| | | |		| | | |
	| | | Note: Receiver |		| | | Note: Receiver |
	| | | may accumulate |		| | | may accumulate |
	| | | events for |		| | | events for |
	| | | periodic action. |		| | | periodic action. |
	| | | |		| | | |
	skipping to change at line 1479 ¶		skipping to change at line 1480 ¶
	| | | |		| | | |
	| | [5] Filtered | |		| | [5] Filtered | |
	| | Resource | |		| | Resource | |
	| | Response | |		| | Response | |
	| |------------------>| |		| |------------------>| |
	| | | |		| | | |
	| | | [6] Coordinated |		| | | [6] Coordinated |
	| | | Action |		| | | Action |
	| | |------------------>|		| | |------------------>|
	| | | |		| | | |
			| +=== end loop ======+===================+
	v v v v		v v v v
	Figure 21: Coordinated Provisioning Sequence		Figure 21: Coordinated 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.
	CP 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
	skipping to change at line 1519 ¶		skipping to change at line 1521 ¶
	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		For example, in a cross-domain scenario, a SCIM service provider
	would 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
End of changes. 61 change blocks.
	73 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.48.