Internet-Draft IPSIE AL1 SCIM February 2026
Schreiber, et al. Expires 24 August 2026 [Page]
Workgroup:
IPSIE
Internet-Draft:
draft-schreiber-ipsie-scim-al1-profile-latest
Published:
Intended Status:
Informational
Expires:
Authors:
J. Schreiber
SGNL
M. Maguire
Aujas Cybersecurity
D. Zollner
Okta
P. Valarezo
Independent

IPSIE AL1 SCIM 2.0 Profile

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.

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 24 August 2026.

▲

Table of Contents

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/ipsie-scim-al1-profile.

2. Introduction

This document defines the IPSIE Account Lifecycle 1 (AL1) Profile for SCIM 2.0. 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 addresses critical aspects of secure identity management, with particular emphasis on:

By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations.

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.

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. Profile

4.1. Authentication and Authorization

The Identity Service and Application MUST use OAuth 2.0 [RFC6749] for authentication and authorization of SCIM protocol.

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 Application's OAuth 2.0 authorization server SHALL NOT support inclusion of client credentials in the HTTP request-body
  • The token MUST contain a "token_endpoint" value which is the URL of the Identity Service's OAuth 2.0 token endpoint.
  • The Acess Token MUST include the "scim" scope and not grant broader permissions.
  • All Authorization Server parameters SHOULD be discovered from OAuth Authorization Server metadata as defined in [RFC8414].
  • The Identity Service SHOULD expose a jwks_uri to allow the Application to perform signature verification

4.2. SCIM Interoperability Requirements

4.2.1. General Requirements

  • 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].
  • All SCIM operations SHALL be authenticated and authorized via OAuth 2.0 as specified in Section 4.1.
  • Local modifications to Users or Groups in the Application are prohibited.
  • The Application SHALL 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 Identity Service SHALL use the HTTP PATCH method to update resources and SHALL NOT use the HTTP PUT method.

4.2.2. User Provisioning

Requirements for user provisioning operations are defined in this section.

4.2.2.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.

4.2.2.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.

DZ note Set the credential-related requirements as aggressively restrictive for now, can define any exceptions or other rules later after discussion.

4.2.2.3. Create User (POST /Users)

The Identity Service and the Application MUST support user creation via POST /Users.

4.2.2.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}.

4.2.2.5. 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.

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.

4.2.2.6. 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.

4.2.2.7. Get All Users (GET /Users)

The Application MUST support retrieval of all users via the SCIM operation GET /Users.

The Application MUST support at least one pagination method and SHOULD avoid returning more than 1,000 users per page. Support for cursor-based pagination by the Application is RECOMMENDED.

4.2.2.8. Get User By ID (GET /Users/{id})

The Application MUST support retrieving a single user by ID via the SCIM operation GET /Users/{id}.

4.2.2.9. List Users By Alternate Identifier (GET /Users?)

The Application MUST support the SCIM "filter" query parameter, performed via the SCIM operation: GET /Users?filter={filterExpression}

Application Providers MUST support the following filter expressions:

  • username eq {username}
  • externalId eq {externalId}
  • emails[value eq {email}]
  • emails[type eq "work" and value eq {email}]

4.2.3. 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.

4.2.3.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.

4.2.3.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.

4.2.3.3. Get All Groups (GET /Groups)

The Application MUST support retrieval of all groups via the SCIM operation GET /Groups.

The Application MUST support the attributes= and excludedAttributes= parameters.

The Identity Service SHOULD include excludedAttributes=members in the HTTP URI when listing all groups.

4.2.3.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}.

4.2.3.5. List Groups By Alternate Identifier (GET /Groups?)

The Application MUST support the SCIM "filter" query parameter, performed via the SCIM operation: GET /Groups?filter={filterExpression}

The Application MUST support the following filter expressions for groups:

  • displayName eq {displayName}
  • externalId eq {externalId}
4.2.3.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.

4.3. Metadata Endpoints

4.3.1. ResourceTypes

Application MUST host a /ResourceTypes endpoint, as defined in Section 4 of [RFC7644].

4.3.2. ServiceProviderConfig

Application Providers MUST host a /ServiceProviderConfig endpoint to describe the operations they support, as defined in Section 4 of [RFC7644]

The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile.

4.3.3. Schemas

Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of [RFC7644]. There must be a schema for each implemented resource type. Schemas returned by the Application MUST include all implemented attributes and MUST NOT include attributes that are not implemented.

5. Security Considerations

For SCIM security considerations, see [RFC7643] and [RFC7644]

Additionally, the following requirements are included to address security considerations.

6. IANA Considerations

This document has no IANA actions.

7. Compliance Statement

Implementation of all mandatory requirements in this profile will result in a SCIM 2.0 deployment that satisfies IPSIE Identity Lifecycle Level 1 (IL1). Specifically:

By conforming to this profile, implementations will achieve a consistent, secure, and interoperable baseline for enterprise identity lifecycle management.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <https://www.rfc-editor.org/info/rfc8414>.

Authors' Addresses

Jen Schreiber
SGNL
Mark Maguire
Aujas Cybersecurity
Danny Zollner
Okta
Pablo Valarezo
Independent