Create IL1-SCIM.md #72

2MarkMaguire · 2025-05-02T20:08:53Z

First draft of SCIM 2.0 profile for IPSIE IL1

mcguinness · 2025-05-03T05:25:22Z

IL1-SCIM.md

+
+# 3.0 Profile
+
+## 3.1 Client Authentication


Recommend we follow similar approach to CAEP Interoperability Profile 1.0 https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html and have OAuth requirements in its own section

I think we should take a dependency on Protected Resource Server Metadata RFC 9728 and Authorization Server Metadata RFC 8414 for discovery of most of the OAuth parameters needed to obtain an access_token for the SCIM Server.

SCIM Server must always publish the following in the PRM

Only 1 Authorization Server (constraint for simplification we can revisit)

Scopes required for the SCIM Server (e.g. both read and manage)

Bearer method supported of header

CAEP interop also defined fallback scopes as PRM was optional. If we don't want to take the dependency on PRM then I would advocate for both a read and manage scope similar to SSF.

I am assuming you intended to support JWT Client Authentication with RFC 7523 and not JWT Authorization Grant. It's currently ambiguous

Only supporting client authentication with JWT assertion adds a lot more deployment friction especially for a multi-tenant deployments IMHO. The Identity Service would more than likely need to register a client credential per-RP tenant out-of-band and couldn't reuse a common registration across tenants as their is no consent flow to authorize the instance. This often a blocker that needs its own human in the loop workflow when onboarding SCIM for an app.

The benefit of authorization code flow is the Identity Server can ask the admin to delegate access at runtime with minimal configuration needed with a shared client registration. The drawback being that operations are performed as the user being delegated and access would be revoked when the user who delegated access is revoked or deactivated.

The use of JWT as Authorization Grant could be interesting if we wanted to profile this as I think we would need to solve a tenant claim for both the OP and RP. This would more than likely be something we need to do outside of IPSIE.

Recommend we follow similar approach to CAEP Interoperability Profile 1.0 https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html and have OAuth requirements in its own section

I think we should take a dependency on Protected Resource Server Metadata RFC 9728 and Authorization Server Metadata RFC 8414 for discovery of most of the OAuth parameters needed to obtain an access_token for the SCIM Server.

SCIM Server must always publish the following in the PRM

* Only 1 Authorization Server (constraint for simplification we can revisit) * Scopes required for the SCIM Server (e.g. both read and manage) * Bearer method supported of `header`

CAEP interop also defined fallback scopes as PRM was optional. If we don't want to take the dependency on PRM then I would advocate for both a read and manage scope similar to SSF.

Updated to remove Client Authentication Section and instead make OAuth 2.0 Requirements, which includes Auth as a part of it

I am assuming you intended to support JWT Client Authentication with RFC 7523 and not JWT Authorization Grant. It's currently ambiguous

Only supporting client authentication with JWT assertion adds a lot more deployment friction especially for a multi-tenant deployments IMHO. The Identity Service would more than likely need to register a client credential per-RP tenant out-of-band and couldn't reuse a common registration across tenants as their is no consent flow to authorize the instance. This often a blocker that needs its own human in the loop workflow when onboarding SCIM for an app.

The benefit of authorization code flow is the Identity Server can ask the admin to delegate access at runtime with minimal configuration needed with a shared client registration. The drawback being that operations are performed as the user being delegated and access would be revoked when the user who delegated access is revoked or deactivated.

The use of JWT as Authorization Grant could be interesting if we wanted to profile this as I think we would need to solve a tenant claim for both the OP and RP. This would more than likely be something we need to do outside of IPSIE.

You are correct - I meant JWT Client Authentication with RFC 7523 not Authorization Grant. Just corrected this.

mcguinness · 2025-05-03T05:43:31Z

IL1-SCIM.md

+Identity Services shall authenticate to the Application's SCIM endpoint using OAuth 2.0 with the JWT Authorization Grant (RFC 7523). All of the following conditions should be met:
+* The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests.
+* The token must be scoped to "scim" and not grant broader permissions.
+* The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint.


All of the Authorization Server parameters should be discovered from OAuth Authorization Server metadata

When we break OAuth requirements out as its own section I will include that as a requirement

complete - this is now added in the OAuth 2.0 requiremements

For consistency, should this be pulled into the common requirements doc, allowing us to specify common behavior for all OAuth clients under IPSIE?

mcguinness · 2025-05-03T06:26:00Z

IL1-SCIM.md

+* The Application shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644.
+* All SCIM operations shall be authenticated via OAuth 2.0; local modifications are prohibited.
+
+### 3.2.2 User Provisioning Operations


I was thinking we would have the required lifecycle operations defined for IPSIE then this document just maps the IPSIE operation to a protocol-specific operation. The IPSIE lifecycle operation would be based on something like ISO/IEC 24760-1:2019 vs REST verbs.

So for example:

Enroll User -> Create User Resource (POST /Users)
Activate User -> Modify User Resource (PATCH /User/:id)
Maintain User -> Modify User Resource (PATCH /User/:id)
Suspend User -> Modify User Resource (PATCH /User/:id)
Deactivate User -> Modify User Resource (PATCH /User/:id)
Reactivate User -> Modify User Resource (PATCH /User/:id)
Delete User -> Delete User Resource (DELETE /User/:id)

The SCIM profile maps to the IPSIE Levels as they are currently written (IL1 requires for CRUD operations to keep RP's in sync with the IdP's data).

This is an interesting idea, but would be a change to the level's definition. We can take this idea to the group meeting and see if people want to change the level definitions? And if we do update the levels, a logical next step would be to update the profile for the levels (such as this one). But at this time, there are no updates to make to this PR.

mcguinness · 2025-05-04T05:57:32Z

IL1-SCIM.md

+
+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. The revocation mechanism is an implementation detail outside the scope of this specification. Revocation SHOULD occur within 5 minutes of receiving the deactivation.


I think we need to be more opinionated here in IPSIE. Deactivation needs to revoke ALL access for user.

We should also look at the revocation as a SLO as you noted above, @mcguinness.

I disagree here. Frequently lifecycle events for large companies are 2 steps:

Disable

(2 weeks later) Delete

When HR accidentally terms someone (and it happens all the time), this allows for their accounts to be reenabled without forcing all access to be rerequested.

I think if we require all access to be removed on disable then it becomes over-prescriptive and removes enterprises freedom to choose what works best for them.

We might need better language but my intent was to ensure all access was revoked not that the account was deleted or permissions were revoked. Suspending an account needs to have stronger guarantee on what is revoked (e.g web sessions, refresh tokens, api tokens, and personal access tokens).

Agreed - updated to include the following:

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

mcguinness · 2025-05-04T05:58:04Z

IL1-SCIM.md

+
+The Application MUST allow reactivation of a deactivated user. 
+
+#### 3.2.6 Delete User (DELETE /Users/{id})


Can you delete an active user?

Its a good question. I would say yes - but I think this is something we should standardize with IPSIE

Deactivate then Delete IMHO seems to align better with what I have seen in the wild. This enables access state to revoked during deactivation then database relationships such as group memberships to be removed during delete.

I think this is something we do not need to take an opinionated stance on for IPSIE.

We should require RP's to support the delete, but allow them the flexibility of if they require a disable first then delete or straight to delete depending on their implementation.

This pushes configuration to the IdP. The IdP can't discover what behavior the SP requires. We can solve this with additional metadata or required behaviors. If we wan't to keep this behavior up to the RP then we should consider modeling additional metadata (suggest we consider the broader challenge of publishing #72 (comment))

mcguinness · 2025-05-04T06:02:11Z

IL1-SCIM.md

+#### 3.2.5 Deactivate or Reactivate User (PATCH /Users/{id})
+Changes to the user activation status are performed via 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.


Is this something that would change at different levels? Service Level Objective (SLO) targets feel like something that would make more sense at the IPSIE level vs at the protocol level if we want to define these.

Maybe the best way to handle this is to introduce SLOs in IPSIE IL3 and for SCIM IL1 Profile we can cut the "5 min" requirements

Alternatively, we can include SLOs in the common requirements.

mcguinness · 2025-05-04T06:06:17Z

IL1-SCIM.md

+The Application MUST provide support all User provisioning operations defined in this section.
+
+#### 3.2.3 Create User (POST /Users)
+User creation is performed by the SCIM operation POST /Users


Is there any required attributes or constraints we need to enforce?

Should externalId be set to the same value as the assertion subject identifier?

Should email or userName be required to enable account linking if there is no externalId?

Should active be required to support lifecycle operations needed by IPSIE

Should we define standard mappings for SAML and OIDC schemas to SCIM?

Should we explicitly disallow the use of password? I know Okta sets this value to a secure random in case the app supports a backdoor login mechanism outside of SSO

We need to discuss whether or not to use standard naming conventions or to provide a mapping to allow client and server to discover the naming conventions used by the other and map fields accordingly. Right now SCIM leaves this too open ended leading to interop challenges. I look forward to hearing others' thoughts on the best path forward.

My worry with making attribute names standardized is it killing adoption. Maybe thats something we introduce at IL2/IL3?

We need a minimum profile to enable the use cases at SL1 (e.g externalId and active. We can also provide standard mappings but not require the attributes to be required.

Added the following (requirements regarding certain types of attributes, but did not specify what the attribute's name must be. Note: active is already required by RFC 7643):

In addition to the user attributes required by RFC 7643, the following attributes are required to be part of the account schema:

An attribute which contains a unique identifier used by the enterprise to distinguish the owner of the account, such as "externalId."

An attribute which contains the primary email address of the user, such as "email"

mcguinness · 2025-05-04T06:10:33Z

IL1-SCIM.md

+### 3.3 Group (Role) Provisioning Operations
+The Application MUST provide support all Group provisioning operations defined in this section.
+
+**Note**: Within the IPSIE standard, Application permissions are referred to as "Roles." Within SCIM, Application permissions are referred to as "Groups." The term "Role" in IPSIE is functionally equivalent to the term "Group" in SCIM.


I had a different understanding. Groups may act as Roles but Apps are free to have Groups and Roles as separate entities. Groups can be assigned to Roles but so can individual users.

We'll also get into the discussion of entitlements, further muddying the terminology if we're not careful. At IETF122 @aaronpk mentioned that the entitlements draft was being resurrected. I've seen no updates yet.

Based on the IPSIE IL definitions, my understanding is that "Role" is the term used for any application permissions - role does not mean bundling of numerous permissions together (although that is a common definition - role and group are both overloaded terms. I maintain "Entitlement" is a better choice than either, but that would require us updating the IPSIE IL definition)

mcguinness · 2025-05-04T06:16:52Z

IL1-SCIM.md

+User creation is performed by the SCIM operation POST /Users
+
+#### 3.2.4 Update User (PATCH /Users/{id})
+User updates are performed via the SCIM operation: PATCH /Users/{id}


Any requirements needed for users that were created via SSO JIT but now need to be managed identities via SCIM?

Since IPSIE says nothing about the JIT process, we need a way to discover these users via SCIM, and then put them under management by SCIM.

This is a good point - I think I need to add a requirement for GET /Users to return all users

Section 3.2.7 now addresses this

How can a client specifically identify a JITed user without having to page through all of the users? I think about Amazon - they onboard thousands of people daily during peak season, and then offboard them at the end of the season. At scale, they wouldn't be able to reconcile all the JITed users due to the rate of change of the users in the application. Synchronization would be difficult to impossible.

I have lots of questions about this, but no good answers.

Knowing whether an user is managed by the IdP or not and remediating is a key use case IMHO for IPSIE. Can we define any required behaviors around externalId or do we need some new attribute? If we can define the behavior as an attribute then you can query for that result set (e.g all users NOT managed by IdP)

mcguinness · 2025-05-04T06:29:33Z

IL1-SCIM.md

+* The Application shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644.
+* All SCIM operations shall be authenticated via OAuth 2.0; local modifications are prohibited.
+
+### 3.2.2 User Provisioning Operations


For brownfield apps, the Identity Service often needs to audit the RP by importing and reconciling the existing identities in the app with the identities in the IdP. This requires paging through all the users and groups. We should define the mechanism a SCIM Server must support for an Identity Service to import/audit large user or group collections. There are several SCIM extensions that could be useful but today are not guaranteed. This is a huge interop challenge today.

Agreed. The cursor based pagination work will be helpful here, but we really need to work with the SCIM WG to drive the delta-query mechanism to completion. Scaling SCIM demands improved tooling for anti-entropy mechanisms.

Completely agree

Delta Query puts a lot of implementation requirements on the RP. I think SL1 should just support cursor paged pagination with lastUpdated timestamps and standardize how rate limits should work. This should significantly address the interop gaps while providing a lowest level in implementation requirements for the RO

I worry that if we make cursor based pagination required for IL1 it will harm adoption. I updated the profile to include the following:

3.2.7 Get All Users (GET /Users)

A search for all users in the system are performed by the SCIM operation: GET /Users

This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service.

To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded.

...

3.3.1 Get All Groups (GET /Groups)

A search for all groups in the system are performed by the SCIM operation: GET /Groups

This endpoint ensures that any all groups can be managed by the Identity Service.

To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded.

I am concerned that this allows optionality (cursor vs. index), and that index-based pagination is known to have issues that impact anti-entropy/reconciliation at scale.

Cursor based pagination will be an RFC soon - it's in the publication queue. I may be biased because of my work on that draft, but I would prefer to see services implement cursor based pagination since it's going to be a pre-requisite to any delta query mechanism, whenever that gets defined.

I would prefer we require cursor and not have optionality as index doesn't scale with user counts and creates more interoperability challenges. RPs can encode a cheap, simple opaque cursor-based paging system from an index-based one such as base64 of the offset

I also think we need to define some required behaviors around rate-limiting. Together this was probably a top 3 SCIM interop challenge from my experience. Punting on this or pushing to configuration doesn't help ecosystem.

mcguinness · 2025-05-06T07:12:32Z

IL1-SCIM.md

+* externalId eq {externalId}
+* emails[value eq {email}]
+
+### 3.3 Group (Role) Provisioning Operations


Need to define audit operation to list all members of a group and how to handle large datasets (e.g page). Identity Server needs to onboard brownfield app as well as ensure no drift between system of record and app

Need to define how to remove a group (e.g https://openid.net/specs/fastfed-scim-1_0-02.html#SCIMInteroperabilityGroupProvisioningDeactivateGroup)

I think creation / removal of groups is out of scope for IL1 and would argue its also out of scope for ipsie. Most Applications I know of manage groups internally and use their IAM controls to aggregate those groups and manage membership. However, in my experience, it is very rare to seen group creation managed through an IAM tool in the wild and would be an unrealistic requirement for IL1.

mcguinness · 2025-05-06T07:12:59Z

IL1-SCIM.md

+# 4.0 Security Considerations
+For SCIM security considerations, see RFC 7643 and RFC 7644. 
+
+Additionally, the following security considerations must be included:


Need to define interoperability for rate-limiting

Updated to include Rate Limiting requirements

mcguinness · 2025-05-06T07:14:20Z

IL1-SCIM.md

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


Need to define schemas that are required such as Enterprise User

Not fully sure what was being asked on this one. For now I updated it to include:

There must be a schema for both Users and Groups. The schemas must include all required attributes from RFC 7643 and from Section 3.2.3 (Create User).

dhs-BI · 2025-05-06T15:09:47Z

IL1-SCIM.md

+
+# 2.0 Conventions and Definitions
+The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.
+


We'll want to normalize these to IETF style language using uppercase terminology in a future version.

Just went through and capitalized

dhs-BI · 2025-05-06T15:11:13Z

IL1-SCIM.md

+## 2.2 Roles
+* **Identity Service**: Acts as the SCIM Client, initiating all provisioning operations.
+* **Application**: Acts as the SCIM Service, hosting SCIM endpoints and processing all provisioning requests.
+


Although SCIM uses these terms, there's a draft of use cases that covers a much richer set of interaction styles. We should consider whether or not to include references to those more complex patterns here as well. https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases-reloaded/

I think sticking with "Application" and "Identity Service" will help with understandability, that draft looks like it introduces a lot of new language which has not been discussed in any IPSIE meetings to date

Fair enough.

Is there ever a scenario where the App will be the client and the Identity service the service? I'm thinking about IL2/3 and the mapping of app specific roles to groups where the app may want to push those to the identity service.

dhs-BI · 2025-05-06T15:12:49Z

IL1-SCIM.md

+* The Identity Service shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644.
+* The Application shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644.
+* All SCIM operations shall be authenticated via OAuth 2.0; local modifications are prohibited.
+


s/authenticated/authorized/ on line 42

Fix per Karl's comment. Auth will use JWT Client Authentication, not JWT Authorization Grant.

Updated to address Karl's comment on "All of the Authorization Server parameters should be discovered from OAuth Authorization Server metadata"

Updated to make OAuth 2.0 Requirements section and to include reference to RFC 8414

Updated to include a list of what needs to be revoked when an account is suspended to address comment "Suspending an account needs to have stronger guarantee on what is revoked"

Updated to address Karl's comment "We need a minimum profile to enable the use cases at SL1 (e.g externalId and active. We can also provide standard mappings but not require the attributes to be require"

Updated to address Karl's comment, "Any requirements needed for users that were created via SSO JIT but now need to be managed identities via SCIM?"

Updated Get All Users to include: To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded.

Updated to include rate limiting requirements

Updating to say both the User and Group schema definitions are required

Updating capitalization

Updated to say OAuth 2.0 is required for authentication and authorization

deansaxe

First pass review, these changes look good and move us toward a doc that could be adopted by the WG.

deansaxe · 2025-07-16T16:24:31Z

IL1-SCIM.md

+User creation is performed by the SCIM operation POST /Users
+
+#### 3.2.4 Update User (PATCH /Users/{id})
+User updates are performed via the SCIM operation: PATCH /Users/{id}


How can a client specifically identify a JITed user without having to page through all of the users? I think about Amazon - they onboard thousands of people daily during peak season, and then offboard them at the end of the season. At scale, they wouldn't be able to reconcile all the JITed users due to the rate of change of the users in the application. Synchronization would be difficult to impossible.

I have lots of questions about this, but no good answers.

SCIM updates

amonika230995 · 2025-08-29T07:07:23Z

IL1-SCIM.md

+* 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 {{authn-authz}}.
+* Local modifications to Users or Groups in the Application are prohibited.


"Local modifications to Users or Groups in the Application are prohibited" - But generally this is not the case right? SCIM does not mandate whether local admins inside the application can or cannot make changes. There can be scenarios where the customer wants to maintain additional information for a user or a group , or they would want to maintain derived or computed attributes?

amonika230995 · 2025-08-29T07:08:46Z

IL1-SCIM.md

+
+In addition to the user attributes required by {{RFC7643}}, the following attributes are required to be part of the User schema:
+
+// TODO: Should we keep this vauge or refer be explicit with attributes we are requiring? email vs emails?


My recommendation would be to explicitly restrict some basic or core attribute name , similar to openid scopes - profile, email etc.,

amonika230995 · 2025-08-29T07:30:09Z

IL1-SCIM.md

+
+* When the op is "add":
+  * The path attribute MUST be "members".
+  * The value attribute MUST be an array of Group member elements, as defined in Section 4.2 of the SCIM Core Schema {{RFC7643}}. Each member MUST contain a value subattribute with the id of the resource being added to the group.


Each member MUST contain a value sub attribute with the id of the resource being added to the group. - probably an example could help here? The sentence is a bit confusing.

Create IL1-SCIM.md

e1d38b4

dhs-BI requested review from aaronpk and dhs-BI May 2, 2025 20:10

dhs-BI added the il1 label May 2, 2025

mcguinness reviewed May 3, 2025

View reviewed changes

mcguinness reviewed May 4, 2025

View reviewed changes

mcguinness reviewed May 6, 2025

View reviewed changes

dhs-BI reviewed May 6, 2025

View reviewed changes

dhs-BI mentioned this pull request May 8, 2025

FAL2 - storage of subscriber attributes/deprovisioning #83

Closed

2MarkMaguire added 9 commits June 4, 2025 18:30

Update IL1-SCIM.md

f0b1a0b

Fix per Karl's comment. Auth will use JWT Client Authentication, not JWT Authorization Grant.

Update IL1-SCIM.md

c6b8b51

Updated to address Karl's comment on "All of the Authorization Server parameters should be discovered from OAuth Authorization Server metadata"

Update IL1-SCIM.md

f790d08

Updated to make OAuth 2.0 Requirements section and to include reference to RFC 8414

Update IL1-SCIM.md

6b5097e

Updated to include a list of what needs to be revoked when an account is suspended to address comment "Suspending an account needs to have stronger guarantee on what is revoked"

Update IL1-SCIM.md

e0fa084

Updated to address Karl's comment "We need a minimum profile to enable the use cases at SL1 (e.g externalId and active. We can also provide standard mappings but not require the attributes to be require"

Update IL1-SCIM.md

54489f3

Updated to address Karl's comment, "Any requirements needed for users that were created via SSO JIT but now need to be managed identities via SCIM?"

Update IL1-SCIM.md

9d09103

Updated to include rate limiting requirements

Update IL1-SCIM.md

d898107

Updating to say both the User and Group schema definitions are required

2MarkMaguire added 2 commits July 15, 2025 13:50

Update IL1-SCIM.md

758aa08

Updating capitalization

Update IL1-SCIM.md

1738321

Updated to say OAuth 2.0 is required for authentication and authorization

deansaxe reviewed Jul 16, 2025

View reviewed changes

jen-schreiber-wd and others added 5 commits July 20, 2025 20:19

initial review with todos

ebe01f9

add create groups

50afcc0

add filter requirement for groups

80e7f22

capitalization

4c5c605

Merge pull request #1 from 2MarkMaguire/jens-updates

162041c

SCIM updates

amonika230995 reviewed Aug 29, 2025

View reviewed changes


		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. The revocation mechanism is an implementation detail outside the scope of this specification. Revocation SHOULD occur within 5 minutes of receiving the deactivation.


		The Application MUST allow reactivation of a deactivated user.

		#### 3.2.6 Delete User (DELETE /Users/{id})


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

		#### 3.4.3 /Schemas


		# 2.0 Conventions and Definitions
		The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.


		In addition to the user attributes required by {{RFC7643}}, the following attributes are required to be part of the User schema:

		// TODO: Should we keep this vauge or refer be explicit with attributes we are requiring? email vs emails?

Create IL1-SCIM.md #72

Are you sure you want to change the base?

Create IL1-SCIM.md #72

Uh oh!

Conversation

2MarkMaguire commented May 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2MarkMaguire Jun 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcguinness May 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcguinness May 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

2MarkMaguire Jun 4, 2025 •

edited

Loading

mcguinness May 4, 2025 •

edited

Loading

mcguinness May 4, 2025 •

edited

Loading