Independent

US prithvikrishnab4u@gmail.com

Applications and Real-Time (ART) SCIM SCIM 2.0 defines "roles" and "entitlements" attributes on the User resource, but it lacks a standardized way to bind roles to specific scopes such as projects, tenants, or groups. This gap forces organizations to rely on group sprawl or non-standard encodings, preventing true interoperability. This document introduces a new SCIM resource type, RoleAssignment, which models scoped role bindings as first-class records, enabling portable provisioning, lifecycle governance, and compliance visibility.

The SCIM protocol defines the User and Group resources and allows global roles to be attached to Users via the "roles" attribute. However, the specification does not provide a standardized way to associate roles with specific scopes such as projects, tenants, or device groups. This limitation prevents SCIM from modeling the most common real-world requirement: assigning different roles to the same identity in different contexts. For example, consider a user named Alice:

Today, there is no interoperable SCIM method to represent Alice's per-project role bindings. Current workarounds include creating Groups for every {scope x role} combination, which leads to group sprawl and poor interoperability, or embedding scope names into free-form role strings, which are not machine-readable or portable. These limitations are visible in real-world SCIM implementations: GitLab , Tanium , and scenarios in Microsoft Entra ID .

This document introduces a new SCIM 2.0 resource, RoleAssignment, which makes scoped role bindings a first-class concept. Each RoleAssignment explicitly links a subject (for example, User), a scope (for example, Project), and a role (for example, Developer). Optional metadata such as validity periods, source system, and approver information enable lifecycle management and governance. By standardizing RoleAssignments: Identity Providers can provision scoped roles in a portable way. Service Providers can expose and consume these assignments consistently. Auditors and governance systems can query "who has what role in which scope."

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 when, and only when, they appear in all capitals, as shown here.

The RoleAssignment resource complements existing SCIM resources. Whereas the User.roles attribute provides only coarse global roles, RoleAssignment expresses who (subject) has what role in which scope. This allows interoperable provisioning of scoped role bindings.

The RoleAssignment resource defines the following top-level attributes.

Attribute	Type	Req	Multi	Mutability	Description
id	string	yes	no	readOnly	Provider-assigned unique identifier.
externalId	string	no	no	readWrite	Client-supplied correlation id.
subject	complex	yes	no	readWrite	The subject receiving the role.
scope	complex	yes	no	readWrite	The scope where the role applies.
role	complex	yes	no	readWrite	The role granted within the scope.
priority	integer	no	no	readWrite	Conflict resolution (higher wins). Default 0.
grant	complex	no	no	readWrite	Assignment metadata (source, reason, approver).
validity	complex	no	no	readWrite	Validity window in UTC.
status	string	no	no	readOnly	Computed lifecycle status.

Priority usage guidance: When multiple active assignments exist for the same subject and scope, the assignment with the highest priority takes precedence. If priorities are equal, implementation-defined resolution rules apply.

Attribute	Type	Req	Multi	Mutability	Description
value	string	yes	no	readWrite	Identifier of the subject.
$ref	reference	no	no	readWrite	URI to the subject resource, when available.
type	string	no	no	readWrite	Subject type. Standard: "User", "Group". "ServiceAccount" MAY be used. Vendor-specific types SHOULD use prefixes.

Attribute	Type	Req	Multi	Mutability	Description
type	string	yes	no	readWrite	Scope type. Common: "project", "tenant", "organization", "application", "environment".
value	string	yes	no	readWrite	Provider-meaningful identifier of the scope.
$ref	reference	no	no	readWrite	URI to the scope resource, if available. Optional when scope is opaque.

Attribute	Type	Req	Multi	Mutability	Description
name	string	yes	no	readWrite	Display name of the role.
value	string	no	no	readWrite	Stable identifier for the role.
$ref	reference	no	no	readWrite	URI to a role catalog entry, if available. Providers with catalogs SHOULD include $ref for discovery.

Role Discovery Guidance: Since role.$ref is optional, servers SHOULD support filtering on role and scope to enable discovery, for example:

Providers that expose a role catalog MAY align discovery with the SCIM Roles and Entitlements approach .

Attribute	Type	Req	Multi	Mutability	Description
source	string	no	no	readWrite	Originating system or process.
reason	string	no	no	readWrite	Human-readable justification.
approver	string	no	no	readWrite	Approver identifier or reference.

Attribute	Type	Req	Multi	Mutability	Description
validFrom	dateTime	no	no	readWrite	Start of validity window (UTC).
validTo	dateTime	no	no	readWrite	End of validity window (UTC).

The "status" attribute is readOnly and computed using the following rules: If the referenced subject is inactive: status = "suspended". If current time < validity.validFrom: status = "pending". If current time > validity.validTo: status = "expired". Otherwise: status = "active". Special cases: If validity.validFrom is null, assignment is immediately eligible. If validity.validTo is null, assignment does not expire. If explicitly revoked via DELETE or PATCH: status = "revoked". Required status values: "active": assignment is currently effective. "expired": validity window has ended. "pending": assignment created but not yet effective. "suspended": subject inactive or assignment temporarily disabled. "revoked": assignment was explicitly withdrawn.

Create (POST): Servers MUST validate subject, scope, and role. Replace (PUT): Missing required attributes cause 400 Bad Request. Patch (PATCH): MUST be supported; invalid states SHOULD be rejected. Delete (DELETE): Removes assignment and SHOULD revoke permissions. Filter (GET): MUST support filters on subject, scope, role. Pagination/Sorting: MUST support startIndex and count; SHOULD support sorting. Bulk: MAY be supported. Clients SHOULD use externalId for idempotency.

400 Invalid Value for malformed attributes or invalid validity windows. 404 Not Found for unknown subject, scope, or role references. 409 Conflict for duplicate active assignments. 412 Precondition Failed for ETag mismatches on conditional updates. Error responses SHOULD include "detail" and "scimType" per .

Providers MAY continue to expose global roles via User.roles and coarse-grained membership via Groups. Providers SHOULD offer mapping guidance between legacy models and RoleAssignments. Dual-writing (maintaining both representations) is RECOMMENDED during migration.

RoleAssignment creation and modification are privileged operations. Servers MUST validate references to prevent privilege escalation. Lifecycle events SHOULD be logged with actor and justification. Replay and bulk abuse MUST be mitigated with rate limiting and idempotency.

RoleAssignments may expose organizational structures and access patterns. Sensitive metadata SHOULD follow least-privilege disclosure.

This specification requests registration of the following SCIM schema:

URNs are assigned and interpreted in accordance with .

MUST implement RoleAssignment and advertise it in /ResourceTypes. MUST validate subject, scope, and role. MUST enforce authorization on RoleAssignment operations. MUST support GET, POST, PUT, PATCH, DELETE, filtering. SHOULD support sorting and bulk operations.

MUST construct RoleAssignments per schema. MUST process error responses per . SHOULD use externalId for idempotency. SHOULD honor ETag preconditions.

Initial version. Defines RoleAssignment schema, attributes, and operations. Adds priority, complete example, error examples, and query patterns. Includes error handling, backward compatibility, and IANA registration. Updates BCP14 boilerplate; replaces non-ASCII; converts ASCII tables to RFCXML tables; updates Roles/Entitlements reference to -02; cites RFC8141.

Prithvi Poreddy<br/> Email: <prithvikrishnab4u@gmail.com>