Summary

  • RFC 9967 gives asynchronous SCIM requests a traceable hand-off: a bodyless 202 response can carry Set-Txn, and a later Security Event Token carries the matching txn for the underlying transaction.
  • The correlation is evidence about an accepted request and a reported outcome. It does not prove that the receiving domain accepts the subject mapping, applies the change, issues a credential, alters a role or grants service access.
  • A sound operating chain keeps request acceptance, event validation, reconciliation, local entitlement, observed effect and reversal separately visible.

A receipt explains which work to look for

RFC 9967 fills a real operational gap in SCIM. A client can ask a provider to perform a POST, PUT, PATCH or DELETE asynchronously by using Prefer: respond-async. The provider may complete normally, or may return a 202 response with no message body. In the latter case, the response includes Set-Txn; a later SCIM Security Event Token, or SET, uses the same txn value to identify the underlying transaction.

That is a useful correlation surface. The transaction value stays with the underlying work even when tokens are retransmitted or sent to more than one receiver, while a token identifier concerns a particular token. Operations teams can therefore distinguish “another delivery of the same underlying event” from “a separate state change”. A client that needs completion evidence has a defined value to match rather than a vague promise that a background job eventually ran.

Yet a matching value says less than its apparent neatness suggests. It can connect an acceptance record to a reported completion record. It cannot determine whether the receiver matched the incoming subject to the intended local record, whether the remote change fits a local contract, whether a local role change is allowed, or whether any downstream system actually took effect. Correlation makes a question auditable; it does not answer every question attached to the transaction.

The event is a signal, not a remote command

The RFC states the boundary directly: a SET conveys information about a state change at a SCIM service provider, and the Event Receiver can decide the best local follow-up action in its own context. That wording is not a loophole. It is the architecture. Domains can have different schemas, resource types, retention duties, service boundaries and recovery obligations. A portable event cannot reliably pre-choose the accountable decision for all of them.

The design makes the information boundary concrete. Provisioning events can use a full form, carrying the provider’s final resource representation in data, or a notice form, which lists the changed attributes. With notice, a receiver may fetch information under an already agreed SCIM relationship. Full can reduce a later fetch; notice can limit disclosure and leave reconciliation to a controlled retrieval. Neither form means “apply this remote state without review.”

Subject handling has the same restraint. RFC 9967 requires sub_id for a SCIM event’s subject and does not use the ordinary JWT sub claim for that purpose. The field helps a receiver know what the sender intended to identify. It does not dissolve a receiver’s own ambiguity: a local account may be merged, suspended, reassigned, governed by a different identifier or deliberately excluded from the feed. A well formed identifier is evidence for matching, not a universal verdict about equivalence.

Completion can include an error, a delay or a different local outcome

The 202 pattern is especially prone to false closure. It means the provider accepted asynchronous handling, not that the entire multi-domain consequence has settled. RFC 9967 allows later asynchronous response events to describe successful operations and error outcomes. A client may also ignore Set-Txn when it does not need confirmation. Capability discovery is optional: a missing security-events capability can mean the provider does not support it or is not currently configured for it.

Those details argue for a precise record chain rather than a single green status:

  1. The request record identifies who asked the provider to change which SCIM resource, under which local authorization and expected precondition.
  2. The provider record captures acceptance or synchronous completion. For an asynchronous path it retains the 202 response and its Set-Txn value.
  3. The event-delivery record captures the received SET, its issuer and audience checks, validation outcome, event type, txn, time and any delivery retry.
  4. The reconciliation record explains how the receiver mapped sub_id, interpreted full or notice content, fetched any agreed additional data and handled schema or version differences.
  5. The local-decision record names the rule and owner that accepted, deferred, rejected or constrained the requested local effect.
  6. The observed-effect and reversal records show what actually changed downstream and how it can be corrected without rewriting the earlier evidence.

Each record can be healthy while the next is refused. A provider can complete a change, a receiver can validate the event, and a local policy can still deny a privileged group assignment. That is not a broken integration. It is evidence that the receiver has retained responsibility for the consequences it alone has to operate.

Transport and format do not allocate authority

SET delivery can be push-based or poll-based. The two RFCs defining those patterns describe different reachability and operational prerequisites; they do not choose the receiver’s authorization policy. Likewise, a full event may be appropriate in a tightly administered replication relationship, while a notice-plus-retrieval approach can be more suitable where the receiver wants to minimize transferred data and reassess each change. The protocol supplies structured options, not a universal instruction to copy a remote directory into every local service.

The same holds for a transaction marker. Intermediaries should not insert, modify or delete Set-Txn, because corrupting correlation harms traceability. That does not make an intermediary, a publisher or a feed owner the final authority over a receiving system’s memberships, credentials or access scope. The shared layer protects the integrity of the hand-off; the decision remains where its operational risk lands.

This is the useful reading of the Heng Lu note. Specify the common fact narrowly enough that parties can exchange it: an asynchronous SCIM request was accepted, and this event reports an outcome for the same transaction. Leave the choice to map, authorize, delay, reverse or escalate the local effect with the party that can explain and repair it.