摘要

  • 10 月 28 日个人草案提出顶层 GroupMembership 资源，让客户按群组或成员筛选、分页读取，并直接定位一条成员关系。
  • 可选的 membersEmbedded 标记只回答一个问题：在请求允许返回成员数组时，true 保证数组完整；false 不作完整性承诺。需要核对授权范围内全量名单的客户，应查询 /GroupMemberships。

发送成功，不等于名单可查

现行 RFC 7643把成员放在 Group 的多值 members 属性里。这个模型简洁，却可能在大群组上变成一份沉重的响应。草案作者指出，有服务实现不返回成员属性，也有客户为减小响应主动排除它。客户仍能提交增删请求，却无法把自己的目标名单与服务端实际名单逐项对照。草案没有给出独立测量的市场比例，值得报道的是这处读写不对称本身。

新设计让“某成员属于某群组”拥有独立 ID。服务端生成的 ID 对客户不透明，但可以用于读取或删除该关系。筛选条件既可列出某组全部成员，也可追问一个用户属于哪些组；对同一群组和成员的重复创建应得到冲突响应。撤销权限的人因此可以找到明确的删除对象，而不是向巨大的数组盲目投递补丁。IETF 状态页把文本列为个人草案，尚无工作组采纳或 IESG 批准。

完整性标记比新网址更有分量。membersEmbedded: true 的前提是本次请求本来会返回 members；客户若主动排除了该属性，就不能把空白当作“没有成员”。false 则表示服务端不保证数组完整，即使数组碰巧列出了全部人也一样。没有这个标记时，继续按既有 SCIM 规则解释。这避免了最危险的误读：看到一个短名单，就把没出现的人当作已经离组。

草案要求新端点提供客户有权查看的每条成员关系。这个限定把权限边界放在盘点边界之前：查询结果可以完整覆盖授权视野，却不能自称全机构名册。端点需支持按群组 ID 和成员 ID 做相等筛选，并至少提供一种分页方式。草案偏好游标，因为读取过程中若名单变化，按序号翻页可能漏人或重复；稳定顺序承诺也以查询期间底层关系不变为条件。

真正棘手的是两套入口同时存在。如果服务端既接受旧的 Group members 改动，又接受新资源的创建和删除，就必须让两边状态同步。通过一边删人，另一边仍显示在组内，撤权就会变成两个互相矛盾的收据。草案把同步、关联删除以及父群组更新时间的责任交给服务端。客户不该靠猜测哪个接口才是真账本。

这份草案尚未变成标准，也没有提供具体服务部署的实测。改变判断的证据很明确：工作组决定，以及服务商在真实增删和分页读取中的一致性记录。

来源：个人草案原文；IETF 状态；RFC 7643；RFC 7644；RFC 9865。