System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)
updates
Extracted elements (29)
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.
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.
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.
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.
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).
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.
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.
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.
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.
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'.
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.
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.
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'.
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.
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').
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.
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.
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.
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.
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).
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).
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).
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.
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.
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.
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.
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.
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.
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.