要約

  • 10月28日の個人草案は、グループとメンバーの一対一の所属をGroupMembership資源として表す。所属を絞り込み、ページ単位で読み、特定の関係を削除できる設計だ。
  • 任意のmembersEmbeddedは、従来のGroup.membersが完全な名簿かどうかを示す。trueでも、要求側がmembersを除外した応答から「誰もいない」とは判断できない。

書き込めるのに、照合できない

RFC 7643では、所属者をグループの複数値属性membersに収める。草案の著者は、大規模なグループではこの応答が重くなり、サービスが属性を返さなかったり、クライアントが明示的に除外したりする状況を挙げる。すると追加・削除は送れても、サービス側に残る実際の所属と手元の予定表を突き合わせられない。草案はこの現象の市場全体での件数を独立に測定してはいない。論点は、操作と検証の間にある穴だ。

新しい/GroupMembershipsでは、サービス提供者が所属関係ごとに不透明なIDを発行する。グループIDで全員を探すことも、メンバーIDで所属先を探すことも、特定の組み合わせだけを取り出すこともできる。同じ組み合わせをもう一度作ろうとすれば、草案は競合エラーを要求する。権限を取り消す担当者は、巨大な配列を相手にする代わりに、一つの関係を指して削除できる。

肝心なのは、旧来のグループ応答をどう読むかだ。membersEmbedded: trueは、要求がmembersの返却を許している場合に限り、そこに現在の全員がいるという保証になる。要求側が属性を除外したなら、空欄は空のグループを意味しない。falseは完全性を保証しないという宣言で、たまたま全員が載っていても結論は同じ。印がない場合は従来のSCIMの解釈が続く。短い名簿を「退会済み」の証拠にする近道を塞ぐ仕組みだ。

新しい資源で提供すべき範囲は、照会するクライアントに閲覧権限のある所属すべて。従って、ある管理者に見える全件が組織全体の全件とは限らない。草案はグループとメンバーによる等価フィルター、少なくとも一種類のページングを求める。途中で所属が変わると番号式のページ境界がずれるため、カーソルを推奨する。安定した順序という約束も、照会中に元データが変わらない場合の話だ。

二つの更新窓口が共存するなら、提供者は両方を同期しなければならない。一方で削除した所属が他方に残れば、取消しの確認書が二枚の異なる名簿を指す。草案はグループやメンバーの削除時に関連する所属も消すよう求める。IETFの記録では、まだ作業部会に採用されていない個人草案である。採用判断と実装上の照合結果が次に必要な事実だ。

出典：草案原文、IETFの状態、RFC 7643、RFC 7644、RFC 9865。