要約

  • RFC 9865 は、同じ SCIM 問い合わせの次の結果ページへ進むための、不透明なカーソルを定める。
  • カーソルを持つことは追加の特権にならず、返す各リソースにはその時点の利用者 ID に対する認可が継続して適用される。

運用会議では、「一度検索できたなら、残りも見られる」という前提が静かに入り込みやすい。たとえば、夜間ジョブが最初のユーザー一覧を読み、nextCursor を保存し、その間に管理者が権限を変更する。朝になってジョブが続きを取得できたとしても、それは最初の許可が保存されたことを意味しない。RFC 9865 が扱うのは検索の継続位置であり、今この利用者が何を見てよいかを決める権限ではない。

開始と継続の規則は明確である。最初のカーソルページネーションでは cursor を空にするか省略する。その後の要求は同じサービス提供者 endpoint と、初回と同一のパラメータおよび値を使い、以前の応答のカーソル値だけを入れ替える。値はクライアントにとって opaque である。最後のページ以外には nextCursor が必要で、previousCursor は任意だが最初のページには置けない。これは一つの問い合わせを同一性のある会話として保つ規則である。結果集合の完全性や権限の持続を保証する規則ではない。

数字も過度に読んではならない。count は望む最大件数であり、提供者はそれを超えられないが、より少ない件数を返してよい。count=0 はリソースを返さず totalResults だけを求める使い方で、その totalResults も推定できない場合は省略可能である。表示された件数は、全件を取得した証明でも、次の瞬間に同じ対象が残る証明でもない。提供者はカーソルだけを唯一のページネーション方式にしてよいし、index と併用するなら既定方式を選択する。

重要なのは RFC が認可を現在形で書いている点だ。カーソルが別の actor の結果から入手された場合であっても、ページネーション結果は actor の current identity が許されたデータに厳密に限定されなければならない。actor が結果集合を進む間も authorization checks は継続し、カーソル所持を supplementary access privileges と解釈してはならない。この規則は、サーバが昨日発行した状態を理由に今日のローカルポリシーを迂回しないための境界である。

権限変更があれば、可能な場合にその actor のカーソルを直ちに無効化するのが望ましい。保持するなら、件数のようなメタデータを新しい権限範囲に合わせなければならない。偽造カーソルを識別できること、認可外ページと存在しないページを区別して秘密を漏らさないことも求められる。期限切れは権限取り消しの証拠ではなく、返答成功も過去の権限の延長証明ではない。いずれも限定された運用事実である。

もう一つの制約は可用性である。カーソルごとに大量の状態を保つ設計は、多数の初回検索によって枯渇させられるおそれがある。RFC は大きな結果集合への認証、rate limiting、カーソル数または page size の上限、資源効率のよい invalidation を勧める。設定が timeout や最大 page size を公開していないことを、制限がないという意味にしてはならない。共通仕様と実際の運用上限は同じものではない。

Heng Lu の見方なら、RFC 9865 は参加者が検証可能な小さな coordination artifact である。クライアントとサーバが次へ進む方法を共有しても、可視性の判断は local policy、実装、運用とその時点の identity に残る。カーソルは一覧を続ける。権限は応答ごとに改めて問われる。

Sources