rfc-9967

System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)

P. Hunt (Editor), N. Cam-Winget, M. Kiser, J. Schreiber
date2026-05 streamIETF areasec wgscim statusPROPOSED STANDARD pages33 canonicalhttps://www.rfc-editor.org/rfc/rfc9967 doi10.17487/RFC9967
This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token (SET) specification (RFC 8417) to enable the asynchronous exchange of messages between SCIM service providers and receivers. This specification updates RFC 7643 by defining additional attributes for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema, and it updates RFC 7644 with an optional new asynchronous SCIM request capability.

updates

Extracted elements (29)

design-rationale §2.5.1.2

The asynchronous bulk txn claim format (base-txn:index) was chosen over 'bulkId' because bulkId is a temporary identifier not required on every operation, whereas zero-based array index maps deterministically back to the original request ordering even when the service provider optimizes operation sequence.

http, security

design-rationale §2.4

The 'notice' vs 'full' event mode duality was designed to support two distinct deployment patterns: Domain-Based Replication (DBR) uses 'full' to replicate complete resource state without callbacks, while Coordinated Provisioning (CP) uses 'notice' to minimize data shared in transit and requires the receiver to call back for data, enabling per-receiver access control.

security, privacy

design-rationale §2.1

The 'sub' JWT claim was prohibited for SCIM events to prevent confusion with JWT authorization tokens, a risk noted in RFC 8417 Section 3. Using a structured 'sub_id' with format='scim' avoids ambiguity and provides richer identification including SCIM-specific attributes.

security, json

design-rationale §2.2

The 'txn' claim was introduced distinct from 'jti' because 'jti' uniquely identifies a token whereas 'txn' identifies an underlying transaction — the same transaction can produce multiple SETs (e.g., for retransmission or multiple receivers) that all share the same 'txn' value, enabling deduplication in CP and async scenarios.

security, json

interoperability-note §7.3

The SCIM Event URIs registry uses Expert Review to ensure new registrations are relevant to SCIM-based systems and avoid conflict with other event definitions outside SCIM, specifically including the OpenID Shared Signals Framework (SSF).

registry, security

interoperability-note §5

This specification is fully compatible with both push-based (RFC 8935) and poll-based (RFC 8936) SET delivery mechanisms. Event Receivers may also retrieve async completion events via HTTP GET. The security and privacy considerations of RFC 8417, RFC 8935, and RFC 8936 all apply.

http, security

normative-requirement §5 MUST

Access to event recovery and forwarding systems MUST be limited to parties needed for recovery or SET forwarding, to prevent attackers from leveraging transaction or signal information.

security

normative-requirement §5 MUST

Event Receivers MUST verify the originator of a SET using JSON Web Signature (JWS) signatures when the Event Publisher is not communicating directly with the Event Receiver, to prevent insertion of forged events by intermediaries.

security, crypto

normative-requirement §2.5.1.2 MUST

For asynchronous bulk requests, a single Asynchronous Request Completion Event MUST be generated for each requested operation. The 'txn' claim MUST be set to the original value appended with ':' and the zero-based array index of the operation.

http, security

normative-requirement §2.4 MUST

For provisioning events, exactly one of the payload attributes 'data' or 'attributes' MUST be present; both MUST NOT be present simultaneously. When 'data' is included the event URI MUST end with 'full'; otherwise it ends with 'notice'.

security, json

normative-requirement §2.1 MUST

SCIM Events MUST use the 'sub_id' claim defined by RFC 9493 to 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 event payload within the 'events' claim.

security, json

normative-requirement §5 MUST

SETs containing sensitive information including PII MUST be protected using TLS (BCP 195) in transit. Event Receivers MUST ensure events are persisted to meet local recovery needs before acknowledging receipt.

tls, security, privacy

normative-requirement §2.1 MUST NOT

The JWT 'sub' claim MUST NOT be used to identify subjects in SCIM Events, to prevent confusion with JWT authorization tokens. Instead, the top-level claim 'sub_id' SHALL be used with 'format' set to 'scim'.

security, json

normative-requirement §2.5.1.1 MUST

The 'Set-Txn' HTTP response header value MUST match the 'txn' claim in a subsequent Security Event Token confirming async request completion. The 'Location' header MUST be either a URI where the completion event MAY be retrieved or the normal SCIM location.

http, security

normative-requirement §2.1 MUST

The 'uri' attribute MUST be provided in a SCIM Event 'sub_id' claim, containing the SCIM relative path for the resource (e.g., '/Users/2b2f880af6674ac284bae9381673d462').

security, json

normative-requirement §5 MUST

The URI endpoint for async operation results MUST be protected and requires an HTTP Authorization header or other client authentication, to prevent unauthorized access to Asynchronous Request Completion Event information.

security, http

normative-requirement §2.5.1.1 MUST

To initiate an asynchronous SCIM request, the HTTP 'Prefer' header is set to 'respond-async'. The HTTP 'Accept' header MUST be ignored for purposes of an asynchronous response, and the asynchronous response MUST contain no response body.

http, security

normative-requirement §2.4.4 SHALL NOT

When a DELETE event (urn:ietf:params:scim:event:prov:delete) is sent, a corresponding 'feedRemove' event SHALL NOT be issued. A delete event has no payload attributes and the 'full'/'notice' qualifiers SHALL NOT be used.

security

privacy-consideration §6

Cross-domain SCIM event sharing operates under two scenarios: a common administrative domain (e.g., DBR mode keeping employee data synchronized) or a cooperative relationship (e.g., CP mode with consent-based, minimal data sharing). The specification states that sharing generally carries no additional personal information beyond the existing SCIM relationship.

privacy, security

protocol-element §2

A SCIM Event is a Security Event Token (SET) containing standard JWT top-level claims and an 'events' claim with event URI subclaims. All events use the URI prefix 'urn:ietf:params:scim:event' with sub-namespaces 'feed' (feed control) or 'prov' (provisioning).

security, json

protocol-element §2.2

Common event attributes defined for all events: 'txn' (transaction identifier, a STRING that remains constant across multiple SETs for the same transaction), 'version' (ETag of the resource post-event), 'data' (full SCIM bulk operation representation), and 'attributes' (array of modified attribute names).

security, json

protocol-element §4

The 'securityEvents' ServiceProviderConfig attribute allows clients to discover async event capabilities. Sub-attributes include 'asyncRequest' (values: 'none', 'long', 'request') and 'eventUris' (multivalued list of SET Event URIs the server can generate).

security, json

protocol-element §2.1

The 'sub_id' object for SCIM events contains: 'format' (set to 'scim'), 'uri' (REQUIRED SCIM relative path), 'externalId' (OPTIONAL cross-domain identifier), and 'id' (OPTIONAL for backwards compatibility). Additional uniqueness-scoped SCIM attributes MAY also be included.

security, json

protocol-element §2.5.1.3

The urn:ietf:params:scim:event:misc:asyncresp event signals completion of an asynchronous SCIM request. Its payload contains 'method', 'version', 'status', and optionally 'bulkId'; on error it MUST include a 'response' attribute with non-200-series HTTP status and error sub-attributes.

security, http, json

registry §7.3

IANA created the 'SCIM Event URIs' registry under the SCIM Schema URIs registry group, with Expert Review procedure. Event URI structure is 'urn:ietf:params:scim:event:{class}:{name}:{other}' where class is 'feed', 'prov', or 'misc'. Once allocated, names MUST NOT be reallocated.

registry, security

registry §7.1

IANA registered the HTTP 'Set-Txn' field name in the HTTP Field Name Registry (RFC 9110 Section 16.3.1) with permanent status, referencing Section 3 of RFC 9967.

registry, http

registry §7.4

Initial SCIM Event URIs registry entries include 12 events: feed:add, feed:remove, prov:create:notice, prov:create:full, prov:patch:notice, prov:patch:full, prov:put:notice, prov:put:full, prov:delete, prov:activate, prov:deactivate, and misc:asyncresp.

registry, security

security-consideration §5

High-rate SCIM resources (e.g., Groups with thousands of members) can cause excessive change rates leading to loss of SET Events. Mitigations include preferring SCIM PATCH over PUT for large groups, using notice-mode events with periodic GETs, and aggregating multiple PATCH events into a single event.

security

wire-format §3

The 'Set-Txn' HTTP response header field carries a unique STRING (e.g., a GUID) that the SCIM client uses to correlate a 202 Accepted response with a future SET event's 'txn' claim. Intermediaries SHOULD NOT insert, modify, or delete the field's value.

http, security