SCIM 2.0 IPSIE Profile
draft-schreiber-scim-ipsie-profile-00

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,
              <https://datatracker.ietf.org/doc/html/draft-zollner-scim-
              interop-profile-01>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [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, <https://www.rfc-editor.org/info/rfc7523>.

   [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, <https://www.rfc-editor.org/info/rfc7643>.

   [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, <https://www.rfc-editor.org/info/rfc7644>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc8414>.

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]