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

[Danny Zollner <[e-mail]>]

I've had various conversations about this over the last few years and
representing the multi-valued attribute as a (sub)resource has always ended
up looking like a cleaner option than the SCIM query/filter-based methods
described in draft-hunt-scim-mv-filtering-00 and in the recent email to
this mailing list by Saurabh. Going deeper on the multi-valued attribute as
a (sub)resource approach, there are a few different ideas that have come to
mind:


   1. A draft to explicitly address group memberships, as that's the
   primary real world scenario I've seen where SCIM resource sizes become too
   large to manage. I've seen some other APIs represent group memberships as
   their own resource (e.g.: /GroupMembers) and I think that has value in SCIM
   as well when thinking about things like delta query/change detection. I
   think /Groups/<id>/members is useful too and can exist alongside
   /GroupMembers without issue.

   2. A draft to explicitly address existing attributes defined in the SCIM
   specifications - the members attribute on groups, but also potentially
   roles, entitlements, the "groups" attribute on users (and other
   resources?), etc.

   3. A draft to define an extensible approach to representing a
   multi-valued attribute as a sub-resource endpoint (e.g.:
   /Users/<id>/entitlements, or /Users/<id>/<customAttributeURN>


Separate from the sub-resource approach, a few other ideas that have come
up in my discussions:


   - Define a way to paginate a SCIM resource that treats the JSON object
   representing the SCIM resource as the thing to be paginated, rather than
   the list of values in an array for a specific multi-valued attribute. This
   has the benefit of helping with pagination on a resource with several
   multi-valued attributes that each require pagination, and with
   single-valued attributes that have large values.

   - Utilize an existing feature in HTTP (or another standard). I'm not an
   expert on HTTP, but Chunked Transfer Encoding stood out when I was looking
   into this.


I lean towards option #1 or #3 from the list of subresource representation
variations.

Thanks,

Danny



On Thu, Jan 29, 2026 at 11:58 AM Phillip Hunt <[e-mail]>
wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> There was a mult-value paging extension draft submitted back in 2019.
>
> SCIM Protocol: Multi-Value Paging Extension
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hunt-scim-mv-paging/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6-0k6p4g$>
> datatracker.ietf.org
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hunt-scim-mv-paging/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6-0k6p4g$>
> [image: ietf-logo-nor-180.png]
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hunt-scim-mv-paging/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6-0k6p4g$>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hunt-scim-mv-paging/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6-0k6p4g$>
>
> This was basically adding paging features to the filter query so that
> queries like the following become possible:
>
> In the following example, all Groups are searched and only Groups
>    whose name starts with "Group" are selected.  Additionally, the
>    members attribute values are filtered return only member values with
>    "type" equal to "groups" (as in sub-groups) returning only the first
>    5 values using the attributes paging qualifying parameters.
> GET /v2/Groups?filter=displayName sw 'Group'&attributes=*,members[type
>       eq \"Group\"&count=5&startIndex=1]
>
>
> The draft had the advantage of being backwards compatible and was
> relatively stateless.
>
> One note, it’s not clear, but the first example in the draft of retrieving
> only work emails is to show existing core
> SCIM functionality.  The following example show how the extension of
> adding paging values, allows a client to
> ask for sub-sets of items.
>
> I think it was lost in the Covid shutdown that happened after.
>
> Cheers,
>
> Phil Hunt
> [e-mail]
>
>
>
>
>
>
> On Jan 29, 2026, at 6:32 AM, Daniel Cormier <[e-mail]>
> wrote:
>
> We've had the same problem getting groups with many members (some with
>
> 100k). For what it's worth, since it is an internal implementation,
>
> we added a new endpoint: GET /Groups/{id}/members. Our flow was to
> retrieve the group (GET /Groups/{id}) with its members excluded, then
> paginate through GET /Group/{id}/members separately. It worked well
> for our case.
>
> Some previous discussion around group member pagination:
>
> * <https://mailarchive.ietf.org/arch/msg/scim/YCcs_ZRWOo4HM8zxKbXlAi2Cpag/
> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/scim/YCcs_ZRWOo4HM8zxKbXlAi2Cpag/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6FvmOQQI$>
> >
> <-- Mentions the same solution we used
>  * <
> https://mailarchive.ietf.org/arch/msg/scim/67Bd0iotMoEx5rcjCUsHUzQzQGU/
> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/scim/67Bd0iotMoEx5rcjCUsHUzQzQGU/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc6CDlxIfw$>
> >
> * <https://mailarchive.ietf.org/arch/msg/scim/txBFAJgcxb0mhIi1Bp0jaL6t2WU/
> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/scim/txBFAJgcxb0mhIi1Bp0jaL6t2WU/__;!!PwKahg!-QXA_7ekr2W3bWqtyUF8mHPk4mH7F0m5NQfl7nBcUg1Cm1nCK8PiBBe0aaQTePX72wIdSK3Dlv7VJL_dJMc61biKnDQ$>
> >
>
> _______________________________________________
> scim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> scim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>