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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . 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, . 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, . [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, . [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, . [NIST-SP-800-207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST SP 800-207, August 2020, . [GDPR] European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation)", OJ L 119, April 2016, . 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]