SCIM User Supersession and Identity Resolution Correction Events

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SCIM [RFC7643] [RFC7644] provides a common model and protocol for provisioning identity resources. RFC 9967 [RFC9967] defines SCIM events using Security Event Tokens (SETs) [RFC8417], including standardized provisioning events for resource creation, modification, deletion, activation, and deactivation.¶

Identity-resolution systems sometimes determine that two existing SCIM User resources represent the same subject within the service provider's authority. The provider may choose one User as the surviving authoritative resource and retire the other. This document calls that transition supersession.¶

Consider two User resources, /Users/A and /Users/B. After an identity-resolution decision, the provider retires A in favor of B. A downstream receiver may hold references or local mappings keyed by A. An RFC 9967 delete event for A communicates that A was deleted, but it does not communicate that B is the successor representation selected by the provider.¶

These cases have materially different semantics:¶

A deleted
  -> the resource is no longer present.

A superseded by B
  -> A is retired, and B is the provider's surviving
     representation for the subject previously represented by A.

The distinction matters because a receiver may need to preserve referential continuity. A supersession signal does not, by itself, define the resulting attributes of the successor User and MUST NOT be interpreted as an instruction to blindly copy or union all attributes from the superseded User into the successor.¶

A second problem occurs when a supersession decision is later found to be incorrect. Shared identifiers, recycled phone numbers, incorrectly interpreted source data, administrative mistakes, or other resolution errors can cause distinct subjects to be collapsed. The source of truth may be able to correct the decision, but downstream receivers need an interoperable signal identifying the earlier supersession that is no longer valid.¶

This document therefore defines two SCIM provisioning events: urn:ietf:params:scim:event:prov:supersede and urn:ietf:params:scim:event:prov:supersession-correction. The first identifies the retired User and its successor. The second invalidates a specified earlier supersession and identifies the resource that now represents the subject that had been retired.¶

A related class of identity-resolution transitions occurs when a representation exists before a SCIM User is established, such as a pseudonymous application profile associated with a browser, device context, or locally scoped identifier. Such representations may later be associated with an authenticated User. This is an important interoperability problem, but defining a Profile ResourceType or profile-linking events is intentionally outside the normative scope of this document. Appendix A discusses this related work.¶

2. Conventions and Terminology

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶

Publisher

A SCIM event publisher as defined by RFC 9967 that asserts a supersession or correction within its authority.¶

Receiver

An authorized recipient of a SCIM event that may maintain references to, or derived state about, the affected Users.¶

Subject

The person or other entity that the publisher considers represented by a User resource. "Same subject" in this document means the publisher's identity-resolution determination and does not imply a global identifier or universally verifiable real-world identity.¶

Superseded User

The User resource retired by a supersession decision.¶

Successor User

The User resource selected by the publisher as the surviving representation after a supersession decision.¶

Supersession

A transition in which one User resource is retired in favor of another existing User resource within the same SCIM authority.¶

Supersession Correction

A later authoritative decision invalidating a specified earlier supersession.¶

Transition Identifier

A stable, issuer-scoped opaque identifier for an underlying supersession or correction decision. It is distinct from the jti of an individual SET carrying that decision.¶

3. Use Cases and Requirements

4. Resolution Model

The events defined by this document describe resource identity lifecycle decisions. They do not encode an attribute merge algorithm.¶

A provider MAY use any internal process to determine that one User supersedes another. That process is outside the scope of this document. The event asserts only the provider's resulting state transition.¶

The source and target resources of a supersession MUST be distinct SCIM User resources within the same SCIM authority. Cross-provider supersession is out of scope for this version.¶

The publisher MAY issue ordinary RFC 9967 create, patch, put, deactivate, or delete events in addition to the events defined here. A later delete event does not replace the supersession event because deletion alone does not identify a successor.¶

A correction invalidates a specified supersession decision for future processing. If the correction changes the authoritative SCIM-visible state of any affected User, those state changes are communicated separately using the ordinary SCIM protocol and applicable RFC 9967 provisioning events.¶

5. Identity Attribute Convergence

Identity resolution can affect both resource identity and the authoritative identity attributes exposed by the SCIM service provider. When User A is superseded by User B, the provider may determine a new authoritative SCIM-visible state for B using attributes previously associated with A, attributes already present on B, and other authoritative sources.¶

Identity attribute convergence is not necessarily a union or copy operation. The provider MAY retain, discard, transform, or select among conflicting attribute values according to local policy, schema constraints, attribute mutability, source authority, or other implementation-specific rules. This document does not standardize those rules.¶

The supersession event communicates only the resource relationship: A has been retired in favor of B. If identity attribute convergence changes the SCIM representation of B, the publisher MUST expose the resulting authoritative state through the normal SCIM protocol. When RFC 9967 event delivery is used, the publisher SHOULD also emit the applicable patch or put provisioning event for B, using the notice or full form as appropriate.¶

For example, A may contain a phone number while B contains a verified email address. After resolution, the provider may decide that B should contain both values, only one of them, or another authoritative value. The supersession event does not encode that decision; the resulting SCIM representation of B does.¶

If a later supersession correction changes the authoritative SCIM-visible state of the affected Users, the publisher SHOULD communicate those changes using ordinary SCIM PATCH or PUT operations and, when applicable, the corresponding RFC 9967 events.¶

This document makes no statement about convergence of non-SCIM application, behavioral, transactional, or customer data. Such data is outside the scope of SCIM and this specification.¶

6. SCIM Supersession Events

{
  "iss": "https://id.example.org/scim/v2",
  "aud": "https://receiver.example.net/events",
  "iat": 1791504000,
  "jti": "set-001",
  "txn": "txn-725",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/u-old"
  },
  "events": {
    "urn:ietf:params:scim:event:prov:supersede": {
      "transitionId": "resolution-725",
      "successor": {
        "format": "scim",
        "uri": "/Users/u-219"
      }
    }
  }
}

{
  "iss": "https://id.example.org/scim/v2",
  "aud": "https://receiver.example.net/events",
  "iat": 1791590400,
  "jti": "set-002",
  "txn": "txn-901",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/u-restored"
  },
  "events": {
    "urn:ietf:params:scim:event:prov:supersession-correction": {
      "transitionId": "resolution-901",
      "reverses": "resolution-725",
      "superseded": {
        "format": "scim",
        "uri": "/Users/u-old"
      },
      "previousSuccessor": {
        "format": "scim",
        "uri": "/Users/u-219"
      }
    }
  }
}

7. Receiver Processing and Reconciliation

A receiver MUST validate the SET, including the issuer, audience, integrity protection, and replay protections applicable to the deployment, before applying either event.¶

A receiver MUST scope sub_id, successor, superseded, and previousSuccessor to the authenticated issuer and the authorized SCIM service-provider namespace. An externalId, email address, phone number, username, or other attribute MUST NOT by itself establish cross-authority equivalence.¶

A receiver SHOULD deduplicate underlying identity-resolution transitions using the pair of issuer and transitionId, rather than treating every SET with a new jti as a distinct supersession decision.¶

After accepting a supersession event, a receiver MAY update local references from the superseded User to the successor when such reconciliation is appropriate. It MUST NOT infer the successor's attribute values from the supersession event; the authoritative SCIM state is obtained through normal SCIM resource retrieval or provisioning updates.¶

When a receiver changes local references or identity mappings because of a supersession, it SHOULD retain enough lineage to associate those changes with the issuer and transitionId.¶

After accepting a supersession-correction event, a receiver MUST stop treating the invalidated supersession as current evidence that the two User resources represent the same subject. The receiver SHOULD identify locally applied effects associated with the transition identified by the "reverses" value and reconcile them according to local policy and retained lineage.¶

If the receiver has not observed the transition identified by reverses, it MUST NOT invent the missing prior state. It SHOULD request an authorized resynchronization, retrieve current SCIM state where appropriate, or mark the affected identity mappings as requiring reconciliation.¶

The correction event does not itself reconstruct previous SCIM attribute values or local identity mappings. Receivers SHOULD use the provider's current authoritative SCIM state and retained transition lineage when reconciling a correction.¶

8. Security Considerations

A forged supersession event could redirect references or account associations from one User to another. A forged correction could similarly disrupt legitimate identity continuity. Publishers and receivers MUST apply the authentication, integrity, audience validation, and replay protections required by SETs [RFC8417], RFC 9493, RFC 9967, and the chosen event transport.¶

Receivers MUST authorize the publisher to assert supersession for the named resources. They MUST reject references that cross unauthorized tenant or authority boundaries.¶

A supersession event does not carry credential-transfer semantics. Receivers MUST NOT use it alone to transfer passwords, authenticators, recovery factors, authorization grants, entitlements, privileged roles, or other security-sensitive state.¶

Publishers SHOULD avoid including raw identity-resolution evidence in event payloads. Shared identifiers such as email addresses or phone numbers can be ambiguous or recycled and may expose sensitive information. The event communicates the publisher's lifecycle decision, not the raw evidence used to make it.¶

Duplicate, delayed, or out-of-order event delivery is possible. Receivers SHOULD retain transition identifiers and enough state to detect replays and later corrections. If required history is unavailable, the receiver SHOULD fail safely and reconcile with the authoritative provider rather than infer identity equivalence.¶

9. Privacy Considerations

Identity supersession creates correlation between two identity records and can therefore have substantial privacy consequences. Privacy analysis should follow the guidance in [RFC6973].¶

A receiver MUST NOT infer that all attributes from the superseded User become attributes of the successor. Attribute convergence is determined by the publisher and reflected in the authoritative SCIM state of the affected resources.¶

Incorrect supersession can cause identity attributes to be associated with the wrong subject. A later correction may stop future misuse but cannot necessarily undo disclosure that has already occurred. Publishers SHOULD preserve sufficient internal provenance to support correction of authoritative SCIM state.¶

Publishers SHOULD minimize the audience of supersession events and SHOULD avoid embedding raw matching identifiers or detailed resolution evidence in the event payload.¶

10. IANA Considerations

The "SCIM Event URIs" registry uses the Expert Review registration procedure defined by RFC 9967. The registrations requested here remain proposals until IANA action is completed.¶

The event URIs in this section are proposed registrations. They are not existing IANA allocations.¶

If this document is published as an RFC, IANA is requested to add the following entries to the "SCIM Event URIs" registry created by [RFC9967].¶

Event URI

urn:ietf:params:scim:event:prov:supersede¶

Descriptive name

SCIM User Superseded Event¶

Reference

Section Section 6.2 of this document.¶

Event URI

urn:ietf:params:scim:event:prov:supersession-correction¶

Descriptive name

SCIM User Supersession Correction Event¶

Reference

Section Section 6.3 of this document.¶

No new SCIM schema URI, ResourceType, OAuth scope, or Security Event Subject Identifier format is requested by this document.¶

11. Open Issues for Community Review

The author particularly requests feedback on the following issues:¶

1. Event naming: Is "supersede" the clearest lifecycle term? For the correction event, should the URI remain "urn:ietf:params:scim:event:prov:supersession-correction", use an RFC 9967-style qualifier such as "urn:ietf:params:scim:event:prov:supersede:correction", or use another term?¶

2. Identity attribute convergence: Is the separation between resource supersession and convergence of SCIM-visible identity attributes sufficiently clear, and is relying on ordinary RFC 9967 patch/put events for the resulting SCIM state the right interoperability boundary?¶

3. Persistent state: Should a future SCIM extension expose current supersession state on a User resource for receivers that join after event history has expired?¶

4. Correction payload: Is identifying superseded, previousSuccessor, and the current User in sub_id sufficient for reconciliation without defining attribute-level provenance metadata in this document?¶

5. Transition identifier: Is a dedicated transitionId appropriate, or should an existing SET/SCIM identifier be reused for correction references?¶

6. Resource scope: Should supersession remain limited to User-to-User transitions, or should the event eventually apply to arbitrary SCIM resource types?¶

7. Related profile work: Should pre-authentication/pseudonymous Profile linkage be pursued as a separate SCIM ResourceType/event document, or is that problem better addressed outside SCIM?¶

12. Pre-Authentication and Pseudonymous Profiles (Informative)

Identity resolution is not limited to deduplicating two established Users. Applications increasingly maintain representations that exist before a SCIM User account or authenticated identity relationship has been established.¶

Examples include records associated with:¶

• a browser- or application-scoped visitor identifier;¶

• a device context;¶

• a locally assigned pseudonymous identifier;¶

• a pre-registration journey; or¶

• an application profile that intentionally remains distinct from an account resource.¶

A later authentication or verification step may establish an association between such a representation and a SCIM User:¶

Pre-authentication representation P
              |
              | identity resolution / association
              v
          SCIM User U

This is related to User supersession because both cases communicate an identity-resolution relationship that cannot be inferred reliably from ordinary SCIM CRUD operations. However, the resource semantics are different. A pre-authentication representation is not necessarily a User, and associating it with a User does not necessarily mean that the representation should disappear or that all of its attributes become attributes of the User.¶

A future specification could explore a dedicated SCIM Profile ResourceType and explicit link/unlink semantics. [RFC9944] provides precedent for introducing a specialized SCIM ResourceType when an entity should not be modeled as a User.¶

Such work would need to answer at least the following questions before standardization:¶

• What minimum semantics distinguish a Profile from a User?¶

• May multiple Profiles be linked to one User?¶

• May one Profile represent a shared context rather than a single subject?¶

• How are link and unlink operations authorized?¶

• What provenance must survive a later unlink or correction?¶

• How should correlation, consent, and purpose limitation be protected?¶

This document intentionally does not allocate a Profile schema URI, /Profiles endpoint, or profile-linking event URI. Keeping those concepts out of the normative -00 allows the SCIM community to evaluate the narrower supersession problem independently while preserving the broader identity-resolution use case for future work.¶

Author's Address