RFC 7642

RFC 7642 carries the vocabulary the other two SCIM RFCs assume. It defines the actors, the triggers, and the flows of cross-domain identity management, and it states the requirements as use cases rather than as wire rules. The document sits outside the standards track by its own first line ("This document is not an Internet Standards Track specification"), and its normative content is correspondingly thin: the whole document contains one MUST, and it concerns transport security, not provisioning behavior (Section 4, retrieved 2026-11-01).

Its authors are Kepeng Li (editor, Alibaba Group), Phil Hunt (Oracle), Bhumip Khasnabish (ZTE), Anthony Nadalin (Microsoft), and Zachary Zeltsan; Section 2, the scenarios, is credited to Darran Rolls and Patrick Harding, whose material the section draws from ("Section 2 ("SCIM User Scenarios") is taken from them", acknowledgments, retrieved 2026-11-01). The 2025-2026 update wave does not touch it: RFC 9865 and RFC 9967 both declare "Updates: 7643, 7644" in their headers, so RFC 7642's text stands exactly as published, and the event work that grows from its Section 3.5 narrative amends the other two documents instead.

Section 2.2.1 names the four triggers that start provisioning work: create, update, delete, and the single-sign-on event that may require an account to exist first. Section 2.2.2 assigns the actors behind those triggers in its Figure 1: the Cloud Service Provider (CSP) that holds the data, theEnterprise Cloud Subscriber (ECS) that subscribes to it, and the Cloud Service User (CSU) the data describes. Section 2.2.3 separates push mode, where the client writes changes to the CSP, from pull mode, where the CSP is queried; the providers documented on this lab-site implement the push model. Bulk and batch semantics are named in Section 2.2.4 and delegated to the protocol document, RFC 7644.

On that frame Section 2.3 hangs six CSP-to-CSP flows and Section 2.4 four ECS-to-CSP flows. The counts are worth memorizing, because the flow list is the scope statement for everything a SCIM deployment can be asked to do:

Section 3 states requirements where the use cases need them: five subsections (migration of identities, SSO service, provisioning for a community of interest, transfer of attributes to a relying party, change notification), each carrying Pre-conditions, Post-conditions, and Requirements bullets. There is no consolidated requirements section to check an implementation against, and the requirements' own wording stays lowercase: Section 1.1 defines lowercase must and shall as plain English, reserved from the normative ALL-CAPS keywords. Reading 7642 for wire rules is the wrong tool; it exists to frame scope, and its requirements sections read as inputs to the protocol work, not as the protocol.

The one exception is Section 4, the security considerations, which carries the document's single MUST: "data confidentiality MUST be guaranteed at the transport layer". The section adds regulatory and personal-information guidance and points at the deeper treatments: RFC 7644 Section 7 for the protocol's security properties and RFC 7643 Section 9 for the schema's.

Section 3.5, change notification, is the use case worth tracking forward. Its shape: the subscriber is notified that a resource changed, then retrieves exactly the changed subset instead of re-reading the whole store. The 2015 protocol has no wire form for the notify half; implementers poll, or diff onmeta.lastModified (the architecture guide covers what that degrades without).

RFC 9967 supplies the missing half eleven years later: SCIM events as Security Event Tokens, with event URIs, payload rules, an asynchronous request flow, and the two usage modes that operationalize Section 3.5's notify-then-pull pattern. Its Updates header names RFC 7643 and RFC 7644, not this document; the lineage runs through the ideas, not through a formal amendment. Thenew-RFCs page carries the wire detail; the lineage is the reason a 2015 concepts document is still the front door to the 2026 event work.

7642 frames, 7643 defines the data, 7644 moves it. This site's breakdowns follow that split: theRFC 7643 page carries the schema model and its errata-repaired JSON, and the RFC 7644 page carries the wire contract, the filter grammar, and the error tables. Nothing in 7642 is needed to parse a filter or build a PATCH; all of it is needed to explain why the protocol looks the way it does.