| Internet-Draft | SCIM Interop Profile | March 2026 |
| Zollner | Expires 3 September 2026 | [Page] |
This document defines an implementation profile for the System for Cross-domain Identity Management (SCIM) 2.0. The goal of this profile is to increase interoperability between identity providers and service providers by reducing the number of optional features and providing clear guidance on implementing a common subset of the SCIM standard. It deprecates certain features that have proven to be problematic for interoperability or are considered insecure.¶
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 3 September 2026.¶
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.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/Zollnerd/scim-interop-profile.¶
The SCIM 2.0 standard RFC7643 [RFC7644] provides a powerful and flexible framework for automating user provisioning. However, its flexibility, with numerous optional features, attributes, and protocol variations, has led to significant interoperability challenges. Implementers are often faced with a wide array of choices, resulting in bespoke integrations that are costly to build and maintain.¶
This document specifies a profile for SCIM 2.0 to address these challenges. It provides a baseline of required features and deprecates others to ensure that implementations conforming to this profile can interoperate seamlessly.¶
The target audience for this profile includes developers of identity providers (IDPs) and service providers (SPs) who wish to build conformant and interoperable SCIM clients and servers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This profile applies to SCIM 2.0 Service Providers and Clients.¶
A Service Provider is conformant with this profile if it implements all the "MUST" and "REQUIRED" features defined herein.¶
A Client is conformant with this profile if it is capable of interacting with a conformant Service Provider.¶
Implementations claiming conformance to this profile should indicate so in their ServiceProviderConfig response.¶
Conformant Service Providers MUST implement the following resource types and their corresponding endpoints:¶
Service Providers MUST publish an accurate list of schemas and attributes via the /Schemas endpoint, matching exactly what is implemented and supported by the service.¶
Conformant Service Providers MAY implement the following resource types and their corresponding endpoints:¶
The following configuration discovery-related resource types and their corresponding endpoints MUST be implemented:¶
This section will define the minimal set of attributes that MUST be supported for the User and Group resources to ensure a baseline level of interoperability.¶
To ensure a functional baseline for user provisioning, Service Providers MUST support the following attributes for the User resource:¶
The password attribute is deprecated and MUST NOT be implemented. Service Providers SHOULD NOT store user passwords and should rely on other authentication methods, such as federation via SAML or OpenID Connect, to authenticate users.¶
Service Providers MUST support both the displayName and members attributes. All group resources MUST contain a value for displayName. Service Providers MUST allow groups to be created without any members.¶
To ensure predictable and interoperable behavior, Service Providers MUST implement case sensitivity consistently across both filtering operations and uniqueness constraint enforcement. For any given attribute, the case sensitivity rules applied during a filter query (e.g., userName eq "User.A") MUST be identical to the rules used to detect a uniqueness conflict during a POST or PATCH operation.¶
Furthermore, this profile requires adherence to the case sensitivity definitions specified in [RFC7643] for the following common attributes:
* userName: caseExact is false. Service Providers MUST treat JSmith and jsmith as equivalent.
* externalId: caseExact is true. Service Providers MUST treat ABC-123 and abc-123 as distinct values.¶
To ensure strict conformance and prevent unintended data loss or corruption, Service Providers MUST adhere to a strict handling model for attributes and schema extensions. When a SCIM request (e.g., POST, PUT, PATCH) contains attributes or schema URIs that are not defined in the Service Provider's ResourceType or Schema definitions, the request MUST be rejected.¶
The Service Provider MUST return an HTTP 400 Bad Request with a scimType error of invalidSyntax for such requests.¶
For multi-valued attributes that include a type sub-attribute (e.g., emails, phoneNumbers, ims, photos), Clients MUST use the canonical type values defined in [RFC7643] (e.g., "work", "home", "other"). Service Providers MUST treat these canonical values as case-insensitive.¶
All data exchange MUST use the JSON format as defined in [RFC7643], and all requests and responses containing SCIM data MUST use the Content-Type header with the value application/scim+json as defined in [RFC7644], Section 8.1. The XML data format is explicitly out of scope for this profile and MUST NOT be used.¶
To aid in troubleshooting and client identification, SCIM clients MUST include a User-Agent header in all HTTP requests. The header's value should be meaningful, for example, identifying the name of the client software.¶
The filter query parameter MUST be supported. Service Providers MUST support the eq and and operators. To promote interoperability, clients MUST NOT use operators other than eq and and.¶
The use of filters in the URI for any HTTP method other than GET (e.g., PATCH /Users?filter=...) is deprecated and MUST NOT be used.¶
Service Providers MUST support filtering on the following User attributes:¶
Service Providers MUST support filtering on the following Group attributes:¶
To ensure the reliable handling of large data sets, service providers MUST implement at least one of the following pagination methods for all list operations:¶
If the count parameter is omitted from a request, Service Providers SHOULD return at least 100 results by default. Service Providers MUST support a client-requested count value of at least 250. Service Providers SHOULD enforce a server-specified maximum number of results per page and MUST return fewer results than requested when the client specifies a count value that exceeds that limit.¶
Service Providers MUST support the PATCH operation ([RFC7644], Section 3.5.2) for resource updates. Clients MUST use the PATCH operation for updates and SHALL NOT use the PUT operation.¶
This profile defines a restricted subset of the SCIM 2.0 PATCH method to ensure predictable behavior and high interoperability.¶
Every operation object within the Operations array MUST contain a path attribute. Clients MUST NOT issue "path-less" PATCH operations where the target attribute is implied by the keys within the value object.¶
Service Providers MUST reject PATCH requests containing operations that lack a path attribute with an HTTP 400 Bad Request and a scimType error of invalidSyntax.¶
When a Client needs to update multiple attributes in a single HTTP request, it MUST provide a separate operation entry within the Operations array for each unique attribute path.¶
For singular simple attributes (e.g., userName, active), Service Providers MUST treat add and replace as functionally equivalent.¶
When only intending to modify the value of a specific sub-attribute of a complex attribute, Clients SHOULD target that sub-attribute using dot-notation (e.g., path: "name.givenName").¶
The following rules apply to each PATCH operation type:¶
If a Client targets a singular complex attribute in its entirety (e.g., path: "name") using the replace operation, the value MUST be a JSON object containing all sub-attributes the Client intends to persist.¶
If a Client targets a singular complex attribute in its entirety using the add operation, the value MUST be a JSON object. The Service Provider MUST perform a partial merge.¶
The following rules apply to each PATCH operation type:¶
Service Providers MAY return an HTTP 400 Bad Request for any PATCH operation that violates these constraints. Specific scimType values should be used as follows:
* invalidSyntax: Missing path or use of prohibited operators.
* invalidFilter: Filter matches more than one element in a multi-valued attribute.
* invalidPath: Filter fails to target a specific sub-attribute.¶
Service Providers MUST NOT treat a PATCH request that sets the active attribute to false as a deletion of the resource. A disabled user is considered inactive and should be excluded from authentication and normal access, but the user object itself MUST be retained by the Service Provider. Deletion of a resource can only be performed via an HTTP DELETE request.¶
SCIM clients MUST NOT include HTTP headers related to conditional requests or entity tags (ETags), such as If-Match, If-None-Match, If-Modified-Since, or If-Unmodified-Since. Service Providers are not expected to support these headers and MAY ignore them or reject the request. This profile relies on the principle of "last write wins" for simplicity.¶
Support for the /Bulk endpoint ([RFC7644], Section 3.7) is RECOMMENDED butOPTIONAL.¶
When a POST or PATCH request attempts to create or modify a resource in a way that violates a uniqueness constraint (e.g., for attributes like userName or externalId), the Service Provider MUST return an HTTP 409 Conflict response. The response body MUST also include a SCIM error detail with the scimType set to uniqueness, as defined in [RFC7644], Section 3.12.¶
All communication between a SCIM client and service provider MUST be secured using Transport Layer Security (TLS) version 1.2 [RFC5246] or a later version.¶
The use of HTTP Basic Authentication over TLS is NOT RECOMMENDED.¶
This document has no IANA actions.¶
(TODO: Add acknowledgements)¶