Cursor-Based Pagination and Deferred Retrieval for Multi-Valued Attributes in SCIM 2.0

1.1. The Conformance Gap

[RFC7644] supports pagination of resources in a SCIM ListResponse. [RFC9865] adds cursor-based pagination for those resource collections. Neither mechanism bounds the values contained inside one resource.¶

[RFC7643] defines Group.members with returned: default. A client may therefore issue:¶

GET /Groups/2819c223-7f76-453a-919d-413861904646

and a conformant service provider is required to return the members attribute. [RFC7644] places no bound on how many values that attribute contains, and defines no mechanism by which a service provider may return fewer than all of them while remaining conformant.¶

For a group with two million members this leaves a service provider with no correct option. Every available behavior is either non-conformant or operationally unsafe:¶

Deployed service providers do all of these. A client has no way to determine which it will encounter, and no defined recovery when it encounters one. This is an interoperability defect in the protocol rather than a deficiency in any implementation.¶

Approaches that expose memberships through a separate address — an inverse filter over the counterpart resource (Section 16.8), a relationship resource type, or a per-attribute sub-resource endpoint (Section 16.4) — give clients good ways to enumerate memberships. None of them closes this gap, because Group.members remains defined with returned: default regardless of what other retrieval paths a provider offers, and clients continue to request it.¶

1.2. Operational Consequences

The same problem occurs for implementation-specific complex multi-valued attributes, particularly assignment attributes such as application grants and accounts, which represent access relationships rather than descriptive properties and grow with the size of the deployment rather than with the size of an individual record.¶

The problem has two distinct forms:¶

1. A collection search can return many parent resources, each of which can trigger an unbounded child or reference-derived query.¶

2. A resource-by-identifier request can return one attribute containing an unbounded number of values.¶

Applying a page size only after discovering or hydrating all values does not protect the system. The page boundary has to be applied to the first query that discovers the attribute values.¶

This document therefore defines two complementary behaviors:¶

• Deferred collection retrieval: a collection search returns parent resources without loading protected multi-valued attributes. Each affected resource contains metadata with a link to retrieve the attribute from that parent.¶

• Cursor-paged resource retrieval: a request for one parent and one protected multi-valued attribute returns a bounded first page and an opaque cursor when more values exist.¶

This model keeps the multi-valued attribute on its parent resource. It avoids introducing a new top-level resource type and avoids maintaining two independently mutable representations of the same relationship.¶

Attribute pagination does not imply snapshot isolation. Unless a service provider advertises stronger consistency, clients MUST tolerate values being added, removed, or reordered while a traversal is in progress.¶

4.1. Explicit and Automatic Modes

A service provider MAY support either or both of these modes:¶

Explicit mode¶

Attribute pagination is used only when the request contains attributeCount or attributeCursor. Other requests retain [RFC7644] behavior, subject to existing provider limits.¶

Automatic deferred mode¶

The service provider can defer protected attributes from collection results and apply a default page size to a resource-by-identifier request even when attributeCount is absent. This is analogous to [RFC9865] permitting a service provider to choose cursor pagination and a default page size when a resource-collection request omits cursor and count.¶

4.2. Deployment Compatibility

A new service provider MAY advertise automatic deferred mode as its default. An existing service provider adding this extension SHOULD preserve its legacy behavior until a compatibility profile has been established for affected clients or tenants.¶

ServiceProviderConfig advertisement alone does not prove that every existing client understands a partial attribute representation. Existing deployments SHOULD use a staged tenant or client profile, the in-band preference below, an out-of-band capability agreement, or another deployment-specific negotiation mechanism before enabling automatic deferred mode.¶

An extension-aware client MAY explicitly opt in by sending this [RFC7240] preference:¶

Prefer: scim-attribute-pagination=deferred

A provider that applies the preference SHOULD return:¶

Preference-Applied: scim-attribute-pagination=deferred

The absence of this preference does not request unsafe or unbounded behavior. A provider MAY still apply deferred mode through its advertised default and compatibility profile. An existing provider that has not established such a profile SHOULD retain legacy behavior or fail closed as described below.¶

If a provider cannot safely return an unbounded attribute and automatic deferred behavior has not been established for the client, it SHOULD fail closed with attributePaginationRequired rather than return a silently truncated representation or attempt unsafe unbounded retrieval.¶

This specification does not claim that automatic deferred mode is wire-compatible with clients that require a complete default attribute. For example, some deployed provisioning clients require a bare GET /Groups/{id} to return all members, or construct a subsequent PUT from a retrieved representation. Such clients require explicit migration, a legacy compatibility profile, or targeted PATCH behavior before automatic deferred mode is enabled.¶

6.1. attributeCount

attributeCount specifies the client's preferred maximum number of values from the selected protected attribute.¶

• The value MUST be a non-negative integer.¶

• The parameter is OPTIONAL for the first page.¶

• If omitted, the provider selects an effective page size.¶

• A provider MUST NOT return more values than the effective page size.¶

• A provider MAY return fewer values because of authorization, response-byte, query-time, or other safety limits.¶

• A value greater than the provider maximum MUST either be reduced to the maximum or rejected with invalidAttributeCount; the behavior SHOULD be advertised consistently.¶

• A value of zero requests no values. The provider MAY return an inexpensive totalResults, but a zero-size response does not create a traversable cursor.¶

When a client supplies attributeCount on a continuation request, it MUST match the effective page size bound into the cursor. A continuation request MAY omit attributeCount because the cursor already identifies that size.¶

6.2. attributeCursor

attributeCursor contains an opaque continuation value returned in the previous response.¶

• It MUST be omitted for the first page.¶

• It MUST NOT be interpreted or constructed by the client.¶

• It MUST contain URL-safe characters or be percent encoded.¶

• It MUST be scoped to the original request context.¶

• It SHOULD expire after a service-defined interval.¶

• It MUST NOT be accepted on a resource-collection endpoint.¶

6.3. Selecting an Attribute

The protected attribute is selected through the existing SCIM attributes parameter or through the default attribute-selection rules in [RFC7644].¶

Example with an explicit client preference:¶

GET /Groups/group-123?attributes=id,displayName,members&attributeCount=100

Example using the provider's default page size:¶

GET /Groups/group-123?attributes=id,displayName,members

attributeCursor applies to exactly one canonical protected attribute on exactly one parent resource. If a continuation request selects a different attribute, parent, projection, or other bound context, the provider MUST reject it.¶

8.1. Attribute Selection

The service provider first applies [RFC7644] attributes, excludedAttributes, schema returned characteristics, and authorization rules. It then applies attribute pagination only to selected and authorized protected attributes.¶

• If a protected attribute is excluded, no values and no pagination entry are returned.¶

• If the client is not authorized to discover the attribute, no pagination entry is returned.¶

• A provider MUST NOT use pagination metadata to reveal the existence, size, source mapping, or values of an unauthorized attribute.¶

• An attribute with returned: always MUST be returned and is not eligible for deferred mode.¶

8.2. Collection Search

For a collection search returning multiple parent resources, a provider using automatic deferred mode:¶

1. Retrieves the parent-resource page without invoking the loader, relationship query, exact count, or hydration path for any protected attribute.¶

2. Omits the selected protected attribute values from each resource.¶

3. Adds one attributePagination entry with state deferred for each selected protected attribute that can be retrieved for that parent.¶

4. Supplies a parent-specific firstPage URI-reference in every entry.¶

More than one protected attribute MAY be deferred on the same resource because deferral does not load any values. Root count, cursor, page, or startIndex parameters continue to control the number of parent resources and MUST NOT be interpreted as an attribute page size.¶

attributeCount and attributeCursor MUST NOT cause per-parent protected-attribute hydration on a collection endpoint. A provider MUST reject either attribute-level parameter on a collection endpoint with attributePaginationNotSupported. Root count and root cursor parameters remain valid and independent.¶

The provider SHOULD NOT issue an exact count query merely to decide whether a deferred descriptor is needed. Consequently, following firstPage can legitimately return an empty attribute page.¶

8.3. Resource-by-Identifier First Page

When a request addresses one parent resource and selects exactly one protected attribute for hydration, the provider:¶

1. Validates the parent and canonical attribute path.¶

2. Evaluates authorization for the parent, attribute, and visible values.¶

3. Chooses the effective page size from attributeCount or provider policy.¶

4. Determines a deterministic total order.¶

5. Retrieves no more than effectivePageSize + 1 candidate rows from the first query that discovers the values.¶

6. Removes the look-ahead row before child, CMVA, reference, or display-value hydration.¶

7. Returns no more than the effective page size.¶

8. Returns nextCursor only when the look-ahead row proves another page exists.¶

9. MAY calculate totalResults when it can do so within configured cost limits.¶

If more than one protected attribute is selected on a resource-by-identifier request, the provider MUST NOT hydrate all of them. It SHOULD return each as deferred with an independent firstPage URI-reference. A provider MAY instead reject an explicitly ambiguous request with multipleAttributePaginationNotSupported when that behavior is advertised. This rule permits a bare resource-by-identifier request to remain bounded even when several default-returned protected attributes exist.¶

8.4. Continuation Page

When attributeCursor is present, the provider:¶

1. Validates cursor syntax, integrity, expiry, and context.¶

2. Re-evaluates authorization for the parent, attribute, and values.¶

3. Applies the stored keyset boundary and ordering.¶

4. Retrieves no more than effectivePageSize + 1 candidate rows.¶

5. Removes the look-ahead row before hydration.¶

6. Returns a replacement nextCursor only when another page is known to exist.¶

7. SHOULD omit totalResults.¶

An invalid cursor MUST NOT fall back to a first page, an unbounded query, or index-based attribute pagination.¶

8.5. Reference-Derived Attributes

For a reference-derived attribute, pagination MUST be applied at the relationship or source-resource query before referenced objects are hydrated. The provider MUST NOT first collect every referenced identifier and then paginate the hydrated result.¶

The source query SHOULD return only the identifiers and ordering values needed for the bounded page. Hydration queries SHOULD use joins, array binding, temporary tables, or bounded chunks appropriate to the database. Implementations MUST account for database expression limits; a page of 1000 plus one look-ahead row MUST NOT become a single 1001-expression IN predicate. The look-ahead row MUST be removed before hydration because it is not part of the response page.¶

8.6. Adaptive Safety Limits

Page size is not the only resource limit. A provider MAY stop a page before reaching the effective page size when a response-byte, serialization, query-time, or hydration budget is reached. If more authorized values remain, it MUST return a nextCursor whose boundary is the last value actually returned.¶

A provider MUST NOT return a cursor that advances past values omitted only because a safety budget was reached.¶

9.1. Collection Search with Deferred App Grants

GET /Apps?attributes=id,displayName,grants&count=100
Prefer: scim-attribute-pagination=deferred

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 2,
  "itemsPerPage": 2,
  "startIndex": 1,
  "Resources": [
    {
      "schemas": [
        "urn:example:scim:schemas:2.0:App",
        "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource"
      ],
      "id": "app-123",
      "displayName": "Payroll",
      "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource": {
        "attributePagination": [
          {
            "attribute": "grants",
            "state": "deferred",
            "firstPage": "/Apps/app-123?attributes=id%2Cgrants"
          }
        ]
      }
    },
    {
      "schemas": [
        "urn:example:scim:schemas:2.0:App",
        "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource"
      ],
      "id": "app-456",
      "displayName": "Travel",
      "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource": {
        "attributePagination": [
          {
            "attribute": "grants",
            "state": "deferred",
            "firstPage": "/Apps/app-456?attributes=id%2Cgrants"
          }
        ]
      }
    }
  ]
}

The grants arrays are absent, not empty. No grant query, count, identifier list, or hydration is performed while building this parent collection.¶

9.2. First Page Without attributeCount

The client follows the first link:¶

GET /Apps/app-123?attributes=id%2Cgrants

Assume the provider chooses an effective page size of two for this abbreviated example.¶

{
  "schemas": [
    "urn:example:scim:schemas:2.0:App",
    "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource"
  ],
  "id": "app-123",
  "grants": [
    {
      "value": "grant-001",
      "$ref": "../Grants/grant-001",
      "granteeId": "user-001"
    },
    {
      "value": "grant-002",
      "$ref": "../Grants/grant-002",
      "granteeId": "user-002"
    }
  ],
  "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource": {
    "attributePagination": [
      {
        "attribute": "grants",
        "state": "page",
        "itemsPerPage": 2,
        "nextCursor": "opaque-attribute-cursor"
      }
    ]
  }
}

itemsPerPage describes the number of values actually present in the response page.¶

9.3. Continuation

GET /Apps/app-123?attributes=id%2Cgrants&attributeCursor=opaque-attribute-cursor

The continuation request does not need attributeCount; the cursor binds the effective page size. The response contains another nextCursor only if another page exists and normally omits totalResults.¶

9.4. Client-Preferred Page Size

GET /Groups/group-123?attributes=id%2CdisplayName%2Cmembers&attributeCount=250

The provider returns at most 250 authorized member values, subject to a smaller provider or response-byte limit.¶

9.5. Multiple Protected Attributes

GET /Apps/app-123?attributes=id%2Cgrants%2Caccounts

The provider returns neither array and advertises both independently:¶

{
  "schemas": [
    "urn:example:scim:schemas:2.0:App",
    "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource"
  ],
  "id": "app-123",
  "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource": {
    "attributePagination": [
      {
        "attribute": "grants",
        "state": "deferred",
        "firstPage": "/Apps/app-123?attributes=id%2Cgrants"
      },
      {
        "attribute": "accounts",
        "state": "deferred",
        "firstPage": "/Apps/app-123?attributes=id%2Caccounts"
      }
    ]
  }
}

The client follows the links independently, so a single cursor never has to encode multiple positions.¶

14.1. Totals and Empty Attributes

Exact totals can be as expensive as retrieving the values and are not required for forward traversal. Providers SHOULD omit totalResults when it requires a costly count. Deferred collection responses SHOULD NOT count protected values merely to populate metadata.¶

An advertised firstPage can return zero values and no nextCursor. This is not an error.¶

16.1. RFC 9865

[RFC9865] pages collections of SCIM resources. This document reuses its main design properties—opaque forward cursors, provider-selected defaults, maximum page sizes, cursor expiry, per-page authorization, and no fallback after an invalid cursor—but scopes the cursor to values of one attribute on one parent.¶

16.2. Multi-Value Paging and Filtering Drafts

[I-D.hunt-scim-mv-paging] (Hunt and Wilson) and its replacement [I-D.hunt-scim-mv-filtering] (Hunt) previously proposed value qualifiers containing index pagination and filters inside the attributes parameter, including paging values across multiple returned parents. Support was discovered through a boolean mvpaging attribute in ServiceProviderConfig. The SCIM working group charter names this work as input for the multi-value query filtering and paging work item.¶

A call for adoption of [I-D.hunt-scim-mv-filtering] was issued to the working group in May 2022. The draft was not adopted, for lack of sufficient responses; the substantive response received did not support adoption, on the grounds summarized in Section 16.8. This document does not assume that history is irrelevant to it. Sections 16.8 and 1.1 set out what this document claims that the 2022 proposal did not, and Section 16.9 records the design question that remains open.¶

This document uses that work as input and differs in three respects. First, it separates parent collection traversal from attribute traversal, which bounds work and avoids encoding multiple parent-specific continuation positions in one request. Second, it uses an opaque keyset cursor rather than index qualifiers, for the reasons given in Section 16.2.1. Third, it uses a structured discovery extension rather than a single boolean, because a service provider needs to advertise which attributes are protected, what page-size limits apply, and which modes are supported, none of which a boolean can express.¶

Two properties claimed for the qualifier approach warrant direct comment, because this document deliberately trades both away.¶

Backward compatibility. Qualifier-based paging is backward compatible in the sense that a client that sends no qualifier receives unmodified behavior. That property is preserved here by the explicit mode of Section 4.1. It is not preserved by automatic deferred mode, and this document does not claim otherwise. The reason is that explicit mode alone does not solve the operational problem: an unmodified client issuing a bare GET /Groups/{id} against a group with millions of members still causes the unbounded work described in Section 2, because the client has no way to know it should ask for less. A mechanism that only protects the service provider when the client cooperates does not protect the service provider. Automatic mode exists to close that gap, and the negotiation surface in Sections 4.1 and 4.2 exists to make the resulting behavior change safe and observable rather than silent.¶

Statelessness. Index qualifiers are stateless in that the server retains nothing between requests. This document accepts server-side or cursor-encoded continuation state because statelessness and correctness are in conflict here: an index position is only a valid continuation point if the underlying value sequence has not changed, and Section 16.2.1 documents what happens in deployment when it has. The cursors defined in this document are self-describing and integrity-protected rather than stored server-side (Section 11), which recovers most of the operational benefit of statelessness without inheriting the correctness defect.¶

16.3. OData Collection Continuation

OData 4.01 [OData-JSON] permits a partial collection-valued property or expanded navigation collection to carry a property-specific nextLink, annotated as {property}@odata.nextLink. A response to an expanded parent collection can therefore return a bounded set of child values per parent together with a per-parent continuation link. The firstPage and nextCursor concepts in this document follow the same architectural principle: continuation metadata belongs to the partial nested collection, while the values remain associated with their parent.¶

OASIS also considered the scoping question this document faces. Issue ODATA-519 records that client-driven paging with $top and $skip was permitted for all collection-valued resources while server-driven paging via next links was restricted to collections of entities or entity references, and notes that there is no semantic reason for that restriction. This document does not adopt the restriction: the deferred and paged behavior defined here applies to any complex multi-valued attribute a service provider designates as protected, whether or not its values are references.¶

16.4. Relationship and Sub-Resource Models

Two related proposals represent a multi-valued attribute's values as resources rather than as attribute values: a top-level relationship resource such as /GroupMembers, defined in [I-D.zollner-scim-groupmember], and a per-attribute sub-resource endpoint such as /Groups/{id}/members or a generalized /{ResourceType}/{id}/{attributeUrn}. Both enable standard collection pagination, filtering, and in the relationship-resource case per-relationship create and delete operations.¶

This document is not an alternative to either. Its relationship to each differs.¶

16.5. Whole-Resource Pagination

An alternative raised in working group mailing list discussion is to paginate the JSON object representing a SCIM resource, treating the serialized resource rather than one attribute's value list as the unit of division. This has the attraction of addressing a resource with several large multi-valued attributes, and of addressing large single-valued attributes, in one mechanism.¶

This document does not adopt that model, for four reasons.¶

• A division of the serialized object has no attribute semantics. It cannot express that an attribute with returned: always must never be withheld, and it cannot distinguish a withheld attribute from an empty one, which Section 4 identifies as a correctness requirement for mutation safety.¶

• A continuation point over serialized output cannot be bound to a deterministic ordering of the underlying value set, so it reintroduces the concurrent-modification defect described in Section 16.2.1 at the document level rather than the attribute level.¶

• Authorization is applied per value (Section 15). A serialization-level boundary can split a value set at a point that does not correspond to any authorization decision, so the provider must still evaluate the whole set before deciding what to emit. Response size is bounded; the underlying work is not.¶

• The generated boundary is not addressable. A client cannot request the second page of one specific attribute without traversing what precedes it, which defeats the selective-retrieval use case in Section 3.¶

A provider needing to bound several protected attributes on one resource achieves this with the mechanism defined here by deferring each independently and hydrating one per response, as specified in Section 8.¶

16.6. HTTP Chunked Transfer Encoding

Chunked transfer encoding has been raised in SCIM working group mailing list discussion as an existing mechanism that could address large resource representations without a SCIM-level extension.¶

Chunked transfer encoding bounds neither the work described in Section 2 nor the memory required to produce the response. It permits a response to be transmitted without a known content length, which allows the service provider to begin transmitting before serialization completes. It does not reduce the number of values the provider must retrieve, hydrate, authorize, or serialize, and it does not bound the intermediate identifier lists, expression-limit exposure, or fan-out during collection searches. A provider that streams a group of several million members has converted a large allocation into a long-running one; the request is still unbounded, and the client still receives a representation it cannot process incrementally without a value-level continuation contract.¶

Chunked transfer encoding is complementary to this document, not an alternative to it, and a provider MAY use it for the bounded pages defined here.¶

16.7. Deployed Practices and Implementation Experience

Deployed identity clients demonstrate both sides of the compatibility problem. Microsoft Entra provisioning requests Groups with excludedAttributes=members and uses targeted membership operations, which naturally avoids unbounded reads. Okta documents that a bare GET /Groups/{id} must return members and that some custom integrations use PUT with full membership state. PingOne management APIs use provider-defined page limits and opaque cursor links for large collections. Providers therefore need client-specific migration evidence before changing automatic behavior for an established integration.¶

Implementers have independently converged on the retrieval pattern this document standardizes. One reported deployment handling groups exceeding one hundred thousand members retrieves the group with its members excluded and then paginates the membership through a separate endpoint, having added that endpoint as an implementation-specific extension. That two-step flow — parent representation without the high-cardinality attribute, followed by a bounded traversal of the attribute at its own address — is the flow specified in Sections 6 and 8 of this document. The contribution here is not the pattern but its standardization: an authoritative provider-generated firstPage link rather than a client-constructed URI template, a deterministic ordering and continuation contract, and discovery that tells a client which attributes behave this way before it issues the first request.¶

16.8. Inverse Filtering Over the Counterpart Resource

Working group feedback on the earlier multi-value filtering proposal observed that the common group-membership use cases can be satisfied with existing SCIM filtering and ordinary resource pagination, without any protocol extension. Where a counterpart resource exists and the inverse relationship is filterable, membership can be enumerated as a resource collection:¶

GET /Users?filter=groups.value eq "2819c223-7f76-453a-919d-413861904646"

The results are resources rather than attribute values, so they page under Section 3.4.2.4 of [RFC7644] with no new mechanism. Membership tests reduce to compound filters in the same way.¶

This document accepts that analysis. For enumerating the members of a group, or the groups containing a user, inverse filtering is an effective technique that requires nothing new, and clients that can use it should. The observation that the base SCIM schemas contain few attributes large enough to warrant server-side value pagination — principally Group.members and User.groups — is also accepted; see Section 3.¶

Three limits define what remains.¶

First, and most importantly, inverse filtering answers a different question. It provides a way for a client to enumerate memberships; it does not define what a service provider returns when a client requests the parent resource, which [RFC7643] entitles it to do and which returns members by default. Section 1.1 sets out that gap. A provider cannot decline to answer GET /Groups/{id} on the grounds that a better query exists.¶

Second, it requires a filterable inverse. User.groups is defined with mutability: readOnly, and support for filtering on it is uneven across deployed service providers. Where the counterpart attribute is not filterable, or is not indexed for that access path, the technique is unavailable and the client has no way to discover this in advance.¶

Third, it requires a counterpart resource. Implementation-specific assignment attributes are frequently derived rather than persisted, and frequently have no resource on the other side of the relationship to filter over. For these attributes the inverse query does not exist to be issued.¶

Inverse filtering and this document are therefore complementary. A service provider SHOULD support inverse filtering where the relationship permits it, and clients SHOULD prefer it for enumeration. This document defines what happens on the paths inverse filtering does not cover.¶

16.9. Root-Level Attribute Traversal (Open Issue)

[[ RFC Editor / Working Group note: this section states an open design question that this revision does not resolve. It is included because the question is material to the value of the mechanism. To be resolved before working group last call. ]]¶

As specified in this revision, traversing a protected attribute requires a request per parent resource. A collection search returns each parent with a firstPage link, and the client follows one link per parent. For a client enumerating memberships across many groups, this is a request per group.¶

This is a substantive limitation of the mechanism as specified, not merely an inefficiency, for two reasons. First, the request count scales with the number of parent resources rather than with the number of values retrieved. Second, and more consequentially, it forecloses a root-level form such as:¶

GET /Groups?attributes=members&attributeCursor=<opaque>

in which a single traversal spans parents. That form is a prerequisite for change-tracking and delta-query mechanisms over relationship sets, which are anticipated future work for this protocol. A design that cannot express it constrains that work.¶

The cursor mechanism defined in Section 10 appears capable of carrying this form. A keyset cursor is defined over a deterministic total ordering; extending that ordering from (value identifier) within one parent to the composite (parent identifier, value identifier) across a collection yields a single continuation sequence over the whole relationship set. The per-parent traversal specified in Section 8 then becomes the case in which the ordering is constrained to one parent, rather than the only available mode. A delta traversal would order over a change sequence instead.¶

Several questions remain unresolved, and this document does not treat the design as settled:¶

• What the response envelope should be. A root-level traversal returns values belonging to many parents; whether these are returned as partial parent resources, as a flat sequence of (parent, value) pairs, or in some other form determines whether the result remains interpretable in the schema context of its parent.¶

• Whether the composite ordering can be evaluated efficiently by service providers whose relationship storage is partitioned by parent, which is a common arrangement and the reason the per-parent form was specified first.¶

• How the result relates to a relationship resource collection (Section 16.4.1). A flat (parent, value) sequence and a paged relationship resource collection may be close enough that specifying both is not warranted.¶

• Whether authorization can be evaluated per value at acceptable cost when a page spans parents with differing access-control outcomes.¶

Working group input is invited on all four, and specifically on whether this work belongs in this document or in the relationship-resource work described in Section 16.4.1.¶

17.1. SCIM Schema URI for Data Resources

• Schema URI: urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource¶

• Name: Attribute Pagination Resource Extension¶

• Reference: This document¶

17.2. SCIM Server-Related Schema URI

• Schema URI: urn:ietf:params:scim:schemas:extension:attributePagination:2.0:ServiceProviderConfig¶

• Name: Attribute Pagination Service Provider Configuration Extension¶

• Reference: This document¶

17.3. HTTP Preference

This document requests registration of the following preference in the IANA "HTTP Preferences" registry defined by [RFC7240]:¶

• Preference: scim-attribute-pagination¶

• Value: deferred¶

• Optional Parameters: None¶

• Description: Indicates that the client understands deferred and cursor-paged SCIM multi-valued attribute representations defined by this document.¶

• Reference: This document¶

The SCIM detail error keywords in Section 13 extend Table 9 of [RFC7644]. No separate IANA registry for SCIM detail error keywords exists at the time of writing.¶

A.1. Resource Extension Schema

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
  "id": "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:Resource",
  "name": "AttributePaginationResourceExtension",
  "description": "Describes deferred or cursor-paged multi-valued attributes on a SCIM resource.",
  "attributes": [
    {
      "name": "attributePagination",
      "type": "complex",
      "multiValued": true,
      "required": false,
      "mutability": "readOnly",
      "returned": "default",
      "uniqueness": "none",
      "description": "Independent retrieval state for protected multi-valued attributes.",
      "subAttributes": [
        {
          "name": "attribute",
          "type": "string",
          "multiValued": false,
          "required": true,
          "caseExact": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Canonical SCIM path of the protected attribute."
        },
        {
          "name": "state",
          "type": "string",
          "multiValued": false,
          "required": true,
          "caseExact": true,
          "canonicalValues": ["deferred", "page"],
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Indicates whether values are deferred or a page is present."
        },
        {
          "name": "firstPage",
          "type": "reference",
          "referenceTypes": ["uri"],
          "multiValued": false,
          "required": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Authoritative URI-reference used to retrieve the first page."
        },
        {
          "name": "itemsPerPage",
          "type": "integer",
          "multiValued": false,
          "required": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Values returned in this page."
        },
        {
          "name": "nextCursor",
          "type": "string",
          "multiValued": false,
          "required": false,
          "caseExact": true,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Opaque cursor for the next page."
        },
        {
          "name": "totalResults",
          "type": "integer",
          "multiValued": false,
          "required": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Optional total authorized values."
        },
        {
          "name": "attributeVersion",
          "type": "string",
          "multiValued": false,
          "required": false,
          "caseExact": true,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "description": "Optional collection version token."
        }
      ]
    }
  ]
}

A.2. Service Provider Configuration Extension Schema

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
  "id":
   "urn:ietf:params:scim:schemas:extension:attributePagination:2.0:ServiceProviderConfig",
  "name": "AttributePaginationServiceProviderConfigExtension",
  "description": "Support and policy for attribute pagination.",
  "attributes": [
    {
      "name": "supported",
      "type": "boolean",
      "multiValued": false,
      "required": true,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "cursor",
      "type": "boolean",
      "multiValued": false,
      "required": true,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "defaultMode",
      "type": "string",
      "multiValued": false,
      "required": false,
      "caseExact": true,
      "canonicalValues": ["explicit", "deferred"],
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "defaultPageSize",
      "type": "integer",
      "multiValued": false,
      "required": false,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "maxPageSize",
      "type": "integer",
      "multiValued": false,
      "required": false,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "maxHydratedAttributesPerResponse",
      "type": "integer",
      "multiValued": false,
      "required": false,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "cursorTimeout",
      "type": "integer",
      "multiValued": false,
      "required": false,
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "totalResults",
      "type": "string",
      "multiValued": false,
      "required": false,
      "caseExact": true,
      "canonicalValues": ["unsupported", "optional", "supported"],
      "mutability": "readOnly",
      "returned": "default"
    },
    {
      "name": "resourceTypes",
      "type": "complex",
      "multiValued": true,
      "required": false,
      "mutability": "readOnly",
      "returned": "default",
      "subAttributes": [
        {
          "name": "resourceType",
          "type": "string",
          "multiValued": false,
          "required": true,
          "caseExact": true,
          "mutability": "readOnly",
          "returned": "default"
        },
        {
          "name": "attributes",
          "type": "string",
          "multiValued": true,
          "required": true,
          "caseExact": false,
          "mutability": "readOnly",
          "returned": "default"
        }
      ]
    }
  ]
}

C.1. Persisted Attributes

A directly persisted attribute can use a parent-scoped keyset query:¶

SELECT ...
FROM RESOURCE_SUBOBJECT
WHERE TENANT_ID = ?
  AND PARENT_ID = ?
  AND MAPPING_PATH = ?
  AND ID > ?
ORDER BY ID
FETCH FIRST ? ROWS ONLY

The final bind is the effective page size plus one.¶

C.2. Reference-Derived Attributes

A reference-derived attribute can page the relationship at its source:¶

SELECT ...
FROM GRANT_RESOURCE
WHERE TENANT_ID = ?
  AND APP_ID = ?
  AND ID > ?
ORDER BY ID
FETCH FIRST ? ROWS ONLY

Only the returned page is hydrated into the parent attribute. Implementations SHOULD avoid N+1 display-value queries and unbounded identifier lists.¶

C.3. Work Budgets

Deferred collection retrieval changes one large response into optional follow-up calls. A malicious or poorly designed client can still fan out across many parents and attributes. Providers SHOULD enforce:¶

• Maximum attribute page size.¶

• Maximum response bytes and serialized values.¶

• Query-time and hydration-time budgets.¶

• Per-client and per-tenant request-rate limits.¶

• Concurrency limits for expensive protected attributes.¶

• Cursor issuance and lifetime limits.¶

• Maximum root-resource page size.¶

• Maximum deferred descriptors per response.¶

For complete extraction of very large datasets, providers SHOULD offer an asynchronous export or bulk mechanism rather than encouraging millions of synchronous cursor requests.¶

C.4. Observability

Providers SHOULD distinguish at least:¶

• deferred collection responses;¶

• first attribute pages;¶

• continuation pages;¶

• terminal pages;¶

• invalid or expired cursors;¶

• effective page size and returned value count;¶

• time spent discovering values versus hydrating them;¶

• response bytes and budget-driven early page termination.¶

Metrics MUST NOT use tenant identifiers, parent identifiers, cursor contents, attribute values, or other unbounded/high-cardinality dimensions.¶