[scim] Re: Group Member Resource

["Dr. Matthias Winter" <[e-mail]>]

Hi Danny and all,

thanks for your response. I hope we can get some more views on the topics you put up for discussion. I’d like to add some more reasoning to some of them:

# memberCount
> Promoting memberCount and ref to top-level core Group attributes

I agree that memberCount shouldn’t be part of the base schema (the core Group schema). When I suggested to make the attributes “top level”, I meant to make them attributes instead of sub-attributes within the schema extension.

# allowedMemberTypes
> allowedMemberTypes provides per-group constraints, which is meaningful in deployments where different groups have different valid member types -- for example, a directory that has distinct User-only and Device-only groups that do not permit mixed membership, with the two group types serving different purposes in the connected system(s).

In your example, if the group types serve different purposes in the connected systems, they should be different SCIM resource types.

In my opinion, adding per-group member types should be out of scope for the draft. The current core Group does not have this option. Adding the possibility would make the scaling problem worse because it seduces service providers to blend all types of different objects into the SCIM “Group”. Then, service providers would start to handle individual “Group” resources differently because they refer to different objects internally, which causes additional problems.

However, as I wrote, if we don’t provide any guidance on how to extend GroupMembers-like membership management to additional group-like resources, we will see incompatible implementations by different service providers. For the usual management via the "members" attribute, this is not an issue. Usage in custom resource types is straightforward, and current implementations are compatible across service providers.

# ref
>   - On ref: I disagree with setting uniqueness: server. The convention for $ref attributes in RFC7643 is uniqueness: none, and most SCIM implementations key off of the "value" sub-attributes (members.value, manager.value..) rather than $ref, in addition to treating $ref as a readOnly sub-attribute populated and returned by the service provider. This change would be inconsistent with RFC7643 precedent.

The proposed “ref” attribute is "uniqueness":"server" by design. We don’t have a choice here and it implies no additional requirement on the attribute. According to the design, the proposed “ref” attribute always contains a filter with the “id” of the same group resource. Therefore, it naturally has the same uniqueness as “id”. The non-unique “$ref” sub-attribute is not really comparable because it has a different purpose and different content.

# GroupMembers: Filter by members.type
> My current inclination is that a SHOULD -- conditional on the Service Provider supporting more than one member resource type -- is more appropriate than an unconditional MUST. Requiring a Service Provider to support filtering by member.type when their implementation only supports one resource type as a group member seems unhelpful.

I agree that a filtering requirement should be subject to the support of multiple member types, not to the mere support of the “type” sub-attribute.
Unfortunately, there is no way within SCIM for service providers to declare which attributes are supported for filtering. The situation that filtering is only supported on a subset of attributes is not covered in RFC7644. Clients would have to implement a trial-and-error approach and handle an unreliable response status code if filtering fails. A “SHOULD” would not improve this situation. We are considering groups with large amounts of members here. It would not be good if clients retrieve thousands of GroupMembers just to get a handful of members of type “Group” because they don’t know if filtering by “type” would work.
If there were a possibility to declare filter support for attributes, I wouldn’t have suggested a “MUST”. But in the current situation, I think it is preferable to an unreliable “maybe” (with or without SHOULD). If support of the “members.type” sub-attribute remains optional, service providers could opt-out of the filter requirement by not supporting the sub-attribute.
I hope, we can get some more opinions on this.

Regards,
Matthias




Classification: Restricted

Mit freundlichen Grüßen / Kind regards,
Dr. Matthias Winter
Senior Software Architect
Beta Systems IAM Software AG
Development
Josef-Lammerting-Allee 14, 50933 Köln
Phone: [phone]
Mobile: [phone]
Email: [e-mail]
www.betasystems.com
Mandatory information for business emails according to German trade laws / Pflichtangaben für geschäftliche E-Mails gemäß Handelsgesetzbuch und Aktiengesetz: 
Beta Systems IAM Software AG, Ernst-Reuter-Platz 6, 10587 Berlin, Germany 
Phone: [phone], Email: [e-mail]  
​ 
Executive Board / Vorstand: Mirko Minnich, Gerald Schmedding | Chairman of the Supervisory Board / Vorsitzender des Aufsichtsrats: Dr. Wolfgang Schlaak 
Legal Form / Rechtsform: Aktiengesellschaft | Registered Office / Sitz: Berlin | Commercial Register / Handelsregister: Amtsgericht Charlottenburg HRB 165007 B 
VAT-ID / Ust-ID-Nr.: DE300760040 | Tax No. / St.-Nr.: 27/036/39045
From: Danny Zollner <[e-mail]>
Sent: Donnerstag, 19. März 2026 01:48
To: Dr. Matthias Winter <[e-mail]>
Subject: Re: [scim] Group Member Resource

Hi Matthias, all,

Thank you for the thorough review of draft-zollner-scim-group-members-00. Rather than responding inline, as the existing quoting structure makes further nesting unwieldy, I've organized my responses by section of the draft below. Several items touch on design questions where I'd welcome broader WG input; those are flagged explicitly and summarized at the end of this email as well.


Section 2 -- Introduction
--------------------------

The suggestion to add guidance for custom group-like resource types (Roles, Teams, Entitlements, etc.) is out of scope for what I intend for this draft to address. The document is specifically chartered around the scalability limitations of the Group resource type and members attribute as defined in RFC7643.


Proposed new section on referenceTypes for string attributes
-------------------------------------------------------------

I disagree with this proposal. The referenceTypes property is defined in RFC7643 for reference-type attributes. Applying it to string-type attributes would constitute a reinterpretation of the SCIM JSON schema specification that is outside the scope of this draft. This disagreement also applies to the related suggestions in Sections 4.1 and 8.1 that depend on the same interpretation. I agree that the problem you have identified here is a problem, and wrote a draft


Section 4 -- The GroupMember Resource
--------------------------------------

I agree with adding explicit language that GroupMember resources MUST represent only direct memberships, and that indirect memberships as defined in RFC7643 Section 4.1.2 MUST NOT be represented as GroupMember resources.

The suggestion to add guidance on analogous resources for other group-like resource types is out of scope for the same reasons noted above for Section 2.


Section 4.1 -- Resource Properties
------------------------------------

schemas, id, and meta: Rather than removing these from the text entirely, I'll add a note clarifying that they are inherited from RFC7643, with specific description of the id attribute's role in the context of a GroupMember resource -- namely as the stable, opaque identifier for a membership link.

display sub-attributes: Agreed. I'll add display sub-attributes to both the group and member complex attributes, consistent with the existing Group:members pattern in RFC7643.

referenceTypes on value sub-attributes: As noted above, referenceTypes is defined for reference-type attributes, not string-type attributes such as value. I disagree with this suggestion for both group.value and member.value.

mutability: Agreed. I'll add clarification that if a Service Provider's implementation does not support creating or deleting GroupMember resources, all attributes on those resources MUST be readOnly in the schema definition returned from /Schemas.

Strengthening requirements for the member attribute: I disagree with making the User resource type a normative MUST for supported member types. This draft defines how to represent group memberships as a top-level resource; it does not define interoperability rules about which resource types are valid members of a group. Similarly, member.type should remain optional but recommended rather than subject to a MUST requirement.


Section 4 -- Resource Type Representation and Section Ordering
---------------------------------------------------------------

I disagree with reordering the subsections. I think both options are acceptable and this is a style preference. The current progression (Resource Properties -> JSON Representation -> Resource Type) follows a natural reading order and is consistent with the approach taken in RFC7643. I agree that the ResourceType example is missing the meta attribute and will add it.


Section 5 -- membersMetadata Group Schema Extension
----------------------------------------------------

Several pieces of feedback on this section raise design questions where I'd welcome broader WG input:

Extension name: The suggestion to rename the extension is noted. I don't have a strong opinion on the name and would welcome WG input.

Removing the policy attribute: The argument that policy can be inferred from schema properties has merit, but an explicit policy attribute provides a per-group, single-signal declaration of intent that simplifies client logic -- particularly for Service Providers that aggregate groups from multiple backend systems where different groups may be managed differently based on size, performance, or other internal factors. I'm open to WG discussion on whether the attribute should be kept, removed, or reformulated.

Removing the allowedMemberTypes attribute: The referenceTypes and canonicalValues mechanisms proposed as alternatives operate at the resource-type level, describing global constraints. allowedMemberTypes provides per-group constraints, which is meaningful in deployments where different groups have different valid member types -- for example, a directory that has distinct User-only and Device-only groups that do not permit mixed membership, with the two group types serving different purposes in the connected system(s). I'm open to WG discussion on this.

Promoting memberCount and ref to top-level core Group attributes: I disagree for the time being but am not strongly against this. My understanding is that as these attributes are not part of the existing core Group schema defined in RFC7643, they belong in their own schema namespace unless they are added to the core Group schema via an IANA registration update. My primary concern is that adding new attributes to the core/base schema risks being a breaking change for existing implementations. I'd want to gather additional feedback from the WG and research some of the most commonly used SCIM client implementations to understand what risk, if any, is posed by moving these to the core Group schema.

Applying the extension to non-Group resource types: Out of scope for the same reasons noted above.

Examples (Section 5.2): Several issues will be corrected: the extension schema URN will be added to the schemas array; inconsistent URN references will be corrected; and the JSON key structure will be fixed. The current examples incorrectly use urn:...Group:membersMetadata as the key, when the correct structure is the plain extension URN urn:...Group with membersMetadata represented as a nested complex attribute underneath it. On meta.created and meta.lastModified: RFC7643 is ambiguous as it specifies that the meta attribute is required but does not specify which sub-attributes, if any, are required to be populated. Many examples in the specification itself show only a subset of meta sub-attributes being populated with a value as well. I don't intend to fully populate each meta attribute in the examples at this time as it does not appear to be required by the RFC 7643 and only adds unnecessary data to the examples.


Section 6.2.2 -- Filtering
---------------------------

I'd welcome WG input on whether to add normative language around filtering on member.type. My current inclination is that a SHOULD -- conditional on the Service Provider supporting more than one member resource type -- is more appropriate than an unconditional MUST. Requiring a Service Provider to support filtering by member.type when their implementation only supports one resource type as a group member seems unhelpful.


Section 7.1.1 -- Schema Endpoint
----------------------------------

The suggestion that schema definitions MUST NOT include unsupported attributes is a general SCIM interoperability requirement better addressed in an interoperability document (such as the other draft I recently published, https://datatracker.ietf.org/doc/draft-zollner-scim-interop-profile/) than in this draft.


Section 7.1.2 -- Impact on the Group Resource
----------------------------------------------

Agreed on the cross-reference correction ("As noted in Section 3" -> "As noted in Section 6"). I did some reorganization of the content in this draft shortly before publishing it and missed updating this reference.

The technical error in the returned: never recommendation is acknowledged -- returned is a schema-level property and cannot vary per individual resource instance. The guidance in this section will be revised; the specific text will depend on the outcome of the WG discussion on membersMetadata.policy noted above. I may remove the offending text in the next version of the draft if the membersMetadata.policy topic is still under discussion.


Section 8.1 -- GroupMember Core Schema
----------------------------------------

The following corrections will be made to the formal schema definition:

  - schemas and meta attributes will be added to the top level of the SCIM JSON schema definition
  - uniqueness will be removed from the group and member complex attributes, as this property applies only to simple attributes per RFC7643 Section 7
  - returned and multiValued will be specified explicitly on all attributes
  - caseExact: true will be set on group.value and member.value, as SCIM id values are opaque and case-sensitive
  - The schema "name" attribute will be updated from "GroupMember" to "Group Member"



Section 8.2.1 -- membersMetadata Schema Extension Definition
-------------------------------------------------------------

The following corrections will be made:

  - schemas and meta attributes will be added to the top level of the SCIM JSON schema definition
  - returned and multiValued will be specified explicitly on all attributes
  - memberCount will have uniqueness: none specified explicitly
  - On ref: I disagree with setting uniqueness: server. The convention for $ref attributes in RFC7643 is uniqueness: none, and most SCIM implementations key off of the "value" sub-attributes (members.value, manager.value..) rather than $ref, in addition to treating $ref as a readOnly sub-attribute populated and returned by the service provider. This change would be inconsistent with RFC7643 precedent.
  - On allowedMemberTypes (if retained following WG discussion): caseExact: true and uniqueness: none will be added. I disagree with hardcoding canonicalValues: ["User"] -- as noted above, this draft does not define normative requirements around which resource types can or must be supported as members.


Section 8.2.2 -- Usage
------------------------

The incorrect URN in the text will be corrected to urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group. The duplicate example will be removed.


Section 8.3 -- Security Considerations
----------------------------------------

Agreed on strengthening the access control language from SHOULD to MUST for write operations: a client authorized to add or remove members from a Group via PATCH MUST have equivalent POST and DELETE permissions on GroupMember resources for that group.

On the read access language: agreed that access to a Group resource alone should not automatically imply access to its full member list -- a Service Provider may legitimately expose group metadata broadly while restricting membership details to privileged clients. The text will be refined to make this distinction explicit: a client with permission to read or write a Group resource's members attribute MUST also be granted permission to the corresponding actions (GET for read, POST + DELETE for write) on the corresponding GroupMember resources for that group.


Section 8.4 -- IANA Considerations
-------------------------------------

Agreed. The extension schema URN (urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group) will be added to this section alongside the GroupMember core schema URN.


Thank you again for the detailed review and your suggestions. I've flagged several items above for broader WG discussion, particularly the membersMetadata extension design (policy, allowedMemberTypes, and naming) and the filtering requirements for member.type. Additional input from the working group on these would be very welcome.

Thanks,

Danny Zollner

On Fri, Mar 13, 2026 at 6:15 AM Dr. Matthias Winter <[e-mail]<mailto:[e-mail]>> wrote:

This message originated outside your organization.

________________________________

Hi Danny,

I like your draft for the GroupMember and I’m strongly in favor of introducing such a resource type. Please have a look at my suggestions below. Most of them are just little clarifications and improvements. In the end, it essentially boils down to the following points:

  *   Added guidance for custom group-like resources, which are facing the same problems with their memberships. This should establish a “best practice” and increase interoperability.
  *   Suggested to remove the “policy” and “allowedMemberTypes” from the extension schema. These settings should not vary between individual resources, rather they are bound to a resource type.
  *   Suggested to use the `referenceTypes` property for string attributes for easier and more reliable configuration discovery. It’s useful, but not strictly required here, so this could alternatively become part of the interoperability profile draft.

Great work. Thanks for taking the initiative for this draft,

Matthias


> 2.  Introduction

Some Service Providers have other group-like resources in addition to “Group”. I’ve encountered at least “Role”, “Entitlement”, “Organization”, and “Team” resources in different Service Providers. Some of these resources have the same issue with the number of memberships as the Group resources. To promote interoperability, there should be a clear guideline on how to implement membership resources for those custom resources.

>    This document proposes […] of any size.
Add:
Guidelines are provided on how to implement analogue mechanisms for custom resources which are analogs of groups.

To increase interoperability, I’d like to add a section between Sections 3 and 4 which describes a new interpretation of the previously unused ‘referenceType’ property for string attributes. The reasons are given in my comments to section 5.
X. The `referenceType` Property for `string` Attributes

The default sub-attribute `value` defined in Section 2.4 of RFC7643 is often used to reference other SCIM resources via their `id` attribute. However, the only way for Service Providers to communicate this to Clients in a fairly reliable manner is to implement the `$ref` sub-attribute, which is rarely done in practice, and to set the `resourceTypes` property of `$ref` accordingly. This addition defines a simpler and more reliable way.
If the only valid values for an attribute or sub-attribute of data type `string` are the `id` values of referenced SCIM resources, the Service Provider SHOULD specify the valid reference resource type names in the corresponding schema definition using the `referenceTypes` property for the string attribute.  If an attribute of data type `string` is used for other purposes, the `referenceTypes` property for the attributes MUST be unassigned.

> 4.  The GroupMember Resource

>   This section […] operations at scale.
I think it would be worth adding:
`GroupMember` resources represent direct memberships. Indirect memberships as specified in Section 4.1.2 of RFC7643 for the `User:groups` attribute MUST NOT be represented by `GroupMember` resources.

And then I suggest adding a paragraph concerning other group-like resources to improve interoperability:
If a service provider wants to implement the same mechanism for other group-like resource types, a new membership resource should be introduced for the group-like resource in analogy to `GroupMember`. For example, if the resource type is called `Team`, the membership resource type should be called `TeamMember` and its base schema should include the attributes `team` and `member` as precise analogues to `group` and `member` in the `GroupMember` resource.

> 4.1.  Resource Properties
>
> The `GroupMember` resource is defined by the following properties:
>
> *   **`group`**: A complex attribute that provides a reference to the parent Group resource. This attribute contains the following sub-attributes:
>     *   **`value`**: The `id` of the referenced Group resource. **REQUIRED**.
>     *   **`$ref`**: The URI of the referenced Group resource. Read-only.
>
> *   **`member`**: A complex attribute that provides a reference to the member resource, which can be a User, another Group, or any other resource type that can be a member of a group. This attribute contains the following sub-attributes:
>     *   **`value`**: The `id` of the referenced member resource. **REQUIRED**.
>     *   **`$ref`**: The URI of the referenced member resource. Read-only.
>     *   **`type`**: A string that specifies the resource type of the member, e.g., "User" or "Group". Read-only.

The attributes “schemas”, “id”, and “meta” are already defined in RFC7643 and they are not part of the schema. I don't think they need to be included in the list.
I added `display` sub-attributes to match the `Group:members` attribute and I tried to improve the clarity a bit:

4.1. Resource Type  (previously 4.3)
I moved this Section from 4.3 to 4.1 because the resource type references the schema.

The `GroupMember` resource type uses the base schema "urn:ietf:params:scim:schemas:core:2.0:GroupMember". Service Providers which use the `GroupMember` resource MUST make the resource type definition available at the `/ResourceTypes` endpoint. And all referenced schemas at the `/Schemas` endpoint.

`GroupMember` resources use the endpoint "/GroupMembers".

**Example ResourceType entry:**

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
  "id": "GroupMember",
  "name": "GroupMember",
  "endpoint": "/GroupMembers",
  "description": "Resource representing a single group membership.",
  "schema": "urn:ietf:params:scim:schemas:core:2.0:GroupMember"
  "meta": {
    "resourceType": "ResourceType",
    "created": "2026-03-12T16:58:42Z",
    "lastModified": "2026-03-12T16:58:42Z",
    "location": "https://example.com/scim/v2/ResourceTypes/GroupMember<https://urldefense.com/v3/__https://example.com/scim/v2/ResourceTypes/GroupMember__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDnChlE4R$>"
  }
}
```
(The `meta` attribute was added to the sample.)

4.2.  Schema (previously 4.1)

The `GroupMember` resource has the following attributes and properties. The properties of all attributes and sub-attributes MUST NOT be changed by Service Providers unless explicitly allowed in this specification. The description properties MAY be changed. The `mutability` of the attributes `group`, `group.value`, `member`, `member.value` MUST be changed to `readOnly` if and only if creation and deletion of GroupMember resources is not supported by the ServiceProvider:

*   **`group`**: A complex attribute that provides a reference to the parent Group. This attribute MUST be supported and MUST NOT be unassigned.  This attribute contains the following sub-attributes:
    *   **`value`**: The `id` of the referenced Group resource. This attribute MUST be supported and MUST NOT be unassigned.
    *   **`$ref`**: The URI of the resource referenced in the `value` attribute.
    *   **`display`**: A human-readable name for the referenced resource. It SHOULD be the value of the `displayName` attribute of the referenced Group resource.

The ` group` attribute has the following properties:

```
"name": " group",
"type": "complex",
"multiValued": false,
"description": "Provides a reference to the Group resource for the member's membership.",
"mutability": "immutable",
"returned": "default",
"required": true,
"subAttributes": [
   {
      "name": "value",
      "type": "string",
      "multiValued": false,
      "description": "The value of the `id` attribute of the Group resource.",
      "mutability": "immutable",
      "returned": "default",
      "required": true,
      "caseExact": true,
      "uniqueness": "none" ,
      "referenceTypes": ["Group"]
   },
   {
      "name": "\$ref",
      "type": "reference",
      "multiValued": false,
      "description": "The URI of the parent resource.",
      "mutability": "readOnly",
      "returned": "default",
      "uniqueness": "none",
      "referenceTypes": ["Group"]
   },
   {
      "name": "display",
      "type": "string",
      "multiValued": false,
      "description": "A human-readable name for the Group resource.",
      "mutability": "readOnly",
      "returned": "default",
      "caseExact": false,
      "uniqueness": "none"
   }
]
```

*   **`member`**: A complex attribute that provides a reference to the member resource, which can be a User, another Group, or any other resource type that can be a member of the resource referenced in the `group` attribute. This attribute MUST be supported and MUST NOT be unassigned.  The User resource type MUST be supported as member.  This attribute contains the following sub-attributes:
    *   **`value`**: The `id` of the referenced member resource.  This sub-attribute MUST be supported and MUST NOT be unassigned. Service Providers MUST set the `referenceTypes` property of this sub-attribute to the supported resource types.
    *   **`$ref`**: The URI of the referenced member resource. Service Providers MUST set the `referenceTypes` property of this sub-attribute to the supported resource types.
    *   **`type`**: If this attribute is supported, the value MUST be the `name` of the resource type of the resource referenced in the `value` attribute. Service Providers which support member resources other than `User` MUST support this attribute and MUST always assign a value. The `canonicalValues` property MUST be specified for this attribute and MUST be the same as the `referenceTypes` for the `value` and the `$ref` sub-attributes.
    *   **`display`**: A human-readable name for the referenced resource. It SHOULD be the value of the `displayName` attribute of the referenced resource if available.

The `member` attribute has the following properties:

```
"name": "member",
"type": "complex",
"multiValued": false,
"description": "Provides a reference to the member User or other member resource.",
"mutability": "immutable",
"returned": "default",
"required": true,
"subAttributes": [
   {
      "name": "value",
      "type": "string",
      "multiValued": false,
      "description": "The value of the `id` attribute of the member resource.",
      "mutability": "immutable",
      "returned": "default",
      "required": true,
      "caseExact": true,
      "uniqueness": "none",
      "referenceTypes": ["User"]
   },
   {
      "name": "\$ref",
      "type": "reference",
      "multiValued": false,
      "description": "The URI of the member resource.",
      "mutability": "readOnly",
      "returned": "default",
      "uniqueness": "none",
      "referenceTypes": ["User"]
   },
   {
      "name": "type",
      "type": "string",
      "multiValued": false,
      "description": "The resource type of the member resource.",
      "mutability": "readOnly",
      "returned": "default",
      "caseExact": true,
      "uniqueness": "none",
      "canonicalValues": ["User"]
   },
   {
      "name": "display",
      "type": "string",
      "multiValued": false,
      "description": "A human-readable name for the member resource.",
      "mutability": "readOnly",
      "returned": "default",
      "caseExact": false,
      "uniqueness": "none"
   }
]
```

> 4.3 JSON Representation (previously 4.2)
Added the `display` sub-attributes.

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:GroupMember"],
  "id": "gm12345",
  "group": {
    "value": "e9e30dba-f08f-4139-944c-2e6949b80b05",
    "display": "All Employees",
    "$ref": https://example.com/scim/v2/Groups/e9e30dba-f08f-4139-944c-2e6949b80b05<https://urldefense.com/v3/__https://example.com/scim/v2/Groups/e9e30dba-f08f-4139-944c-2e6949b80b05__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDjXV1qk9$>
  },
  "member": {
    "value": "2819c223-7f76-453a-919d-413861904646",
    "display": "Babs Jensen",
    "$ref": https://example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646<https://urldefense.com/v3/__https://example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDihonh4J$>,
    "type": "User"
  },
  "meta": {
    "resourceType": "GroupMember",
    "created": "2026-02-24T20:26:44Z",
    "lastModified": "2026-02-24T20:26:44Z",
    "location": https://example.com/scim/v2/GroupMembers/gm12345<https://urldefense.com/v3/__https://example.com/scim/v2/GroupMembers/gm12345__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDuMBfgiS$>
  }
}
```

> 5.  membersMetadata Group Schema Extension
The name of the schema extension does not describe the intended use and does not create a link to the Group Member resource type. I suggest: ‘External Member Management’. What do you think?

5.  Schema Extension `External Member Management`

The sub-attributes ‘policy’ and ‘allowedMemberTypes’ should be properties of the resource type, not the individual resource. The `policy` attribute can be dropped because the policy can be deduced from the existence of the schema extension in the Group resource type and the properties of the `members` attribute in the Group schema:

  *   Inline: No “GroupMembers” resource type and the extension schema is missing
  *   Hybrid: “GroupMembers” resources and schema extension exists and `members` attribute is readable
  *   Strict: schema extension exists and `members` is not readable (missing or "returned":"never").
Likewise, the `allowedMemberTypes` are listed as referenceTypes in `Group:members.$ref` and `GroupMembers:member.$ref` and as `canonicalValues` in `Group:members.type` and `GroupMembers:member.type`. Noting that hardly any Service Provider implements `$ref` sub-attributes, and that this is a far more general issue, I’d like to propose the extension given in section “X” above. That way, the supported resource types can be communicated to clients with the `Group:members.value` and `GroupMember:member.value` sub-attributes directly. It’s not strictly necessary here but would be helpful in general.
The `memberCount` attribute should be a top-level attribute, in my opinion. After moving that to top-level, the only sub-attribute left is `ref`. So, I’d suggest making that a top-level attribute as well (e.g. `membersRef`).

To prevent ambiguity and provide a clear path for clients, this specification also defines a schema extension for the `Group` resource. When a Service Provider supports the `/GroupMembers` endpoint, it MUST include the `External Member Management` schema extension on the `Group` resource type. The schema URN for the schema extension is `urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group`

The same schema extension should be used in other group-like resources if a service provider wants to support an analogue mechanism for managing memberships of those resources.


5.1.  Attributes

*   **`MembersRef`**: A URI that a client can use to query for the group's members. It MUST be the URI of the `/GroupMembers` endpoint with a pre-populated filter for the current resource's ID. Its format is `[GroupMembers_Endpoint]?filter=group.value eq "[Group_ID]"`. This sub-attribute MUST be supported if the extension schema is used and MUST be assigned if the group has members and the `members` attribute is omitted.

The `membersRef` attribute has the following properties, which MUST NOT be changed by Service Providers except for the `description` property:
```
"name": "membersRef",
"type": "reference",
"multiValued": false,
"description": " A URI that a client can use to query for the group's members.",
"mutability": "readOnly",
"returned": "default",
"uniqueness": "none",
"referenceTypes": ["uri"]
```

*   **`memberCount`**: A non-negative integer indicating the total number of members in the group.

The ` memberCount ` attribute has the following properties which MUST NOT be changed by Service Providers except for the `description` and `returned` property:
```
"name": " memberCount ",
"type": "integer",
"multiValued": false,
"description": "Indicates the total number of members in the group.",
"mutability": "readOnly",
"returned": "default",
"uniqueness": "none"
```

> 5.2.  Example Group Resources
The examples are missing values for `meta.created` and `meta.lastModified` and the schema extension "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group" is missing in the `schemas` attribute. The schema extension URN differs from the definition above and the sub-attributes are missing the "membersMetadata" parent attribute. Here’s the correction:

### Example of Externally Managed Group Members

The following is a `Group` with a large number of members. The members are managed externally via the `GroupMembers` resource. Therefore, the `members` attribute is absent, and the client is directed to use the `membersRef` URI.

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group", "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group"],
  "id": "e9e30dba-f08f-4139-944c-2e6949b80b05",
  "displayName": "All Employees",
  "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group": {
    "ref": https://example.com/scim/v2/GroupMembers?filter=group.value%20eq%20%22e9e30dba-f08f-4139-944c-2e6949b80b05%22<https://urldefense.com/v3/__https://example.com/scim/v2/GroupMembers?filter=group.value*20eq*20*22e9e30dba-f08f-4139-944c-2e6949b80b05*22__;JSUlJQ!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDgw2B346$>,
    "memberCount": 150321
  },
  "meta": {
    "resourceType": "Group",
    "created": "2026-03-12T17:52:14Z",
    "lastModified": "2026-03-12T17:52:14Z",
    "location": https://example.com/scim/v2/Groups/e9e30dba-f08f-4139-944c-2e6949b80b05<https://urldefense.com/v3/__https://example.com/scim/v2/Groups/e9e30dba-f08f-4139-944c-2e6949b80b05__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDjXV1qk9$>
  }
}
```

### Example of a "Hybrid" Policy

The following is a `Group` with a small number of members. The members are included inline for convenience; clients should still prefer using the `/GroupMembers` endpoint for management operations.

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group", "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group"],
  "id": "a0b1c2d3-d62c-5719-351f-5d5a675ea283",
  "displayName": "Project Phoenix Team",
  "members": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "display": "Babs Jensen"
    }
  ],
  "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group": {
    "membersRef": https://example.com/scim/v2/GroupMembers?filter=group.value%20eq%20%22a0b1c2d3-d62c-5719-351f-5d5a675ea283%22<https://urldefense.com/v3/__https://example.com/scim/v2/GroupMembers?filter=group.value*20eq*20*22a0b1c2d3-d62c-5719-351f-5d5a675ea283*22__;JSUlJQ!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDnyZoi1-$>,
    "memberCount": 1
  },
  "meta": {
    "resourceType": "Group",
    "created": "2026-03-12T17:52:14Z",
    "lastModified": "2026-03-12T17:52:14Z",
    "location": https://example.com/scim/v2/Groups/a0b1c2d3-d62c-5719-351f-5d5a675ea283<https://urldefense.com/v3/__https://example.com/scim/v2/Groups/a0b1c2d3-d62c-5719-351f-5d5a675ea283__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDoeayIpM$>
  }
}
```

> 6.2.2.  Filtering
I think, and `member.type` should be added to list of REQUIRED filter attributes, if the `type` attribute is supported by the Service Provider.

> 7.1.1.  Schema Endpoint
A schema definition must only contain attributes which are supported by the Service Provider. Therefore, the text should be

The Service Provider's schema definitions, available at the `/Schemas` endpoint, MUST include the definitions for `urn:ietf:params:scim:schemas:core:2.0:GroupMember` and `urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group` with all attributes supported by the Service Provider. It MUST NOT contain unsupported attributes.

> 7.1.2.  Impact on the Group Resource

> As noted in Section 3,
It’s Section 6.

> Service Providers that support both mechanisms SHOULD clearly document their consistency model. It is RECOMMENDED that for groups with a very large number of members, Service Providers implement the `members` attribute as write-only by setting the 'returned' schema property to 'never'.

The recommendation is not possible because the `returned` property can only be set per resource type, not for individual resources. Therefore:

Service Providers that support both mechanisms SHOULD clearly document their consistency model and keep their Schemas consistent. If a Service Provider never returns the `members` attribute of a group resource, but supports management via the `members` attribute, the `returned` property of `members` MUST be set to `never` in the schema definition and its `mutability` property MUST be `writeOnly` or `immutable`. If management through the `members` attribute is not supported, the `mutability` of `members ` MUST be `readOnly`. If the `members` attribute is neither returned nor writable, it MUST be omitted from the schema.

> 8.1.  GroupMember Core Schema
The `schemas` and `meta` attributes are missing and the `uniqueness` properties for `group` and `member` should be removed because complex attributes do not have uniqueness. The `returned` and `multiValued` properties should be specified explicitly for all attributes. The `value` sub-attributes must be case-exact. I suggest putting a space between “Group” and “Member” in the name for better readability. The terms ‘schema’ and ‘resource’ where a bit mixed up here.

The following is the formal SCIM schema definition for the `Group Member` schema which is the intended base schema for the `GroupMember` resource. The attribute properties were provided in section 4.2 and are not repeated here:

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
  "id": "urn:ietf:params:scim:schemas:core:2.0:GroupMember",
  "name": "Group Member",
  "description": "SCIM schema representing a single group membership.",
  "attributes": [
    {
      "name": "group",
      … (see section 4.2)
    },
    {
      "name": "member",
      … (see section 4.2)
    }
  ],
  "meta": {
    "resourceType": "Schema",
    "created": "2026-03-12T17:52:14Z",
    "lastModified": "2026-03-12T17:52:14Z",
    "location": "https://example.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:GroupMember<https://urldefense.com/v3/__https://example.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:GroupMember__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDgkQEGBY$>"
  }
}
```

> 8.2.1.  The membersMetadata Attribute Definition
The schema definition is missing the `schemas` and `meta` attributes. The `returned` and `multiValued` properties should be specified explicitly for all attributes.
The `policy` sub-attribute should be explicitly case-insensitive and non-unique. But I think, it should be removed, see above.
The `ref` sub-attribute should have "uniqueness": "server".
The `memberCount` sub-attribute should explicitly have "uniqueness": "none".
The `allowedMemberTypes` sub-attribute should have "caseExact”: true, "uniqueness": "none", and "canonicalValues": ["User"]. The canonical values can also be set to ["User", "Group"], like in the `members` attribute in RFC7643, but since Group-in-Group relationships are rather rare among Service Providers, I’d prefer not to include "Group" in the example. I think this sub-attribute is not needed, see above.

## External Membership Management Schema Extension

The following is the formal SCIM schema definition for the `External Membership Management` schema extension. The attribute properties were provided in section 5.1 and are not repeated here:

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
  "id": "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group",
  "name": "External Membership Management",
  "description": "A schema extension for Group and group-like resources to provide metadata about their members if memberships are managed through dedicated resources.",
  "attributes": [
    {
      "name": "membersRef",
      … (see Section 5.1)
    },
    {
      "name": "memberCount",
      … (see Section 5.1)
    }
  ],
  "meta": {
    "resourceType": "Schema",
    "created": "2026-03-12T17:52:14Z",
    "lastModified": "2026-03-12T17:52:14Z",
    "location": https://example.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group<https://urldefense.com/v3/__https://example.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group__;!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDkkZ90_N$>
  }
}
```

> 8.2.2.  Usage
The URN for the extension is wrong. It should be "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group" in the text and examples.
The example is missing the `meta` attribute and it’s a duplicate of the example in Section 5.2.1.

> 8.3.  Security Considerations

> *   Access controls for `GroupMember` resources may be inherited from the parent `Group`. For example, a client that has permission to view a `Group` and its members should also have permission to `GET` the corresponding `GroupMember` resources.
> *   A client authorized to add or remove members from a `Group` (e.g., via a `PATCH` to the `Group` resource) should have equivalent permissions to `POST` and `DELETE` `GroupMember` resources for that same group.

I think, consistency should be a MUST:
*   Access controls for `GroupMember` resources MUST be consistent with the `members` attribute of the group. A client authorized to add or remove members from a Group (e.g., via a PATCH to the Group resource) MUST have equivalent permissions to POST or DELETE GroupMember resources for that same group. When a client has permission to read a group's `members` attribute, it MUST also have permission to `GET` the corresponding `GroupMember` resources.

> *   When a client attempts to retrieve one or more GroupMember resources, whether through a direct GET to a resource URI (/GroupMembers/{id}) or through a list request to the endpoint (/GroupMembers), the Service Provider's authorization decision MUST be based on the client's permission to read the parent Group. A client that has permission to read a Group resource MUST also be granted permission to retrieve any GroupMember resource where the group.value attribute matches the id of that Group. This policy mirrors the existing SCIM behavior where access to a Group resource implies access to its member list. A Service Provider MUST NOT require an additional authorization check on the member resource itself as a condition for retrieving a GroupMember resource.

This is not correct and would be a violation of the “need to know” principle. In SCIM, access to a resource does explicitly NOT imply access to every attribute of that resource. Access to the `userName` of a User does not imply access to his emails, photos, or empoyeeNumber. Access to a Group’s `displayName` does not imply access to its members. A User may be allowed to change his own `displayName` but only someone from the HR department may change his `name.lastName`.

Section 9.3 of RFC7643
> Ensure that access to data is appropriately restricted to authorized parties with a "need to know".

Section 3.3 of RFC7644
>   *  Service providers MAY take into account whether or not a client access to all of the resource's attributes when deciding or not non-asserted attributes should be defaulted.

Section 3.5.1 of RFC7644
> Service providers MAY take into account whether or not a client has access to, or understands, all of the resource's attributes when deciding whether non-asserted attributes SHALL be removed or defaulted.

> 8.4.  IANA Considerations
The URN "urn:ietf:params:scim:schemas:extension:groupMembers:2.0:Group" for the schema extension is missing here.



Classification: Restricted
Mit freundlichen Grüßen / Kind regards,
Dr. Matthias Winter
​​​​
Senior Software Architect
Beta Systems IAM Software AG
Development
Josef‑Lammerting‑Allee 14, 50933 Köln
Phone: [phone]<tel:+49%20221%2065015%20318>
Mobile: [phone]<tel:+49%20170%204175175>
Email: [e-mail]<mailto:[e-mail]>
www.betasystems.com<https://urldefense.com/v3/__https://eu.content.exclaimer.net/?url=https*3A*2F*2Fwww.betasystems.com*2F&tenantid=_BOyF-_tEe2QfAANOry0EQ&templateid=0ab19d971e48f0118f7d000d3ac24a6d&excomponentid=ZSgdkiBCR4gZQ1suDB02b8_UmSkyUXy8sBDE8_S6QLg&excomponenttype=Link&signature=ew7D3Yq24VG400gMHqsEI-0HJUQgmP_QKSFW5EMjnY1IV962HdY_zg2Iy5UiW96Srra8I6q9KcQGsY6urQFfVcvzpm3D3PPnVTDfyByJrCouA3_Ux65AeqlEcvpSy4mZvjF0xPVf9uvt5NkPoWVrTc406RJTkmpEbwMtJ9PnbV5Skb3NJpGynX_ZP5tm98r1G89BerwBGVK33IgbuHDnxR9Urh_D2TF073Urx5LOkUeSXqr6JBb5g1KKbQKopHrh3-462fiE2Am7NjRQO5oJdRkozKJ3QablFwN9n0l3Df6ftMowPo5JobPbYyjIJ0ZjmbTo08Hbl80YnzUOapCWzQ&v=1&imprintMessageId=9b8cbcd5-02dd-4782-b821-e9bf30638e92__;JSUlJQ!!PwKahg!7mUXSiOXbyANA4_Nxp3eU4qKHtxCwhmJGJX4gXVM8kYUJ3OCPXZL2EZIHx9SpC-G_HZNnfYAqMM74_o5LB-9xU8PDkD2WWp0$>

Mandatory information for business emails according to German trade laws / Pflichtangaben für geschäftliche E-Mails gemäß Handelsgesetzbuch und Aktiengesetz:
Beta Systems IAM Software AG, Ernst-Reuter-Platz 6, 10587 Berlin, Germany
Phone: [phone], Email: [e-mail]<mailto:[e-mail]>
​
Executive Board / Vorstand: Mirko Minnich, Gerald Schmedding | Chairman of the Supervisory Board / Vorsitzender des Aufsichtsrats: Dr. Wolfgang Schlaak
Legal Form / Rechtsform: Aktiengesellschaft | Registered Office / Sitz: Berlin | Commercial Register / Handelsregister: Amtsgericht Charlottenburg HRB 165007 B
VAT-ID / Ust-ID-Nr.: DE300760040 | Tax No. / St.-Nr.: 27/036/39045