The new RFCs

The IANA group "System for Cross-domain Identity Management (SCIM) Schema URIs" atiana.org/assignments/scim was established by RFC 7643 Section 10, and it is the spine the three new RFCs hang from: each one mutates rows there, and each one is discovered at runtime through the ServiceProviderConfig document rather than versioned into the protocol. Nothing in the three RFCs makes anything mandatory for an existing server; a 2015-era deployment that ignores all of them remains conformant to the 2015 texts.

Published October 2025 as the first new SCIM RFC in a decade, RFC 9865 exists because SCIM service providers are usually wrappers over backends that already paginate with cursors. Translating cursors to RFC 7644's index pagination forces the server to iterate and materialize full result sets; the RFC names that cost "pagination translation" and adds a cursor mode alongside it. The mode engages when a client uses the cursor parameter on a GET search or a POST SearchRequest.

The client contract is deliberately narrow: repeat the initial query with all parameters identical except the cursor. Three scimType values extend RFC 7644's error table for the mode, all on 400:invalidCursor, expiredCursor, and invalidCount (the count must match the initial query's). Two design rules matter to implementers adding cursors to an index-paginated server: the SP MAY force cursor pagination by returning nextCursor even when the client did not ask for it, and if both methods are supported the SP MUST pick and advertise a default, with the RFC's own guidance to keep index as the default for compatibility. One relaxation rides along: totalResults MAY be omitted by cursor-paginating SPs that cannot estimate it, which a 7644-era client must therefore treat as optional in the wild.

The security considerations are worth reading in full: possession of a cursor confers no privilege and authorization is re-checked per page; SPs SHOULD invalidate a user's cursors on permission changes or keep counts consistent; out-of-scope and non-existent pages MUST return identical errors so cursors cannot be probed; and large anonymous cursor queries remain subject to the 400 tooManyceiling.

Published May 2026 and purely additive (its header carries no Updates line; it extends SCIM through RFC 7643's extension mechanism alone), RFC 9944 registers two core resources. Device(urn:ietf:params:scim:schemas:core:2.0:Device) carries a REQUIRED booleanactive, an optional displayName, mudUrl (an RFC 8520 Manufacturer Usage Description URL), and read-only groups. EndpointApp covers the client applications that control devices or receive telemetry, with a REQUIRED immutableapplicationType of deviceControl or telemetry, and a credential model that returns either server-generated clientToken or acceptedcertificateInfo. Group membership extends to both: the members type may be"Device" or "EndpointApp".

Two aspects make the document worth a close read beyond its schema tables. First, the role reversal: in the device model the SCIM server lives in the deployment receiving device records, while the SCIM clients are the vendors and onboarding apps pushing those records. The RFC states the consequence plainly: the SCIM database "is therefore essentially equivalent to a network's AAA database". The provisioning direction has not changed; the authority relationship has. Second, the appendices: RFC 9944 ships non-normative JSON Schema and OpenAPI renderings of its schemas, artifact forms SCIM never had in 2015, which change what tooling can consume a SCIM schema directly.

The registry footprint is the largest of the three RFCs: 12 URIs, two core plus ten extensions covering BLE (with four nested pairing-method schemas), Wi-Fi Easy Connect, Ethernet MAB, FIDO Device Onboard, Zigbee, and the endpoint-apps extension for non-IP devices behind application-layer gateways. The ethernet-MAB extension carries the RFC's own warning that MAC-address authentication is weak and incompatible with MAC randomization.

Published May 2026, RFC 9967 profiles Security Event Tokens (RFC 8417) for SCIM: a SCIM Event is a SET whose events claim carries URNs under urn:ietf:params:scim:event. Subjects are identified with the RFC 9493 sub_id claim in a SCIM-specific format whoseuri member is REQUIRED (the path after the Base URI); the JWT sub claim MUST NOT be used. Alongside the event identity ride four payload claims: txn (a transaction identifier shared across every SET from one state change, REQUIRED for async and replication use),version (the resulting ETag), data (a full resource representation), andattributes (the changed-attribute names, in RFC 7644 path syntax). Exactly one ofdata and attributes MUST be present where a payload is defined, never both.

The event URIs split into three classes, and the notice/full suffix encodes the payload choice:

The protocol update is the asynchronous request flow. A client sends POST, PUT, PATCH, or DELETE withPrefer: respond-async (RFC 7240); the SP returns either the normal response or 202 Accepted with an empty body, a Set-Txn header whose value MUST match the txn claim of the future completion event, Preference-Applied: respond-async, and a Location that retrieves that event. For asynchronous bulk requests, each operation in the originalOperations array gets its own completion event, with txn suffixed:<zero-based index> of the operation it completes; the bulkId value MUST NOT be used for this. The ServiceProviderConfig gains an OPTIONAL securityEvents block withasyncRequest (none, long, or request) and an informational eventUris list; absent block, no support. Discovery stays in the same document the 2015 spec established.

Appendix A defines the two usage modes that give the event model its deployment shapes:Domain-Based Replication, where one administrative owner replicates full state between systems that share authority (full-data events), and Coordinated Provisioning, where independent systems coordinate through notice events plus callback reads of the changed resource. The security section binds the modes to practice: TLS is REQUIRED for sensitive SETs, receivers MUST persist events before acknowledging (recovery depends on it), JWS signature verification is REQUIRED when the publisher is not communicating directly (which also protects through TLS-terminating proxies), and the async result URI MUST require authentication. High-churn groups get explicit guidance: prefer PATCH over PUT, use notice events with periodic GETs, and aggregate PATCHes, because a PUT of a 100k-member group floods every event payload.

Read together, the three RFCs teach a repeatable design pattern for extending SCIM without fragmenting it. Each capability is optional and discovered in the ServiceProviderConfig, never inferred; an absent attribute means the feature is unsupported, with no probing grammar. Servers keep control of defaults (RFC 9865's SP MAY force cursors, and its keep-index-default guidance for dual-mode servers). Registry rows, not document prose, carry the machine-readable identity of every new schema and event. The drafts on the drafts tracker follow the same shape: attribute pagination, tenancy, and agent governance all propose ServiceProviderConfig discovery blocks of their own.

Adoption has started, unevenly: UnboundID's scim2 6.1.0 and SCIM-SDK 1.35.0 both advertise RFC 9865 cursor pagination and RFC 9944 device management in their release notes as of 2026-11-01; RFC 9967 support had not shown up in those notes at retrieval time. For a protocol that sat still from 2015 to 2025, the presence of any implementation signal within months is the adoption story to watch.