Oracle

Pleasanton CA United States of America saurabh.kushwaha@oracle.com

Security SCIM SCIM identity provisioning multi-tenancy tenant isolation This document defines a System for Cross-domain Identity Management (SCIM) extension for tenant-aware identity provisioning. The extension introduces a "Tenant" resource type, tenant-membership extensions for the "User" and "Group" resources, a lifecycle state machine for tenants and memberships, tenant-scoped uniqueness discovery, a normative tenant-context resolution rule built around the highest-precedence authenticated indicator together with a stated tenant-binding invariant, concurrency requirements for membership mutation, tenant-aware filtering, and an OPTIONAL region-aware metadata profile. The extension is backward compatible with SCIM 2.0 and is intended for multi-tenant Software as a Service (SaaS), cloud identity, business-to-business identity, identity governance, and multi-region identity deployments. Scoped role and entitlement bindings are delegated to the SCIM Roles and Entitlements and RoleAssignment work rather than redefined here.

Introduction The System for Cross-domain Identity Management (SCIM) 2.0 standardizes provisioning of identity resources between an identity provider and a service provider. SCIM defines "User" and "Group" resource types, an extension mechanism based on schema URIs, and a protocol with endpoints for resource discovery and lifecycle. SCIM resources are represented in JSON . SCIM does not define a portable "Tenant" resource. , Section 1.1 acknowledges that a service provider may be multi-tenant and lists deployment techniques for conveying tenant context (URL prefix, subdomain, HTTP header, authentication context), but does not specify a "Tenant" resource type, a tenant-membership schema, a tenant-scoped uniqueness model, a tenant lifecycle model, or a normative rule for resolving tenant context when more than one tenant indicator is present and the indicators disagree. The SCIM use cases describe multi-tenant deployment topologies but likewise do not define an on-the-wire tenant resource or a context-resolution rule. In practice, each identity platform fills the gap proprietarily. The same logical concept (tenant, organization, identity domain, workspace, customer account) is therefore not portable across SCIM endpoints. In zero-trust deployments , where authorization is evaluated continuously, an ambiguous or stale tenant context is itself a security liability, which raises the importance of a precise tenant-resolution rule. This document proposes a backward-compatible SCIM 2.0 extension that closes this gap. The contribution of this document is the portability of the tenant concept through SCIM and the precise, security-relevant rules that govern it: a tenant resource and membership model, a context-resolution rule with a stated invariant, a lifecycle state machine, and a tenant-scoped uniqueness model. This document does not invent tenancy and does not require identity platforms to abandon their internal representations; it defines a vendor-neutral abstraction layer.

Relationship to Other SCIM Work This extension is intended to compose with, not duplicate, other SCIM resource and extension work:

Roles and entitlements:

The discovery of which roles and entitlements a service provider accepts, including values that vary per customer or tenant, is addressed by . Portable, scoped role bindings of the form "subject has role R in scope S" (where S MAY be a tenant) are addressed by the RoleAssignment work , whose scope type "tenant" references a Tenant defined by this document. Accordingly, this document does NOT carry tenant-local roles or entitlements on the membership object; see . Implementations that require scoped role bindings SHOULD use RoleAssignment with a scope that references a Tenant "id" defined here.

Use cases:

Multi-tenant deployment topologies and reconciliation flows are described in . This document provides the schema and protocol surface those topologies require.

Core resources:

This document extends the "User" and "Group" resources of and adds the "Tenant" resource type. It does not modify the core schema or protocol and is additive in the sense of , Section 4.

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 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout the document:

Tenant:

A logical administrative boundary within a service provider. A Tenant corresponds to an organization, customer account, workspace, realm, identity domain, or SaaS tenant.

Tenant context:

The Tenant to which a SCIM request applies.

Tenant indicator:

A signal in a SCIM request that conveys tenant intent. Indicators are one of: a JWT or OAuth access-token claim, a URL path segment, an HTTP header, a request-host subdomain, or a field in the request body.

Authenticated tenant indicator:

A tenant indicator whose integrity is cryptographically bound to the request, such that a network-positioned adversary cannot alter it without detection. By default, the only authenticated indicator is the access-token claim of .

Tenant-scoped resource:

A SCIM resource whose ownership function maps it to exactly one Tenant. Tenants own Users, Groups, Memberships, and (transitively) their members and attributes.

Authorized tenant set:

The set of Tenants for which a SCIM client holds at least one authorization grant for at least one operation.

Effective tenant (T*):

The single Tenant to which a request is resolved by the rule of .

Service provider:

A SCIM service provider as defined in .

Schema URIs This document defines four SCIM schema URIs: The Tenant resource is a new resource type and therefore uses a primary schema URI in the "core" namespace, consistent with , Section 10 and with the convention adopted by other new SCIM resource types. The two membership schemas extend existing resource types and therefore use the "extension" namespace. These URIs are requested for registration in the IANA "SCIM Schema URIs" registry; see .

Tenant Resource A Tenant resource is exposed at the SCIM endpoint "/Tenants".

Endpoints A service provider implementing this extension SHALL support the following endpoints with the semantics defined in : DELETE is subject to the cascade rules of .

Attributes The Tenant resource has the following attributes. Each entry below follows , Section 2.2. Unless otherwise noted, the type is "string", "multiValued" is false, "required" is false, "caseExact" is false, "mutability" is "readWrite", "returned" is "default", and "uniqueness" is "none".

id:

Type string. Required true. Mutability readOnly. Returned always. Uniqueness server. A unique, stable, non-reassignable identifier assigned by the service provider. Compared octet-by-octet; see .

externalId:

Type string. Uniqueness server. A client-supplied identifier; see , Section 3.1.

displayName:

Type string. Required true. A human-readable name for the Tenant.

status:

Type string. Required true. Canonical values "active", "suspended", "archived", "pending". Transitions are governed by .

type:

Type string. Canonical values "customer", "partner", "internal", "workspace", "organization".

domains:

Complex multi-valued. Each entry has sub-attributes "value" (string, required, the FQDN), "primary" (boolean; at most one entry MAY be true), and "verified" (boolean, readOnly; true if and only if the service provider has independently verified domain ownership). FQDN comparison follows .

homeRegion:

Type string. Optional. Identifier of the Tenant's home region. Present only when the region profile (see ) is supported.

regions:

Complex multi-valued. Optional. Present only when the region profile is supported. Sub-attributes are defined in .

meta:

Complex. Required. ReadOnly. As defined in , Section 3.1. "meta.resourceType" SHALL be the string "Tenant". "meta.version" SHALL be supported to enable the concurrency control of .

Example

Tenant Membership Extension for User The Tenant Membership extension for User is identified by the URI "urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User".

Attributes

memberships:

Complex multi-valued. ReadWrite. Each entry represents the user's relationship to one Tenant. Sub-attributes:

• "value" (string, required, readWrite): the referenced Tenant's "id".
• "$ref" (reference, required, readOnly, referenceTypes=["Tenant"]): the URI "/Tenants/{id}".
• "status" (string, required, readWrite): canonical values "active", "suspended", "invited", "pending", "deactivated". Transitions are governed by .
• "primary" (boolean, readWrite): at most one entry MAY be true.

This object intentionally does NOT carry tenant-local "roles" or "entitlements". Scoped role and entitlement bindings are expressed using RoleAssignment with a scope that references the Tenant "id", and the set of available roles and entitlements is discovered using . This avoids re-encoding scope into role strings and keeps a single interoperable mechanism for scoped authorization data. See .

Effective State A user's effective state in Tenant "t" is determined by composing the core user state, the tenant state, and the membership state, in this order:

1. If core "User.active" is false, the effective state is "inactive" in every Tenant.
2. Otherwise, if "Tenant(t).status" is "suspended" or "archived", the effective state is "inactive" in "t" regardless of membership status.
3. Otherwise, the effective state is derived from "membership.status" for the matching membership: "active" is active; "suspended" and "deactivated" are inactive; "invited" and "pending" are inactive until activation.
4. If no membership exists for "t", the user has no presence in "t", and SCIM operations targeting "t" for that user SHALL be rejected with HTTP 404.

Example

Tenant Membership Extension for Group The Tenant Membership extension for Group is identified by the URI "urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:Group".

Attributes

value:

Type string. Required when "scope = tenant". Mutability readWrite. The owning Tenant's "id".

$ref:

Type reference. ReferenceTypes ["Tenant"]. Required when "scope = tenant". Mutability readOnly. The URI "/Tenants/{id}".

scope:

Type string. Required. Mutability readWrite. Canonical values "tenant", "global".

Constraints Tenant-scoped groups SHALL belong to exactly one Tenant. A client SHALL NOT create a Group with "scope = tenant" and no "value". Cross-tenant Group membership is not modeled; cross-tenant collaboration is expressed at the User level via multiple memberships.

ServiceProviderConfig Extension A service provider implementing this extension SHALL advertise its tenant-related capabilities through "/ServiceProviderConfig", using the schema URI "urn:ietf:params:scim:schemas:extension:multiTenancy:2.0:ServiceProviderConfig".

Attributes

multiTenancy:

Complex. Required. Mutability readOnly. Sub-attributes:

• "supported" (boolean): true if and only if the service provider supports any portion of this extension.
• "tenantResourceSupported" (boolean): true if and only if "/Tenants" is available.
• "tenantMembershipSupported" (boolean): true if and only if the user and group membership extensions are supported.
• "tenantAwareFilteringSupported" (boolean): true if and only if filters referencing membership attributes are supported.
• "tenantScopedUniquenessSupported" (boolean): true if and only if tenant-scoped uniqueness is configurable for natural-key attributes.
• "regionAwareTenancySupported" (boolean): true if and only if the region profile is implemented.
• "tenantSelectionMethods" (string, multi-valued): the indicator methods the service provider accepts. Values are drawn from "tokenClaim", "path", "header", "subdomain", "body".
• "tenantSelectionPrecedence" (string, multi-valued): an ordered list of methods denoting their precedence. The default order is ["tokenClaim", "path", "header", "subdomain", "body"].
• "authenticatedSelectionMethods" (string, multi-valued): the subset of "tenantSelectionMethods" the service provider treats as authenticated (see ). The default value is ["tokenClaim"].
• "tenantClaim" (string): the JWT claim name carrying tenant context. Default "tenant_id".
• "tenantHeader" (string): the HTTP header field name carrying tenant context. Default "SCIM-Tenant-Id".
• "tenantScopedUniqueness" (complex): a record of which natural keys are scoped to Tenant rather than server. Sub-attributes are attribute names ("userName", "externalId", "groupDisplayName") mapped to the string "tenant" or "server".

Example

Tenant Context Resolution This section defines a single rule that resolves a request to one effective Tenant "T*" and states the invariant the rule preserves. The rule subsumes both indicator precedence and indicator-conflict handling; the two are not independent mechanisms.

Resolution Rule and Binding Invariant Let TI(q) be the set of present, canonicalized () tenant indicators in request q, and let A(q) be the subset of TI(q) that the service provider treats as authenticated (by default, the access-token claim only; see "authenticatedSelectionMethods"). The service provider SHALL resolve and admit a request as follows: Step (1) is the authorization gate. Step (2) is the cross-check that prevents a lower-precedence (possibly spoofable) indicator from silently redirecting the request. Because T* is taken from the highest-precedence authenticated indicator whenever one is present, effective context is never derived from a spoofable source when an authenticated indicator exists. Each rule preserves the invariant: derivation sets the effective tenant to T*; step (1) ensures authorization for T*; step (2) ensures no other indicator disagrees; and canonicalization () ensures the comparisons in (2) are sound. Implementations SHALL evaluate the gate and cross-check in a way that does not leak tenant existence or authorization; see .

Rejection and Error Uniformity When a request is not admissible, the service provider SHALL respond as follows:

• If the client is not authorized for T* (step (1) fails), the service provider SHALL return HTTP 404 and SHALL return a response that is indistinguishable from the response for a nonexistent Tenant (see ). The service provider SHALL NOT reveal that an indicator conflict occurred.
• If the client is authorized for T* but a lower-precedence indicator disagrees (step (2) fails), the service provider SHALL return HTTP 400 with a SCIM error response with "scimType = invalidValue". Such a response MAY identify T* (for which the client is authorized) but MUST NOT echo any conflicting tenant identifier for which the client is not authorized.

Because the 400 conflict response is reachable only after the authorization gate for T* has been passed, it does not act as an existence or authorization oracle for any other Tenant.

Identifier Canonicalization Before comparison under , each indicator is mapped to a Tenant "id" and normalized:

• A "tokenClaim", "path", "header", or "body" indicator carries a Tenant "id" directly. Tenant "id" values are compared octet-by-octet (case-sensitive); the service provider SHALL NOT apply case folding or Unicode normalization to "id".
• A "subdomain" indicator carries an FQDN that is mapped to a Tenant "id" through the verified "domains" of a Tenant. FQDNs are compared after lowercasing, removal of any trailing dot, and conversion of any internationalized labels to their A-label (Punycode) form. An unverified domain SHALL NOT resolve a tenant context.

If an indicator cannot be mapped to a Tenant "id" (for example, an unrecognized subdomain), it is treated as not resolving to any Tenant; the request is then handled as in with respect to T*.

Multi-Tenant Administrative Clients A single client (for example, an identity-governance administrator) may be authorized for many Tenants under one access token. Such a token cannot name a single Tenant in "tenant_id". To support this case:

• If the access token asserts an authorized tenant set rather than a single Tenant, the token claim does not by itself fix T*. A(q) is then empty for the purpose of , and T* is taken from the highest-precedence present indicator in TI(q).
• The resolved T* SHALL be a member of the token's authorized tenant set; otherwise the authorization gate (step (1)) fails and applies. This preserves the Tenant Binding Invariant: T* remains constrained by an authenticated grant even though it is not named by an authenticated indicator.

Token Claim A service provider that consumes OAuth 2.0 access tokens or JWT-profile access tokens SHALL accept a JWT claim named "tenant_id" of type string. The claim value SHALL be the SCIM Tenant "id" the client asserts as the request's tenant context. A service provider MAY additionally accept implementation-specific claims (for example, "tid" for compatibility with deployed ecosystems) and SHALL advertise the primary accepted claim in "ServiceProviderConfig.multiTenancy.tenantClaim". When multiple claims carrying tenant context are present in a single token, the claim named by "tenantClaim" SHALL take precedence.

HTTP Header Field When an HTTP header-field indicator is used, the canonical field name is "SCIM-Tenant-Id" and its value is the Tenant "id". The field name follows the structured-naming guidance of , Section 16.3.2 and is registered as a provisional HTTP field name; see . The header field is a tenant-context indicator only and, unless it is listed in "authenticatedSelectionMethods", SHALL NOT be treated as authenticated.

Precedence Configuration The default precedence is ["tokenClaim", "path", "header", "subdomain", "body"], reflecting that a signed access-token claim is cryptographically bound to the request through OAuth bearer presentation , while URL path, header, subdomain, and body are mutable by intermediaries or by the client. Implementations MAY alter the precedence per deployment. Any deviation from the default SHALL be reflected in "ServiceProviderConfig.multiTenancy.tenantSelectionPrecedence", and any deviation from the default authenticated set SHALL be reflected in "authenticatedSelectionMethods". A service provider SHALL NOT place an unauthenticated indicator ahead of an authenticated one in a way that would allow an unauthenticated indicator to determine T* while an authenticated indicator is present.

Lifecycle State Machine This section specifies the permissible states and transitions for the Tenant resource and for User memberships, and the cascade effects of Tenant transitions on memberships. Service providers SHALL reject transitions not listed here with HTTP 400 and "scimType = invalidValue".

Tenant States Tenant status transitions

From	To	Effect
(create)	pending, active	Initial state on POST.
pending	active	Tenant becomes operational.
pending	archived	Abandoned before activation.
active	suspended	Members become inactive (); resources retained.
suspended	active	Members' effective state recomputed from membership status.
active, suspended	archived	Terminal-soft state; read-only; members inactive.
archived	(DELETE)	Permitted subject to .

While a Tenant is "suspended" or "archived", the service provider SHALL reject state-changing operations on resources owned by that Tenant with HTTP 409 and "scimType = mutability", except operations that themselves transition the Tenant status.

Membership States Membership status transitions

From	To	Notes
(create)	invited, pending, active	Initial state on membership add.
invited	pending, active, deactivated	Invitation accepted or withdrawn.
pending	active, deactivated	Provisioning completed or abandoned.
active	suspended, deactivated	Temporary or permanent removal of presence.
suspended	active, deactivated	Reinstatement or permanent removal.
deactivated	active	Re-activation; permitted only while the Tenant is "active".
(any)	(remove)	Removing the membership ends the user's presence in the Tenant; see .

Tenant Deletion and Cascade A service provider SHALL NOT silently cascade-delete Users or Groups when a Tenant is deleted. On "DELETE /Tenants/{id}":

1. If the Tenant owns any tenant-scoped Group or any User whose only membership is in this Tenant, the service provider SHALL reject the request with HTTP 409 and "scimType = uniqueness" unless the client supplies an explicit cascade indication that the service provider documents and advertises. This prevents accidental destruction of identities.
2. For a User with memberships in other Tenants, deletion of this Tenant SHALL remove only the membership entry that references this Tenant; the User resource is retained.
3. A Tenant SHOULD be in status "archived" before deletion.

Concurrency and PATCH Semantics Membership "status" is security-relevant: it gates a user's presence and effective state in a Tenant. Concurrent modification of memberships is therefore a correctness and security concern, not only a convenience.

Optimistic Concurrency Service providers SHALL support resource versioning via "meta.version" and HTTP entity-tags as described in , Section 3.14 and , Section 8.8.3. A client that mutates a membership (adds, replaces, or removes a membership entry, or changes "membership.status") SHOULD supply an "If-Match" precondition. A service provider SHALL reject a membership-mutating request whose "If-Match" precondition does not match the current version with HTTP 412. A service provider MAY require the precondition and reject a membership-mutating request that omits "If-Match" with HTTP 428 . These requirements prevent lost-update races that could otherwise reinstate or escalate a user's presence in a Tenant.

PATCH Targeting of Memberships A single membership is targeted in a PATCH operation using a value-path filter per , Section 3.5.2, with the schema URI prefix. For example, to suspend a user's membership in one Tenant: An "op" of "remove" whose path selects an entire membership entry (for example, "...:memberships[value eq \"tenant-acme\"]") ends the user's presence in that Tenant; subsequent operations targeting that Tenant for that user are handled per , item 4. A service provider SHALL reject a PATCH that would leave two membership entries referencing the same Tenant with HTTP 409 and "scimType = uniqueness".

Tenant-Aware Filtering A service provider that sets "tenantAwareFilteringSupported = true" SHALL accept SCIM filters referencing extension attributes per , Section 3.4.2.2. The schema URI is separated from the attribute path by a colon: Tenant-aware filtering is a convenience for clients and is never the isolation boundary. Regardless of any filter, a service provider SHALL scope results to the client's authorized tenant set and SHALL NOT return resources owned by a Tenant for which the client is not authorized ().

Tenant-Scoped Uniqueness and Backward Compatibility This section specifies how tenant-scoped uniqueness interacts with the "uniqueness = server" constraint of on attributes such as "userName". The notion that "externalId" is interpreted relative to a tenant has long-standing precedent in SCIM; this section generalizes the idea and makes it discoverable. A service provider MAY scope uniqueness of "userName", "externalId", and "Group.displayName" to Tenant rather than to server. When it does so it SHALL advertise the scope in "ServiceProviderConfig.multiTenancy.tenantScopedUniqueness". The contract with clients is preserved as follows:

1. Single-tenant clients interact with exactly one Tenant per SCIM endpoint binding (typically via a tenant-specific base URL). Within that binding, "userName" appears server-unique because the binding pins tenant context.
2. A client SHALL NOT see resources from a Tenant for which it is not authorized. Even if two Tenants contain users with identical "userName", an unaware single-tenant client observes at most one of them.
3. The resource identifier "id" and "meta.location" remain server-unique and uniquely addressable. This document SHALL NOT weaken "id" uniqueness on "User", "Group", or "Tenant".

Cross-tenant clients require an explicit contract. When a client is authorized for more than one Tenant and queries a natural key that is tenant-scoped (for example, "GET /Users?filter=userName eq \"alex\""), the service provider MAY return more than one matching resource across the client's authorized Tenants. Such clients SHOULD constrain natural-key queries with a tenant predicate (for example, a "memberships.value" term or the tenant context of ) to obtain a single result, and MUST NOT assume that a natural-key match is unique across Tenants. A deployment migrating from "server" to "tenant" uniqueness MUST first verify that no Tenant pair contains conflicting natural keys, and SHOULD perform the migration while the affected Tenants are in status "suspended" to avoid concurrent creation of conflicting keys.

Region-Aware Tenant Metadata (Optional Profile) This profile is OPTIONAL and addresses data residency and active/passive replication topology, which are largely orthogonal to the core tenant model. It is documented here for completeness and MAY be moved to a companion document; see . A service provider that does not implement multi-region tenancy SHALL set "regionAwareTenancySupported = false" and SHALL NOT include "homeRegion" or "regions" on Tenant resources.

Tenant.regions Sub-Attributes

region:

Type string. Required. Region identifier (deployment-specific).

mode:

Type string. Required. Canonical values "readWrite", "readOnly", "authenticationOnly", "unavailable".

status:

Type string. Mutability readOnly. Canonical values "available", "degraded", "unavailable".

writeAuthority:

Type boolean. Required. Mutability readOnly. At most one region per Tenant SHALL have "writeAuthority = true".

Region Write Authority Rule When "regions" is present, a service provider SHALL reject a state-changing operation if the receiving region has "writeAuthority = false" for the resolved Tenant. The rejection SHALL return HTTP 409 with "scimType = mutability" and a "Link" header field to the home region's SCIM root, per the discovery semantics of , Section 4.

Example

Normative Behavior Summary A service provider that claims conformance to this document:

• MUST expose tenant capability metadata through "/ServiceProviderConfig".
• MUST resolve each request to a single effective Tenant T* per and preserve the Tenant Binding Invariant.
• MUST NOT derive effective context from an unauthenticated indicator when an authenticated indicator is present.
• MUST respond to an unauthorized-Tenant request indistinguishably from a nonexistent-Tenant request (), and MUST NOT let conflict handling act as an existence or authorization oracle.
• MUST NOT return tenant-scoped resources from a Tenant for which the SCIM client is not authorized, regardless of any filter.
• MUST enforce the lifecycle transitions of and MUST NOT silently cascade-delete identities on Tenant deletion.
• MUST support "meta.version" and reject stale membership-mutating requests per .
• MUST reject region-bypass writes when the region profile is implemented and the receiving region lacks write authority.
• SHOULD support tenant-aware filtering for "Users", "Groups", and "Tenants".
• SHOULD advertise tenant-scoped uniqueness rules.
• MAY accept implementation-specific tenant claims for compatibility and MUST advertise the primary accepted claim name.

Security Considerations

Threat Model The threat model assumes a network-positioned adversary that may craft arbitrary HTTP requests including any combination of tenant indicators, that holds valid credentials for some subset of Tenants, that cannot forge signatures of the trusted OAuth issuer, that cannot break TLS confidentiality or integrity, and that may observe response codes, bodies it is authorized to receive, and response timing. The named attack classes are:

1. Indicator confusion: induce a state mutation for a Tenant whose authenticated context disagrees with another indicator.
2. Cross-tenant access: read or mutate a resource owned by a Tenant for which the adversary is not authorized.
3. Unauthorized membership: create a membership in a Tenant for which the adversary is not authorized.
4. Region bypass: cause a write to commit at a region with "writeAuthority = false".
5. Lost-update escalation: use a concurrent membership update to reinstate or escalate presence in a Tenant.

Why the Rules Hold Resistance to attack classes 1-3 reduces to the Tenant Binding Invariant of : every committed state-changing operation acts on T*, and the client is authorized for T*. Indicator confusion (class 1) is prevented because T* is taken from the highest-precedence authenticated indicator when one is present, and step (2) rejects any disagreement; an adversary cannot move effective context to a Tenant other than the one named by an indicator it can authenticate. Cross-tenant access and unauthorized membership (classes 2-3) are prevented by the authorization gate, step (1), which is evaluated for T* before any state change. Region bypass (class 4) is prevented by the write-authority rule of . Lost-update escalation (class 5) is prevented by the concurrency requirements of . These are argued as invariant-preservation properties rather than proved formally; a formal symbolic model is identified as future work in .

Indicator Trust The default precedence places the token claim first because it is cryptographically bound to the request. An implementation that downgrades this ordering MUST justify the change in a deployment-specific threat model and MUST reflect the change in "tenantSelectionPrecedence" and "authenticatedSelectionMethods". A service provider SHALL NOT accept an unsigned tenant claim from any indicator that is not authenticated as if it were authenticated.

Tenant Enumeration A service provider SHALL respond identically to requests for an unauthorized Tenant and a nonexistent Tenant, returning HTTP 404 with no body content that distinguishes the two cases. Differential timing between the two paths SHOULD be minimized; constant-time existence checks are RECOMMENDED for tenant lookup.

Error Message Leakage Error responses MUST NOT echo Tenant identifiers from indicators that resolved to Tenants the client is not authorized for. As specified in , conflict-rejection (400) responses are reachable only after the authorization gate for T* has passed, and SHALL describe the conflict without revealing any tenant identifier for which the client is unauthorized.

Side-Channel Timing Tenant-scoped uniqueness checks MAY leak existence via response-time variance. Service providers SHOULD apply constant-time comparison or response-time padding for natural-key uniqueness probes that occur during create operations.

Audit Scoping Audit events SHALL be scoped to the Tenant the event affects. Cross-tenant administrative audit views SHALL be restricted to clients explicitly authorized for cross-tenant administration.

Region Metadata Exposure When the region profile is enabled, "Tenant.regions" reveals deployment topology and failover posture. This metadata SHOULD be exposed only to clients with administrative authorization for the Tenant.

Privacy Considerations

Membership Disclosure Tenant membership reveals customer, partner, employment, or administrative relationships. Service providers SHALL apply least-privilege response shaping. A client authorized only for Tenant "t" SHALL NOT receive memberships of the same User in Tenants other than "t".

Attribute Minimization "ListResponses" from "/Tenants" SHOULD by default return only "id", "displayName", and "status". Per-Tenant user counts, membership counts, and similar aggregate properties MUST NOT be returned unless explicitly requested by a suitably authorized administrative client.

Data Residency and Cross-Border Transfer When the region profile is implemented, "homeRegion" and "regions" metadata may correspond to the lawful basis under which the Tenant's personal data is processed. Service providers SHOULD ensure that the "homeRegion" of a Tenant is consistent with the data-residency commitment made to the Tenant's data controller; that cross-region replication is governed by an appropriate data-transfer mechanism, including but not limited to Standard Contractual Clauses under , Articles 44 through 49, or equivalent mechanisms in other regimes; and that the exposure of "Tenant.regions" is consistent with data-subject rights under the applicable regime.

Cross-Tenant Analytics Aggregate analytics across Tenants SHALL NOT be exposed through SCIM endpoints. Such analytics are out of scope of this document.

IANA Considerations

SCIM Schema URIs This document requests registration of the following entries in the "SCIM Schema URIs" registry maintained by IANA. The reference for each entry is this document.

urn:ietf:params:scim:schemas:core:2.0:Tenant

Name: Tenant

urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User

Name: User Tenant Membership

urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:Group

Name: Group Tenant Membership

urn:ietf:params:scim:schemas:extension:multiTenancy:2.0:ServiceProviderConfig

Name: Multi-Tenancy ServiceProviderConfig

SCIM Resource Types This document requests registration of the following entry in the "SCIM Resource Types" registry. The reference is this document.

Name:

Tenant

Endpoint:

/Tenants

Schema:

urn:ietf:params:scim:schemas:core:2.0:Tenant

JSON Web Token Claims This document requests registration of the following claim in the "JSON Web Token Claims" registry per , Section 10.1. Because tenant identifiers are deployment-specific and several equivalent claims are already deployed, the registration is requested as provisional, with the expectation that the SCIM and OAuth communities confirm or revise the name before any permanent registration.

Claim Name	Claim Description	Change Controller	Reference
tenant_id	The SCIM Tenant id asserted as request context	IETF	This document,

HTTP Field Name This document requests provisional registration of the HTTP field name "SCIM-Tenant-Id" in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" per , Section 16.3.1, with status "provisional", a reference to this document, and the field semantics of .

Open Issues for Working Group Discussion The following items are expected to receive WG attention.

• Whether the region-aware profile () should be a separate companion document, for example "draft-kushwaha-scim-tenant-regions".
• Whether tenant hierarchy (parent/child Tenants) should be in scope or deferred.
• Confirmation of the canonical-value sets and transitions in .
• The precise relationship to RoleAssignment and Roles/Entitlements , including whether a Tenant should be a registered RoleAssignment scope type.
• Whether a formal symbolic model (for example, in a Tamarin or ProVerif style) of the resolution rule and the Tenant Binding Invariant should accompany this document.
• Whether "tenantClaim" should permit a multi-valued list of accepted claim names rather than a single primary, and whether a new IETF claim is warranted versus profiling an existing claim.

Normative References Informative References European Parliament and Council

Acknowledgments The author thanks the IETF SCIM Working Group for prior work on and , and the broader identity community for ongoing discussions on multi-tenant provisioning.

Change Log draft-kushwaha-scim-tenant-resource-00: Initial submission. This revision, relative to the author's working draft, incorporates the following substantive changes:

• Set the document stream to IETF with intended status Standards Track (the prior "independent + standards-track" combination was inconsistent).
• Added positioning this work against RoleAssignment, Roles and Entitlements, and the SCIM use cases, and removed tenant-local "roles"/"entitlements" from the User membership object in favor of RoleAssignment.
• Replaced the separate "precedence" and "conflict" rules with a single resolution rule based on the highest-precedence authenticated indicator and added the Tenant Binding Invariant ().
• Closed the conflict/enumeration oracle by making the 400 conflict response reachable only after the authorization gate ().
• Added identifier canonicalization () and handling of multi-tenant administrative clients ().
• Added an explicit lifecycle state machine with cascade and deletion rules ().
• Added concurrency and PATCH-targeting requirements for membership mutation ().
• Specified the cross-tenant-client contract for tenant-scoped uniqueness ().
• Corrected the Tenant primary schema URI to the "core" namespace and added an HTTP field-name registration; softened the JWT claim registration to provisional ().