IPSIE J. Schreiber Internet-Draft Crowstrike Intended status: Informational D. Zollner Expires: 7 January 2027 Okta 6 July 2026 SCIM 2.0 IPSIE Profile draft-schreiber-scim-ipsie-profile-00 Abstract This document defines a profile for SCIM 2.0 to meet the security and interoperability requirements for identity lifecycle management within enterprises. Within the context of SCIM, the profile establishes requirements for provisioning, account management, client authentication, and identity synchronization across three Account Lifecycle assurance levels: AL1 (User Deprovisioning), AL2 (User and Group Management), and AL3 (Role Management). 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Schreiber & Zollner Expires 7 January 2027 [Page 1] Internet-Draft SCIM IPSIE July 2026 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. Discussion Venues . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 4. Shared Prerequisites . . . . . . . . . . . . . . . . . . . . 5 4.1. Authentication and Authorization . . . . . . . . . . . . 5 4.2. SCIM Interoperability Requirements . . . . . . . . . . . 5 4.3. Performance and Efficiency . . . . . . . . . . . . . . . 6 5. AL1: User Deprovisioning . . . . . . . . . . . . . . . . . . 6 5.1. Deactivate or Reactivate User (PATCH /Users/{id}) . . . . 6 5.2. Delete User (DELETE /Users/{id}) . . . . . . . . . . . . 7 5.3. Get User By ID (GET /Users/{id}) . . . . . . . . . . . . 7 5.4. List Users By Alternate Identifier (GET /Users?) . . . . 7 6. AL2: User and Group Management . . . . . . . . . . . . . . . 8 6.1. User Provisioning . . . . . . . . . . . . . . . . . . . . 8 6.1.1. Schema . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.2. Passwords and other credentials . . . . . . . . . . . 8 6.1.3. Create User (POST /Users) . . . . . . . . . . . . . . 8 6.1.4. Update User (PATCH /Users/{id}) . . . . . . . . . . . 9 6.1.5. Get All Users (GET /Users) . . . . . . . . . . . . . 9 6.2. Group Provisioning Operations . . . . . . . . . . . . . . 9 6.2.1. Schema . . . . . . . . . . . . . . . . . . . . . . . 9 6.2.2. Create Group (POST /Groups) . . . . . . . . . . . . . 9 6.2.3. Get All Groups (GET /Groups) . . . . . . . . . . . . 10 6.2.4. Get Group By ID (GET /Group/{id}) . . . . . . . . . . 10 6.2.5. List Groups By Alternate Identifier (GET /Groups?) . 10 6.2.6. Update Group (PATCH /Group/{id}) . . . . . . . . . . 10 7. AL3: Role Management . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Compliance Statement . . . . . . . . . . . . . . . . . . . . 11 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Schreiber & Zollner Expires 7 January 2027 [Page 2] Internet-Draft SCIM IPSIE July 2026 1. Discussion Venues 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/jischr/scim-ipsie-profiles (https://github.com/jischr/scim-ipsie-profiles). 2. Introduction This document defines the SCIM 2.0 IPSIE Profile for enterprise identity lifecycle management. It provides a clear reference for SCIM deployments that require a well-defined security baseline meeting best practices for interoperable enterprise identity management. The profile is organized according to the three IPSIE Account Lifecycle assurance levels as defined in the IPSIE Levels specification: * *AL1 - User Deprovisioning*: The Application deprovisions users at the request of the Identity Service. This includes account deactivation and deletion. * *AL2 - User and Group Management*: The Identity Service synchronizes user provisioning and group membership with the Application. The Application accepts creation and updates of user accounts and maps groups and their memberships to application roles and capabilities. * *AL3 - Role Management*: The Application exposes its available roles to the Identity Service, enabling centralized role assignment and synchronization. Each level is cumulative: AL2 requirements extend AL1, and AL3 requirements extend AL2. The profile addresses critical aspects of secure identity management, with particular emphasis on: * Client authentication * Retrieve, add, and modify Users * Retrieve, add, and modify Groups * Synchronization of data from the Identity Service to the Application By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations. Schreiber & Zollner Expires 7 January 2027 [Page 3] Internet-Draft SCIM IPSIE July 2026 3. Conventions and Definitions 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. 3.1. Terminology SCIM | The System for Cross-domain Identity Management as defined in | [RFC7643] and [RFC7644] SCIM Client | An application that uses the SCIM protocol to access or manage | identity data maintained by the SCIM service provider (SP). The | client initiates SCIM HTTP requests to a SCIM service provider. | To clarify the relationship in terms of identity management, the | Identity Provider (IdP) is the SCIM Client and initiates requests | to the SP, which is the SCIM Server. SCIM Server (also referred to as SCIM Service Provider) | An HTTP web application that provides identity information via the | SCIM protocol. To clarify the relationship in terms of identity | management, the SP is the SCIM Server and receives the requests | from the IdP, which is the SCIM Client. Role | A set of permissions. Any user or account within the same role | receives the predefined ability to access a resource and/or | perform an action. Identity Service or Identity Provider (IdP) | Acts as the SCIM client, initiating all provisioning, updates, and | deprovisioning operations. Application | Acts as the SCIM server or service provider, hosting SCIM | endpoints and processing all provisioning requests. Schreiber & Zollner Expires 7 January 2027 [Page 4] Internet-Draft SCIM IPSIE July 2026 Note: When SCIM is applied to the context of IPSIE, the Identity Service acts as the SCIM client and the Application acts as the SCIM service provider. The document will use the Role terms below for consistency across IPSIE profiles. 4. Shared Prerequisites The following requirements apply to all assurance levels defined in this profile. 4.1. Authentication and Authorization The Identity Service and Application MUST use OAuth 2.0 [RFC6749] for authentication and authorization of all SCIM (HTTP) requests. | *Editor's Note:* This section should be expanded and may need to | reference the IPSIE Session Lifecycle 1 (SL1) profile. The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: * OAuth 2.0 interactions MUST use the client_credentials grant type with JWT Client Authentication as defined in [RFC7523] section 2.2. * The Identity Provider SHALL acquire an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. * The Identity Service MUST authenticate to the Application's OAuth 2.0 authorization server using HTTP Basic authentication in the Authorization request header. Transmission of client credentials (e.g., client_assertion, client_secret) in the HTTP request body is prohibited. * The Access Token MUST include the "scim" scope and not grant broader permissions. * Both the Application and the Identity Service MUST expose OAuth Authorization Server metadata as defined in [RFC8414]. The Application's metadata document MUST include a "token_endpoint" value identifying its OAuth 2.0 token endpoint. The Identity Service's metadata document MUST include a "jwks_uri" so that the Application can retrieve the Identity Service's public keys and validate the signatures of JWTs it issues. 4.2. SCIM Interoperability Requirements Schreiber & Zollner Expires 7 January 2027 [Page 5] Internet-Draft SCIM IPSIE July 2026 * Implementations conforming to this profile MUST also conform to the SCIM 2.0 Interoperability Profile [I-D.zollner-scim-interop-profile]. The requirements of this profile supplement and extend those of the SCIM 2.0 Interoperability Profile. * The Identity Service SHALL implement the required functionality of a SCIM client as defined in [RFC7643] and [RFC7644]. * The Application SHALL implement the required functionality of a SCIM service provider as defined in [RFC7643] and [RFC7644]. * Local modifications to Users or Groups in the Application are prohibited. 4.3. Performance and Efficiency * The Application MUST enforce rate limits on all SCIM endpoints and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. * The Application MUST support at least 25 SCIM requests per second. This requirement is per-tenant for multi-tenant (B2B SaaS, etc.) applications. * The Application and the Identity Service MUST support the SCIM /Bulk endpoint defined in [RFC7643] section 3.7. * The Application MUST support PATCH requests that update multiple attributes within a single request. * The Identity Service SHOULD optimize its SCIM request logic to minimize the number of SCIM requests made for each resource in a short period of time. As an example, a single PATCH request containing multiple attribute updates should be made rather than updating each attribute in a separate PATCH request. * The Identity Service SHOULD use the SCIM /Bulk endpoint when it plans to make changes to more than 100 SCIM resources in a 5 minute period. 5. AL1: User Deprovisioning AL1 requires the Application to deprovision users at the request of the Identity Service. The Identity Service can suspend, archive, delete, or otherwise deprovision accounts at the Application. 5.1. Deactivate or Reactivate User (PATCH /Users/{id}) Changes to the user activation status, such deactivation and reactivation, are performed by the SCIM operation PATCH /Users/{id} The Identity Service SHOULD propagate user deactivation events to the Application within 5 minutes of the user being deactivated. Schreiber & Zollner Expires 7 January 2027 [Page 6] Internet-Draft SCIM IPSIE July 2026 The Application SHOULD respond to user deactivation events by revoking the ability for the user to continue accessing the Application, including the revocation of currently active sessions. Session revocation mechanisms are outside the scope of this profile. Revocation SHOULD occur within 5 minutes of receiving the deactivation request. When a user account is deactivated, all access mechanisms and authorizations associated with that account MUST also be deactivated. This includes, but is not limited to: * Web sessions * API tokens * Refresh tokens * Personal access tokens * SSH keys associated with the user * Device-based authentication credentials The Application MUST allow reactivation of a deactivated user. 5.2. Delete User (DELETE /Users/{id}) Applications MAY allow users to be deleted via the SCIM operation DELETE /Users/{id}. After a user is deleted, the Application MUST allow the creation of a new user with the same username. | *Editor's Note:* Need to clarify implications for maintaining user | data and avoiding conflicts when recreating users with the same | username. 5.3. Get User By ID (GET /Users/{id}) The Application MUST support retrieving a single user by ID via the SCIM operation GET /Users/{id}. 5.4. List Users By Alternate Identifier (GET /Users?) The Application MUST support the following filter expressions: * username eq {username} * externalId eq {externalId} * emails[value eq {email}] * emails[type eq "work" and value eq {email}] Schreiber & Zollner Expires 7 January 2027 [Page 7] Internet-Draft SCIM IPSIE July 2026 6. AL2: User and Group Management AL2 extends AL1. In addition to deprovisioning, the Identity Service synchronizes user provisioning and group membership with the Application. The Application MUST accept creation and updates of user accounts from the Identity Service and MUST prohibit local account creation for users managed by the Identity Service. The Application MUST support mapping Identity Service groups to local Application roles and capabilities. 6.1. User Provisioning Requirements for user provisioning operations are defined in this section. 6.1.1. Schema The Application MUST include the following attributes in the User schema: * userName * displayName * active Additionally, the "externalId" attribute defined as optional in the "common" resource schema in [RFC7643] MUST be supported by the Application. 6.1.2. Passwords and other credentials The Application MUST NOT support the "password" attribute. The Identity Service MUST NOT include the "password" attribute in any SCIM requests. A user resource may have various credentials or similar data associated with them. This includes passwords, password hashes, private keys, and multi-factor authentication data such as Time-Based One-Time Password (TOTP) seeds. The Application MUST NOT define attributes containing credentials in custom schemas. The Identity Service MUST NOT send values for user credentials in any SCIM requests. 6.1.3. Create User (POST /Users) The Identity Service and the Application MUST support user creation via POST /Users. Schreiber & Zollner Expires 7 January 2027 [Page 8] Internet-Draft SCIM IPSIE July 2026 6.1.4. Update User (PATCH /Users/{id}) The Identity Service and the Application MUST support updating a user's attribute values via the SCIM operation PATCH /Users/{id}. 6.1.5. Get All Users (GET /Users) The Application MUST support retrieval of all users via the SCIM operation GET /Users. The Application SHOULD avoid returning more than 1,000 users per page. Support for cursor-based pagination by the Application is RECOMMENDED. 6.2. Group Provisioning Operations Requirements for group provisioning operations are defined in this section. The Application MAY implement support for groups and MUST follow the below requirements if it does. 6.2.1. Schema The Application MUST include the following attributes in the Group schema: * displayName * members Additionally, the "externalId" attribute defined as optional in the "common" resource schema in [RFC7643] MUST be supported by the Application. The Application SHOULD NOT allow multiple groups to have the same value for the "displayName" attribute". The Identity Service SHOULD use a unique value for the "displayName" attribute. 6.2.2. Create Group (POST /Groups) The Identity Service and the Application MUST support group creation via POST /Groups. The Application MUST allow groups to be created with zero members. Schreiber & Zollner Expires 7 January 2027 [Page 9] Internet-Draft SCIM IPSIE July 2026 6.2.3. Get All Groups (GET /Groups) The Application MUST support retrieval of all groups via the SCIM operation GET /Groups. The Identity Service SHOULD include excludedAttributes=members in the HTTP URI when listing all groups. 6.2.4. Get Group By ID (GET /Group/{id}) The Application MUST support retrieving a single group by ID via the SCIM operation GET /Groups/{id}. 6.2.5. List Groups By Alternate Identifier (GET /Groups?) The Application MUST support the following filter expressions for groups: * displayName eq {displayName} * externalId eq {externalId} * members[value eq {memberId}] 6.2.6. Update Group (PATCH /Group/{id}) The Identity Service and the Application MUST support updating a group's attribute values via the SCIM operation PATCH /Groups/{id}. The Application MUST support the inclusion of at least 50 add or remove operations on the "members" attribute in a single PATCH request. The Identity Service SHOULD compile multiple changes to the "members" attribute into a single PATCH request. 7. AL3: Role Management AL3 extends AL2. The Application exposes its available roles to the Identity Service, enabling centralized role assignment and synchronization. The Identity Service maps Application roles to users and synchronizes those assignments back to the Application. | *Editor's Note:* AL3 requirements are not yet defined in this | draft. Requirements will be added in a future revision. 8. Security Considerations For SCIM security considerations, see [RFC7643] and [RFC7644] Schreiber & Zollner Expires 7 January 2027 [Page 10] Internet-Draft SCIM IPSIE July 2026 Additionally, the following requirements are included to address security considerations. * *Error Handling*: Error responses SHALL use the SCIM error format and SHALL NOT leak internal details. * *Replay Resistance*: Access tokens SHALL expire and nonces SHALL be validated to prevent replay. * *Auditing*: All SCIM requests resulting in the creation, deletion, or modification of a SCIM resource SHALL be logged for audit and troubleshooting. * *Rate Limiting*: All endpoints SHALL enforce rate limiting and must respond with "429 Too Many Requests" when limits are exceeded. 9. IANA Considerations This document has no IANA actions. 10. Compliance Statement Implementation of all mandatory requirements at each level results in a SCIM 2.0 deployment satisfying the corresponding IPSIE Account Lifecycle assurance level. * *AL1 (User Deprovisioning)* - *Identity Service (SCIM client)*: SHALL initiate deactivation and deletion operations for Users and SHALL adhere to the security considerations above. - *Application (SCIM service provider)*: SHALL support PATCH /Users/{id} for deactivation and reactivation, SHALL support DELETE /Users/{id}, SHALL prevent local modifications outside of SCIM, SHALL enforce OAuth 2.0 JWT Profile for Authentication [RFC7523], and SHALL adhere to the security considerations above. * *AL2 (User and Group Management)* — requires AL1 - *Identity Service (SCIM client)*: SHALL initiate all CRUD operations for Users and Groups and SHALL adhere to the security considerations above. - *Application (SCIM service provider)*: SHALL host all SCIM endpoints with full support for User provisioning, and if supported, Group provisioning; SHALL prevent local modifications outside of SCIM; SHALL enforce OAuth 2.0 JWT Profile for Authentication [RFC7523]; and SHALL adhere to the security considerations above. Schreiber & Zollner Expires 7 January 2027 [Page 11] Internet-Draft SCIM IPSIE July 2026 * *AL3 (Role Management)* — requires AL2 - Requirements to be defined in a future revision. By conforming to this profile at the appropriate level, implementations will achieve a consistent, secure, and interoperable baseline for enterprise identity lifecycle management. 11. Normative References [I-D.zollner-scim-interop-profile] Zollner, D., "SCIM 2.0 Interoperability Profile", Work in Progress, Internet-Draft, draft-zollner-scim-interop- profile-01, 15 April 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [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, . Schreiber & Zollner Expires 7 January 2027 [Page 12] Internet-Draft SCIM IPSIE July 2026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . Authors' Addresses Jen Schreiber Crowstrike Email: jwschreib@gmail.com Danny Zollner Okta Email: danny.zollner@okta.com Schreiber & Zollner Expires 7 January 2027 [Page 13]