Summary

  • A 28 October individual Internet-Draft proposes a top-level GroupMembership resource. Clients could query, page through and address individual group-member links instead of relying only on one potentially enormous Group.members array.
  • Its optional membersEmbedded flag makes a narrow promise: true says the returned array is complete when the request permits that array to be returned; false offers no such guarantee. A client that needs the full, authorized roster would query /GroupMemberships.

A grant without a head count

RFC 7643 puts members inside the Group resource. That is tidy until the group is large enough that returning the entire array becomes expensive. The new draft's author describes implementations that omit members or clients that exclude it from responses. A provisioning client may still send additions and removals, yet cannot compare its intended list with what the service actually holds. The draft supplies no independent census of how many providers behave this way; its mechanism, rather than a claimed market total, is the news.

The proposal takes the edge out of the group record and makes it a record of its own. Each GroupMembership would carry an opaque provider-issued ID, a group reference and a member reference. A filtered request could ask for all members of a group, all groups containing one member, or one particular pair. That last query matters to a revocation operator: it can find the exact resource to delete. The provider would reject a second copy of the same pair with a conflict response. Datatracker lists this as an individual draft, with no working-group adoption or IESG approval.

The subtle part is a single boolean. If a Group response says membersEmbedded: true, the draft makes the provider guarantee that the members array contains the full current membership, provided the request allowed that attribute to appear. A client that deliberately excluded members cannot read an empty roster from that flag. If the flag is false, even a populated array carries no completeness guarantee. The client seeking a full picture must use the filtered membership endpoint. Silence from the flag leaves the old RFC 7643 interpretation in place.

This is a stronger contract than merely making a giant response smaller. Under the draft, /GroupMemberships must expose every membership the requesting client is authorized to see. That access clause matters: a filtered response is a complete view of the client's permitted slice, not necessarily of the provider's entire directory. The endpoint must offer equality filters on group and member IDs and at least one pagination method. It recommends cursors because an index can shift while a client walks a changing list. Its stable-order promise explicitly assumes the underlying memberships stay unchanged during the query.

The proposed second interface also creates a two-ledger trap. A provider that accepts mutations through both Group.members and /GroupMemberships must keep them synchronized. Removing a member through either path removes the same membership; deleting a group or member removes its associated links. Otherwise a revocation could look finished in one view while the other continues to report the grant. The draft puts that consistency duty on the service provider, not on the client trying to guess which screen is authoritative.

The practical question for an identity team is simple: after a grant or revocation, can it query the provider's authorized membership records and reconcile the result? An individual draft has now named the missing readback and specified a way to supply it. Adoption and implementation evidence are still absent; a working-group decision or tested provider behaviour would change the story.

Sources: individual draft; IETF status; SCIM core schema, RFC 7643; SCIM protocol, RFC 7644; cursor pagination, RFC 9865.