[scim] Pagination Support for Multi-Valued Attributes in SCIM 2.0

[saurabh kushwaha <[e-mail]>]

Hi Team,

Please review my enchantment request.

Description

*1. Problem Statement*
The current SCIM 2.0 specification (RFC 7644, Section 3.4.2.4
<https://www.google.com/search?q=https://datatracker.ietf.org/doc/html/rfc7644%23section-3.4.2.4>)
defines pagination exclusively at the Resource level using startIndex and
count. While this manages the number of Resources (e.g., Groups) returned
in a ListResponse, it fails to address Multi-Valued Attributes (MVAs) that
may contain a high volume of sub-elements.
*Scenario:*
• A Service Provider (SP) has 10,000 Group resources.
• One specific Group contains 100,000 members.
• A client requesting this Group via GET /Groups/{id} or a filtered search
will receive a massive JSON payload because the specification provides no
standard mechanism to paginate the members attribute itself.

*2. Proposed Enhancement*
I propose an extension to the query syntax that allows clients to request
specific "slices" of multi-valued attributes. This could be achieved
through a new query parameter or an extension of the attributes parameter.

*Option A: Attribute-Specific Range Parameters*
Introduce a syntax that targets specific attributes for indexing: GET
/Groups/{id}?attrStartIndex=members:1&attrCount=members:100
Option B: Bracketed Indexing in attributes
GET /Groups/{id}?attributes=displayName,members[1-100]

*3. Impact Analysis*
• *Performance*: Drastically reduces memory overhead for both Identity
Providers (IdPs) and Service Providers (SPs) when dealing with "Large
Groups."
• *Reliability*: Prevents HTTP 504 (Gateway Timeout) and 413 (Payload Too
Large) errors during full-sync operations.
• *Backward Compatibility*: If the SP does not support attribute-level
pagination, it can default to the current behavior of returning the full
list (standard SCIM graceful degradation).
Thanks
Saurabh Kushwaha