SCIM Extension for Tenant-Aware Identity Provisioning
draft-kushwaha-scim-tenant-resource-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Saurabh Kushwaha | ||
| Last updated | 2026-08-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kushwaha-scim-tenant-resource-00
SCIM S. Kushwaha
Internet-Draft Oracle
Intended status: Standards Track 25 August 2026
Expires: 26 February 2027
SCIM Extension for Tenant-Aware Identity Provisioning
draft-kushwaha-scim-tenant-resource-00
Abstract
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.
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 26 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kushwaha Expires 26 February 2027 [Page 1]
Internet-Draft Tenant-Aware SCIM August 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship to Other SCIM Work . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Schema URIs . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Tenant Resource . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Tenant Membership Extension for User . . . . . . . . . . . . 8
5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Effective State . . . . . . . . . . . . . . . . . . . . . 9
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Tenant Membership Extension for Group . . . . . . . . . . . . 10
6.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 11
7. ServiceProviderConfig Extension . . . . . . . . . . . . . . . 11
7.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Tenant Context Resolution . . . . . . . . . . . . . . . . . . 12
8.1. Resolution Rule and Binding Invariant . . . . . . . . . . 13
8.2. Rejection and Error Uniformity . . . . . . . . . . . . . 13
8.3. Identifier Canonicalization . . . . . . . . . . . . . . . 14
8.4. Multi-Tenant Administrative Clients . . . . . . . . . . . 14
8.5. Token Claim . . . . . . . . . . . . . . . . . . . . . . . 15
8.6. HTTP Header Field . . . . . . . . . . . . . . . . . . . . 15
8.7. Precedence Configuration . . . . . . . . . . . . . . . . 15
9. Lifecycle State Machine . . . . . . . . . . . . . . . . . . . 16
9.1. Tenant States . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Membership States . . . . . . . . . . . . . . . . . . . . 16
9.3. Tenant Deletion and Cascade . . . . . . . . . . . . . . . 17
10. Concurrency and PATCH Semantics . . . . . . . . . . . . . . . 17
10.1. Optimistic Concurrency . . . . . . . . . . . . . . . . . 18
10.2. PATCH Targeting of Memberships . . . . . . . . . . . . . 18
11. Tenant-Aware Filtering . . . . . . . . . . . . . . . . . . . 18
12. Tenant-Scoped Uniqueness and Backward Compatibility . . . . . 19
13. Region-Aware Tenant Metadata (Optional Profile) . . . . . . . 20
13.1. Tenant.regions Sub-Attributes . . . . . . . . . . . . . 20
Kushwaha Expires 26 February 2027 [Page 2]
Internet-Draft Tenant-Aware SCIM August 2026
13.2. Region Write Authority Rule . . . . . . . . . . . . . . 20
13.3. Example . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Normative Behavior Summary . . . . . . . . . . . . . . . . . 21
15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 22
15.2. Why the Rules Hold . . . . . . . . . . . . . . . . . . . 22
15.3. Indicator Trust . . . . . . . . . . . . . . . . . . . . 23
15.4. Tenant Enumeration . . . . . . . . . . . . . . . . . . . 23
15.5. Error Message Leakage . . . . . . . . . . . . . . . . . 23
15.6. Side-Channel Timing . . . . . . . . . . . . . . . . . . 23
15.7. Audit Scoping . . . . . . . . . . . . . . . . . . . . . 23
15.8. Region Metadata Exposure . . . . . . . . . . . . . . . . 24
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
16.1. Membership Disclosure . . . . . . . . . . . . . . . . . 24
16.2. Attribute Minimization . . . . . . . . . . . . . . . . . 24
16.3. Data Residency and Cross-Border Transfer . . . . . . . . 24
16.4. Cross-Tenant Analytics . . . . . . . . . . . . . . . . . 24
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
17.1. SCIM Schema URIs . . . . . . . . . . . . . . . . . . . . 25
17.2. SCIM Resource Types . . . . . . . . . . . . . . . . . . 25
17.3. JSON Web Token Claims . . . . . . . . . . . . . . . . . 25
17.4. HTTP Field Name . . . . . . . . . . . . . . . . . . . . 26
18. Open Issues for Working Group Discussion . . . . . . . . . . 26
19. Normative References . . . . . . . . . . . . . . . . . . . . 26
20. Informative References . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
The System for Cross-domain Identity Management (SCIM) 2.0 [RFC7643]
[RFC7644] 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 [RFC8259].
Kushwaha Expires 26 February 2027 [Page 3]
Internet-Draft Tenant-Aware SCIM August 2026
SCIM does not define a portable "Tenant" resource. [RFC7644],
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
[I-D.ietf-scim-use-cases-reloaded] 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 [NIST-SP-800-207], 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.
1.1. 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
[I-D.ietf-scim-roles-entitlements]. 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
[I-D.poreddy-scim-role-assignment], 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 Section 5. Implementations that require
scoped role bindings SHOULD use RoleAssignment with a scope that
references a Tenant "id" defined here.
Kushwaha Expires 26 February 2027 [Page 4]
Internet-Draft Tenant-Aware SCIM August 2026
Use cases: Multi-tenant deployment topologies and reconciliation
flows are described in [I-D.ietf-scim-use-cases-reloaded]. This
document provides the schema and protocol surface those topologies
require.
Core resources: This document extends the "User" and "Group"
resources of [RFC7643] and adds the "Tenant" resource type. It
does not modify the core schema or protocol and is additive in the
sense of [RFC7643], Section 4.
2. 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.
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 Section 8.5.
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 Section 8.
Service provider: A SCIM service provider as defined in [RFC7644].
Kushwaha Expires 26 February 2027 [Page 5]
Internet-Draft Tenant-Aware SCIM August 2026
3. Schema URIs
This document defines four SCIM schema URIs:
urn:ietf:params:scim:schemas:core:2.0:Tenant
urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User
urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:Group
urn:ietf:params:scim:schemas:extension:multiTenancy:2.0:ServiceProviderConfig
The Tenant resource is a new resource type and therefore uses a
primary schema URI in the "core" namespace, consistent with
[RFC7643], 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 Section 17.
4. Tenant Resource
A Tenant resource is exposed at the SCIM endpoint "/Tenants".
4.1. Endpoints
A service provider implementing this extension SHALL support the
following endpoints with the semantics defined in [RFC7644]:
GET /Tenants (list/search)
GET /Tenants/{id} (read)
POST /Tenants (create)
PUT /Tenants/{id} (replace)
PATCH /Tenants/{id} (modify)
DELETE /Tenants/{id} (delete; see lifecycle rules)
DELETE is subject to the cascade rules of Section 9.
4.2. Attributes
The Tenant resource has the following attributes. Each entry below
follows [RFC7643], 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 Section 8.3.
Kushwaha Expires 26 February 2027 [Page 6]
Internet-Draft Tenant-Aware SCIM August 2026
externalId: Type string. Uniqueness server. A client-supplied
identifier; see [RFC7643], 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
Section 9.
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 Section 8.3.
homeRegion: Type string. Optional. Identifier of the Tenant's home
region. Present only when the region profile (see Section 13) is
supported.
regions: Complex multi-valued. Optional. Present only when the
region profile is supported. Sub-attributes are defined in
Section 13.
meta: Complex. Required. ReadOnly. As defined in [RFC7643],
Section 3.1. "meta.resourceType" SHALL be the string "Tenant".
"meta.version" SHALL be supported to enable the concurrency
control of Section 10.
4.3. Example
Kushwaha Expires 26 February 2027 [Page 7]
Internet-Draft Tenant-Aware SCIM August 2026
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Tenant"
],
"id": "tenant-acme",
"externalId": "customer-1001",
"displayName": "Acme Corporation",
"status": "active",
"type": "customer",
"domains": [
{"value": "acme.example.com", "primary": true, "verified": true}
],
"meta": {
"resourceType": "Tenant",
"version": "W/\"a330bc54f0671c9\"",
"location": "https://sp.example.com/scim/v2/Tenants/tenant-acme"
}
}
5. 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".
5.1. 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 Section 9.
* "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 [I-D.poreddy-scim-role-assignment] with a scope
that references the Tenant "id", and the set of available roles and
entitlements is discovered using [I-D.ietf-scim-roles-entitlements].
This avoids re-encoding scope into role strings and keeps a single
interoperable mechanism for scoped authorization data. See
Section 1.1.
Kushwaha Expires 26 February 2027 [Page 8]
Internet-Draft Tenant-Aware SCIM August 2026
5.2. 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.
5.3. Example
Kushwaha Expires 26 February 2027 [Page 9]
Internet-Draft Tenant-Aware SCIM August 2026
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User"
],
"id": "user-123",
"userName": "alex@example.com",
"active": true,
"urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User": {
"memberships": [
{
"value": "tenant-acme",
"$ref": "/Tenants/tenant-acme",
"status": "active",
"primary": true
},
{
"value": "tenant-contoso",
"$ref": "/Tenants/tenant-contoso",
"status": "suspended",
"primary": false
}
]
}
}
6. 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".
6.1. 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".
Kushwaha Expires 26 February 2027 [Page 10]
Internet-Draft Tenant-Aware SCIM August 2026
6.2. 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.
7. 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".
7.1. 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 Section 2). 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".
Kushwaha Expires 26 February 2027 [Page 11]
Internet-Draft Tenant-Aware SCIM August 2026
* "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".
7.2. Example
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig",
"urn:ietf:params:scim:schemas:extension:multiTenancy:2.0:ServiceProviderConfig"
],
"urn:ietf:params:scim:schemas:extension:multiTenancy:2.0:ServiceProviderConfig": {
"multiTenancy": {
"supported": true,
"tenantResourceSupported": true,
"tenantMembershipSupported": true,
"tenantAwareFilteringSupported": true,
"tenantScopedUniquenessSupported": true,
"regionAwareTenancySupported": true,
"tenantSelectionMethods": [
"tokenClaim","path","header","subdomain","body"
],
"tenantSelectionPrecedence": [
"tokenClaim","path","header","subdomain","body"
],
"authenticatedSelectionMethods": ["tokenClaim"],
"tenantClaim": "tenant_id",
"tenantHeader": "SCIM-Tenant-Id",
"tenantScopedUniqueness": {
"userName": "tenant",
"externalId": "tenant",
"groupDisplayName": "tenant"
}
}
}
}
8. 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.
Kushwaha Expires 26 February 2027 [Page 12]
Internet-Draft Tenant-Aware SCIM August 2026
8.1. Resolution Rule and Binding Invariant
Let TI(q) be the set of present, canonicalized (Section 8.3) 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:
T* = value of the highest-precedence element of A(q), if A(q) is
non-empty; otherwise the highest-precedence element of TI(q).
A request is ADMISSIBLE if and only if:
(1) the client is authorized for T*, AND
(2) for every indicator i in TI(q): canonicalize(i) = T*.
Tenant Binding Invariant:
For any operation that commits a state change, the effective tenant
equals T*, and the client holds an authorization grant for T*.
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 (Section 8.3) 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
Section 15.5.
8.2. 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 Section 15.4). The service provider SHALL NOT reveal
that an indicator conflict occurred.
Kushwaha Expires 26 February 2027 [Page 13]
Internet-Draft Tenant-Aware SCIM August 2026
* 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.
8.3. Identifier Canonicalization
Before comparison under Section 8.1, 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 Section 8.2 with respect to
T*.
8.4. 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 Section 8.1, and T* is taken from
the highest-precedence present indicator in TI(q).
Kushwaha Expires 26 February 2027 [Page 14]
Internet-Draft Tenant-Aware SCIM August 2026
* The resolved T* SHALL be a member of the token's authorized tenant
set; otherwise the authorization gate (step (1)) fails and
Section 8.2 applies. This preserves the Tenant Binding Invariant:
T* remains constrained by an authenticated grant even though it is
not named by an authenticated indicator.
8.5. Token Claim
A service provider that consumes OAuth 2.0 [RFC6749] access tokens or
JWT-profile access tokens [RFC9068] 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.
8.6. 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 [RFC9110], Section 16.3.2
and is registered as a provisional HTTP field name; see Section 17.
The header field is a tenant-context indicator only and, unless it is
listed in "authenticatedSelectionMethods", SHALL NOT be treated as
authenticated.
8.7. 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 [RFC6750], 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.
Kushwaha Expires 26 February 2027 [Page 15]
Internet-Draft Tenant-Aware SCIM August 2026
9. 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".
9.1. Tenant States
+===========+=================+====================================+
| 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 |
| | | (Section 5.2); resources retained. |
+-----------+-----------------+------------------------------------+
| suspended | active | Members' effective state |
| | | recomputed from membership status. |
+-----------+-----------------+------------------------------------+
| active, | archived | Terminal-soft state; read-only; |
| suspended | | members inactive. |
+-----------+-----------------+------------------------------------+
| archived | (DELETE) | Permitted subject to Section 9.3. |
+-----------+-----------------+------------------------------------+
Table 1: Tenant status transitions
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.
9.2. Membership States
+=============+==================+===============================+
| From | To | Notes |
+=============+==================+===============================+
| (create) | invited, | Initial state on membership |
| | pending, active | add. |
+-------------+------------------+-------------------------------+
| invited | pending, active, | Invitation accepted or |
| | deactivated | withdrawn. |
Kushwaha Expires 26 February 2027 [Page 16]
Internet-Draft Tenant-Aware SCIM August 2026
+-------------+------------------+-------------------------------+
| pending | active, | Provisioning completed or |
| | deactivated | abandoned. |
+-------------+------------------+-------------------------------+
| active | suspended, | Temporary or permanent |
| | deactivated | removal of presence. |
+-------------+------------------+-------------------------------+
| suspended | active, | Reinstatement or permanent |
| | deactivated | 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 Section 10.2. |
+-------------+------------------+-------------------------------+
Table 2: Membership status transitions
9.3. 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.
10. 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.
Kushwaha Expires 26 February 2027 [Page 17]
Internet-Draft Tenant-Aware SCIM August 2026
10.1. Optimistic Concurrency
Service providers SHALL support resource versioning via
"meta.version" and HTTP entity-tags as described in [RFC7644],
Section 3.14 and [RFC9110], 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
[RFC6585]. These requirements prevent lost-update races that could
otherwise reinstate or escalate a user's presence in a Tenant.
10.2. PATCH Targeting of Memberships
A single membership is targeted in a PATCH operation using a value-
path filter per [RFC7644], Section 3.5.2, with the schema URI prefix.
For example, to suspend a user's membership in one Tenant:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User:memberships[value eq \"tenant-acme\"].status",
"value": "suspended"
}
]
}
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 Section 5.2, 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".
11. Tenant-Aware Filtering
A service provider that sets "tenantAwareFilteringSupported = true"
SHALL accept SCIM filters referencing extension attributes per
[RFC7644], Section 3.4.2.2. The schema URI is separated from the
attribute path by a colon:
Kushwaha Expires 26 February 2027 [Page 18]
Internet-Draft Tenant-Aware SCIM August 2026
GET /Users?filter=
urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:User:
memberships.value eq "tenant-acme"
GET /Groups?filter=
urn:ietf:params:scim:schemas:extension:tenantMembership:2.0:Group:
value eq "tenant-acme"
GET /Tenants?filter=status eq "active"
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 (Section 14).
12. Tenant-Scoped Uniqueness and Backward Compatibility
This section specifies how tenant-scoped uniqueness interacts with
the "uniqueness = server" constraint of [RFC7643] 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 [RFC7644] 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
Kushwaha Expires 26 February 2027 [Page 19]
Internet-Draft Tenant-Aware SCIM August 2026
\"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 Section 8) 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.
13. 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 Section 18. A service provider
that does not implement multi-region tenancy SHALL set
"regionAwareTenancySupported = false" and SHALL NOT include
"homeRegion" or "regions" on Tenant resources.
13.1. 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".
13.2. 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 [RFC7644],
Section 4.
13.3. Example
Kushwaha Expires 26 February 2027 [Page 20]
Internet-Draft Tenant-Aware SCIM August 2026
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Tenant"
],
"id": "tenant-acme",
"displayName": "Acme Corporation",
"status": "active",
"homeRegion": "region-a",
"regions": [
{"region":"region-a","mode":"readWrite",
"status":"available","writeAuthority":true},
{"region":"region-b","mode":"authenticationOnly",
"status":"available","writeAuthority":false}
],
"meta": {
"resourceType": "Tenant",
"location": "https://sp.example.com/scim/v2/Tenants/tenant-acme"
}
}
14. 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
Section 8 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 (Section 15.4), 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 Section 9 and MUST NOT
silently cascade-delete identities on Tenant deletion.
* MUST support "meta.version" and reject stale membership-mutating
requests per Section 10.
* MUST reject region-bypass writes when the region profile is
implemented and the receiving region lacks write authority.
Kushwaha Expires 26 February 2027 [Page 21]
Internet-Draft Tenant-Aware SCIM August 2026
* 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.
15. Security Considerations
15.1. 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.
15.2. Why the Rules Hold
Resistance to attack classes 1-3 reduces to the Tenant Binding
Invariant of Section 8.1: 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
Kushwaha Expires 26 February 2027 [Page 22]
Internet-Draft Tenant-Aware SCIM August 2026
(class 4) is prevented by the write-authority rule of Section 13.2.
Lost-update escalation (class 5) is prevented by the concurrency
requirements of Section 10.1. These are argued as invariant-
preservation properties rather than proved formally; a formal
symbolic model is identified as future work in Section 18.
15.3. 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.
15.4. 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.
15.5. 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 Section 8.2, 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.
15.6. 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.
15.7. 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.
Kushwaha Expires 26 February 2027 [Page 23]
Internet-Draft Tenant-Aware SCIM August 2026
15.8. 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.
16. Privacy Considerations
16.1. 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".
16.2. 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.
16.3. 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
[GDPR], 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.
16.4. Cross-Tenant Analytics
Aggregate analytics across Tenants SHALL NOT be exposed through SCIM
endpoints. Such analytics are out of scope of this document.
17. IANA Considerations
Kushwaha Expires 26 February 2027 [Page 24]
Internet-Draft Tenant-Aware SCIM August 2026
17.1. 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
17.2. 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
17.3. JSON Web Token Claims
This document requests registration of the following claim in the
"JSON Web Token Claims" registry per [RFC7519], 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 | Claim | Change | Reference |
| Name | Description | Controller | |
+===========+=================+============+=============+
| tenant_id | The SCIM Tenant | IETF | This |
| | id asserted as | | document, |
| | request context | | Section 8.5 |
+-----------+-----------------+------------+-------------+
Table 3
Kushwaha Expires 26 February 2027 [Page 25]
Internet-Draft Tenant-Aware SCIM August 2026
17.4. 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 [RFC9110], Section 16.3.1, with status
"provisional", a reference to this document, and the field semantics
of Section 8.6.
18. Open Issues for Working Group Discussion
The following items are expected to receive WG attention.
* Whether the region-aware profile (Section 13) 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
Section 9.
* The precise relationship to RoleAssignment
[I-D.poreddy-scim-role-assignment] and Roles/Entitlements
[I-D.ietf-scim-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.
19. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Kushwaha Expires 26 February 2027 [Page 26]
Internet-Draft Tenant-Aware SCIM August 2026
[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <https://www.rfc-editor.org/info/rfc7643>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
20. Informative References
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
Kushwaha Expires 26 February 2027 [Page 27]
Internet-Draft Tenant-Aware SCIM August 2026
[I-D.ietf-scim-roles-entitlements]
Zollner, D. and U. Vartak, "SCIM Roles and Entitlements
Extension", Work in Progress, Internet-Draft, draft-ietf-
scim-roles-entitlements-01, October 2025,
<https://datatracker.ietf.org/doc/draft-ietf-scim-roles-
entitlements/>.
[I-D.poreddy-scim-role-assignment]
Poreddy, P., "SCIM RoleAssignment Draft Specification",
Work in Progress, Internet-Draft, draft-poreddy-scim-role-
assignment-01, November 2025,
<https://datatracker.ietf.org/doc/draft-poreddy-scim-role-
assignment/>.
[I-D.ietf-scim-use-cases-reloaded]
Correia, P. and P. Dingle, "System for Cross-domain
Identity Management: Definitions, Overview, Concepts, and
Requirements", Work in Progress, Internet-Draft, draft-
ietf-scim-use-cases-reloaded-02, January 2026,
<https://datatracker.ietf.org/doc/draft-ietf-scim-use-
cases-reloaded/>.
[NIST-SP-800-207]
Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
"Zero Trust Architecture", NIST SP 800-207, August 2020,
<https://doi.org/10.6028/NIST.SP.800-207>.
[GDPR] European Parliament and Council, "Regulation (EU) 2016/679
(General Data Protection Regulation)", OJ L 119, April
2016, <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
Acknowledgments
The author thanks the IETF SCIM Working Group for prior work on
[RFC7643] and [RFC7644], 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).
Kushwaha Expires 26 February 2027 [Page 28]
Internet-Draft Tenant-Aware SCIM August 2026
* Added Section 1.1 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
(Section 8).
* Closed the conflict/enumeration oracle by making the 400 conflict
response reachable only after the authorization gate
(Section 8.2).
* Added identifier canonicalization (Section 8.3) and handling of
multi-tenant administrative clients (Section 8.4).
* Added an explicit lifecycle state machine with cascade and
deletion rules (Section 9).
* Added concurrency and PATCH-targeting requirements for membership
mutation (Section 10).
* Specified the cross-tenant-client contract for tenant-scoped
uniqueness (Section 12).
* Corrected the Tenant primary schema URI to the "core" namespace
and added an HTTP field-name registration; softened the JWT claim
registration to provisional (Section 17).
Author's Address
Saurabh Kushwaha
Oracle
Pleasanton, CA
United States of America
Email: saurabh.kushwaha@oracle.com
Kushwaha Expires 26 February 2027 [Page 29]