System for Cross-domain Identity Management (SCIM) Vivek Internet-Draft 15 October 2026 Intended status: Standards Track Expires: 18 April 2027 SCIM User Supersession and Identity Resolution Correction Events draft-vivek-scim-user-supersession-00 Abstract The System for Cross-domain Identity Management (SCIM) defines resources, provisioning operations, and Security Event Token (SET) based events for resource lifecycle changes. Existing standardized SCIM events can signal that a User resource was created, modified, activated, deactivated, or deleted, but they do not express an identity-resolution decision in which one User resource is retired in favor of another User resource representing the same subject within the issuer's authority. Deletion and supersession have different semantics for downstream systems. This document defines two SCIM provisioning events: a User supersession event and a supersession- correction event. It distinguishes resource supersession from identity-attribute convergence and specifies how ordinary SCIM provisioning events communicate the resulting authoritative SCIM state of the surviving User. Matching algorithms, attribute- convergence and conflict-resolution policy, identity proofing, and non-SCIM data handling remain outside the scope of this document. Pre-authentication and pseudonymous profile linkage is identified as related future work but is not standardized by this document. 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. Vivek Expires 18 April 2027 [Page 1] Internet-Draft SCIM User Supersession October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5 3.1. User Supersession . . . . . . . . . . . . . . . . . . . . 5 3.2. Correction of an Incorrect Supersession . . . . . . . . . 5 3.3. Minimum Requirements . . . . . . . . . . . . . . . . . . 6 4. Resolution Model . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Transition Identifiers . . . . . . . . . . . . . . . . . 7 5. Identity Attribute Convergence . . . . . . . . . . . . . . . 8 6. SCIM Supersession Events . . . . . . . . . . . . . . . . . . 8 6.1. Common SET Requirements . . . . . . . . . . . . . . . . . 8 6.2. Supersession Event . . . . . . . . . . . . . . . . . . . 9 6.3. Supersession Correction Event . . . . . . . . . . . . . . 10 7. Receiver Processing and Reconciliation . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Open Issues for Community Review . . . . . . . . . . . . . . 15 12. Pre-Authentication and Pseudonymous Profiles (Informative) . 16 13. Normative References . . . . . . . . . . . . . . . . . . . . 17 14. Informative References . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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. Vivek Expires 18 April 2027 [Page 2] Internet-Draft SCIM User Supersession October 2026 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 Vivek Expires 18 April 2027 [Page 3] Internet-Draft SCIM User Supersession October 2026 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. 1.1. Goals * Distinguish User supersession from ordinary User deletion. * Identify the surviving User resource selected by the publisher. * Provide a precise mechanism for correcting a previously signaled supersession. * Reuse the SCIM SET envelope, SCIM Subject Identifier format, and delivery model defined by RFC 9967. * Permit receivers to maintain referential continuity without implying a particular identity-attribute convergence policy. * Keep identity-matching and attribute conflict-resolution algorithms outside the protocol. 1.2. Non-Goals This document does not standardize identity-matching or entity- resolution algorithms; confidence scoring or evidence formats; identity proofing or authentication; attribute-selection, conflict- resolution, or convergence algorithms; transfer of credentials or authentication factors; handling of non-SCIM application or customer data; cross-provider global person identifiers; or pre-authentication or pseudonymous Profile resources. A supersession event is an assertion by a specific issuer within an established trust relationship. It is not universal proof that two resources represent the same real-world person. 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. Vivek Expires 18 April 2027 [Page 4] Internet-Draft SCIM User Supersession October 2026 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 3.1. User Supersession A provider has User A and User B. The provider later determines that, within its identity model, both represented the same subject and chooses B as the surviving resource. It retires A according to local policy and emits a supersession event identifying B. A receiver can then distinguish the transition from an unrelated deletion and decide whether local references to A should be reconciled with B. Separately, if identity resolution changes the authoritative SCIM attributes of B, those changes are communicated using the ordinary SCIM protocol and the applicable RFC 9967 provisioning events. 3.2. Correction of an Incorrect Supersession The provider later determines that the A-to-B supersession was incorrect. The provider must signal that the earlier transition is no longer valid. Vivek Expires 18 April 2027 [Page 5] Internet-Draft SCIM User Supersession October 2026 If A still exists and can be reinstated, A may again represent the distinct subject. If A was permanently deleted and its identifier cannot be reused, the provider may create a new User C representing the subject formerly represented by A. * the supersession transition being invalidated; * the originally superseded resource; * the previous successor; and * the User resource that now represents the subject that had been retired. 3.3. Minimum Requirements A conforming publisher: * MUST distinguish supersession from ordinary deletion when it intends to communicate successor semantics; * MUST identify the successor User in a supersession event; * MUST assign a stable transitionId to each supersession and correction decision; * MUST identify the earlier supersession transition in a correction event; * MUST NOT use these events as an implicit authorization to transfer credentials, privileges, consent, or other protected state. A conforming receiver: * MUST validate the SET and the publisher before processing either event; * MUST scope all referenced resources to the publisher's authority; * MUST NOT treat supersession as an instruction to blindly copy or union attributes; * MUST NOT infer a prior supersession when a correction references a transition it has never observed or otherwise reconciled. Vivek Expires 18 April 2027 [Page 6] Internet-Draft SCIM User Supersession October 2026 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. 4.1. Transition Identifiers Each supersession or correction event payload contains a REQUIRED "transitionId" value. * MUST be unique within the issuer's authority for the underlying decision; * MUST be opaque to receivers; * MUST NOT be reused for an unrelated decision; * MUST remain stable if the same underlying transition is delivered more than once. The SET "jti" claim identifies a particular Security Event Token. The RFC 9967 "txn" claim may correlate changes belonging to one transaction. Neither replaces transitionId, because a later correction needs to refer to the underlying supersession decision independently of a particular token delivery. Vivek Expires 18 April 2027 [Page 7] Internet-Draft SCIM User Supersession October 2026 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 6.1. Common SET Requirements Both events defined by this document use the SCIM SET profile from [RFC9967]. Vivek Expires 18 April 2027 [Page 8] Internet-Draft SCIM User Supersession October 2026 The top-level sub_id claim MUST use the "scim" Subject Identifier format defined by [RFC9967], which uses the Subject Identifier framework from [RFC9493]. The top-level "sub" claim MUST NOT be used for these events. A SET carrying an event defined by this document MUST contain iss, aud, iat, and jti as required by the applicable SET and SCIM event specifications. For this version, a SET carrying one of the events defined here MUST contain exactly one of the two event URIs defined by this document. The referenced User identifiers MUST belong to the same SCIM authority as the sub_id resource. Receivers MUST NOT compare relative SCIM paths across issuers as if they were globally unique. 6.2. Supersession Event The proposed event URI is urn:ietf:params:scim:event:prov:supersede. This URI is not assigned by IANA at the time of this document. The top-level sub_id identifies the superseded User. The event payload contains: * transitionId - REQUIRED. The transition identifier for this supersession. * successor - REQUIRED. A SCIM Subject Identifier identifying the successor User. The successor MUST identify a User distinct from the User in sub_id and within the same SCIM authority. A supersession event states that the publisher has retired the sub_id User as its authoritative representation for the relevant subject and has selected successor as the surviving User resource. A supersession event MUST NOT be interpreted as an instruction to: * delete the superseded User; * copy or union every attribute from the superseded User; * transfer credentials or recovery factors; * grant the successor the superseded User's entitlements; Vivek Expires 18 April 2027 [Page 9] Internet-Draft SCIM User Supersession October 2026 * transfer consent or purpose-specific authorization. If identity resolution changes the successor's SCIM-visible attributes, the publisher SHOULD communicate the resulting successor resource state using the ordinary SCIM protocol and, when applicable, the RFC 9967 patch or put event. The supersession event carries the relationship between resource identities; it does not carry an attribute-level convergence delta. If the publisher subsequently deletes the superseded User, it SHOULD make the supersession available to authorized receivers before or with the deletion sequence so that the relationship is not lost. Example: { "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" } } } } 6.3. Supersession Correction Event The proposed event URI is urn:ietf:params:scim:event:prov:supersession-correction. This URI is not assigned by IANA at the time of this document. A supersession-correction event invalidates exactly one earlier supersession transition. Vivek Expires 18 April 2027 [Page 10] Internet-Draft SCIM User Supersession October 2026 The top-level sub_id identifies the User resource that now represents the distinct subject that had previously been retired. This resource MAY be the original superseded User if it still exists, or MAY be a newly created User if the original resource cannot be reinstated. The event payload contains: * transitionId - REQUIRED. The transition identifier for this correction. * reverses - REQUIRED. The transitionId of the earlier supersession that is being invalidated. * superseded - REQUIRED. A SCIM Subject Identifier identifying the User that was retired by the earlier supersession. * previousSuccessor - REQUIRED. A SCIM Subject Identifier identifying the successor selected by the earlier supersession. The publisher MUST NOT recycle an old SCIM User id for a different resource merely to make the correction appear to restore the original identifier. A correction invalidates the earlier supersession relationship. Any corresponding changes to the authoritative SCIM-visible attributes of the affected Users are communicated separately using ordinary SCIM PATCH or PUT semantics. Example where a replacement User is created because the original User cannot be reinstated: Vivek Expires 18 April 2027 [Page 11] Internet-Draft SCIM User Supersession October 2026 { "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" } } } } If the original User still exists and is reinstated, the top-level sub_id MAY identify the same User as superseded. 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. Vivek Expires 18 April 2027 [Page 12] Internet-Draft SCIM User Supersession October 2026 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. Vivek Expires 18 April 2027 [Page 13] Internet-Draft SCIM User Supersession October 2026 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 Vivek Expires 18 April 2027 [Page 14] Internet-Draft SCIM User Supersession October 2026 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? Vivek Expires 18 April 2027 [Page 15] Internet-Draft SCIM User Supersession October 2026 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: Vivek Expires 18 April 2027 [Page 16] Internet-Draft SCIM User Supersession October 2026 * 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. 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, . [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, . Vivek Expires 18 April 2027 [Page 17] Internet-Draft SCIM User Supersession October 2026 [RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, . [RFC9967] Hunt, P., Ed., Cam-Winget, N., Kiser, M., and J. Schreiber, "System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)", RFC 9967, DOI 10.17487/RFC9967, May 2026, . 14. Informative References [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC9944] Shahzad, M., Iqbal, H., and E. Lear, "Device Schema Extensions to the System for Cross-Domain Identity Management (SCIM) Model", RFC 9944, DOI 10.17487/RFC9944, May 2026, . Author's Address Vivek Sri Lanka Email: cvivekvinushanth@gmail.com Vivek Expires 18 April 2027 [Page 18]