Summary

  • RFC 9967, co-authored by Nancy Cam-Winget, defines SCIM security events carried in SETs. A SET says that a state change occurred at a SCIM service provider; an Event Receiver chooses its own local follow-up rather than treating the event as a command.
  • An asynchronous Set-Txn value links a 202 Accepted response to a later event’s txn claim. That correlation, an event’s persistence, or an included resource shape is not a receipt that the receiver matched, reconciled, acted on, or currently holds the same state.

The dangerous phrase in asynchronous identity automation is often completed. A caller receives 202 Accepted, sees a Set-Txn header and later finds a SET with the same txn. It is tempting to compress that sequence into one reassuring sentence: the change completed everywhere. RFC 9967 does not say that, and its careful wording explains why.

RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), frames a SET as information about a state change that has occurred at a SCIM service provider. That is a valuable fact. It lets a provider publish a change into an asynchronous channel instead of requiring every dependent receiver to poll blindly. Yet the next sentence is the boundary that matters: receivers determine the best local follow-up action in their own context rather than interpreting SETs as commands. The RFC gives schema and resource-type reconciliation between domains as its example.

That example is not decorative. A provider and receiver can use different resource identifiers, data models, lifecycle names or local rules. A receiver may recognize the URI in an event and update an internal representation. It may decide that the event names no local resource. It may need to use the agreed provider base URI and perform a SCIM GET, an option RFC 9967 expressly permits when it cannot match the URI. Or it may preserve the event for recovery while a separate local process evaluates it. The provider-side change is real without automatically becoming a receiver-side outcome.

The asynchronous correlation field is similarly narrow. When a SCIM client asks for an asynchronous response, RFC 9967 requires 202 Accepted, no response body and a Set-Txn header. Its value must match the txn claim in a subsequent SET, allowing the client to look for the corresponding completion event. This is an excellent audit join: it connects a request accepted for asynchronous processing with a later statement from the provider. It is not a global receipt. The RFC distinguishes txn from jti: jti identifies an individual token, while a txn can remain the same across retransmission or publication to multiple receivers. A matching value tells a reviewer what was correlated, not which receiver reconciled what.

The event payload also resists over-reading. Exactly one of data or attributes may appear. data carries a representation after the transaction; attributes identifies attributes created or modified. A full representation can still require a receiver’s mapping and policy. A changed-attribute notice can still require a retrieval. Neither declares that a receiver accepted the representation, that an entitlement was enforced, or that a downstream system now agrees. Those are distinct observations under the receiver’s control.

Persistence is an equally important but different join. RFC 9967 requires Event Receivers to ensure events are persisted directly or indirectly for their local recovery needs before acknowledging them. That rule protects a long-lived event stream against momentary delivery failures and retries. It is a recovery discipline, not an action receipt. A durable inbox may honestly prove that a receiver retained an event; it does not prove that a match succeeded, that a human or policy engine approved a change, or that the current local resource equals the provider’s representation.

This is a Running-Code Primacy problem in miniature. A protocol artifact should be allowed to prove exactly the state transition it exposes. An accepted request, a correlation token, a received SET, a token identifier, a durable event record, a local match, a callback result, a policy decision and observed receiver state are separate pieces of evidence. Combining their labels into a dashboard word such as synchronized hides the very failure surface that operators later need to inspect.

The stronger practice is neither to distrust RFC 9967 nor to demand a single central decision. It is to keep authority where the consequence lies. The SCIM service provider reports its change. The receiver decides how to interpret and use that information within its own model. A relying organisation defines what must be reconciled before an automated workflow can have an external effect. The resulting record can say precisely which part of the path occurred and which part remains unknown.

Sources