Internet Engineering Task Force (IETF) M. Peterson, Ed.
Request for Comments: 9865 Entrust
Updates: 7643, 7644 D. Zollner
Category: Standards Track Independent
ISSN: 2070-1721 A. Sehgal
Amazon Web Services
October 2025
This document updates RFCs 7643 and 7644 by defining additional System for Cross-Domain Identity Management (SCIM) query parameters and result attributes to allow use of cursor-based pagination in SCIM service providers that are implemented with existing codebases, databases, or APIs where cursor-based pagination is already well established.
このドキュメントは、追加の System for Cross-Domain Identity Management (SCIM) クエリ パラメーターと結果属性を定義することによって RFC 7643 および 7644 を更新し、カーソル ベースのページネーションがすでに確立されている既存のコードベース、データベース、または API で実装されている SCIM サービス プロバイダーでカーソル ベースのページネーションを使用できるようにします。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9865.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9865 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Notational Conventions
1.2. Definitions
2. Query Parameters and Response Attributes
2.1. Pagination Errors
2.2. Sorting
2.3. Implementing Cursors as the Only Pagination Method
2.4. Implementing Both Cursors and Index Pagination
3. Querying Resources Using HTTP POST
4. Service Provider Configuration
5. Security Considerations
5.1. Threat Model and Security Environment
5.2. Confidentiality
5.3. Availability
5.4. Other Security References
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The two common patterns for result pagination are index-based pagination and cursor-based pagination. Rather than attempt to compare and contrast the advantages and disadvantages of competing pagination patterns, this document simply recognizes that System for Cross-Domain Identity Management (SCIM) service providers are commonly implemented as an interoperability layer on top of already existing application codebases, databases, and/or APIs that already have a well established pagination pattern.
結果のページネーションの 2 つの一般的なパターンは、インデックス ベースのページネーションとカーソル ベースのページネーションです。このドキュメントでは、競合するページネーション パターンの長所と短所を比較対照するのではなく、クロスドメイン ID 管理システム (SCIM) サービス プロバイダーは、一般に、十分に確立されたページネーション パターンを持つ既存のアプリケーション コードベース、データベース、および/または API 上の相互運用性レイヤーとして実装されることを単に認識しています。
Translating from an underlying cursor-based pagination pattern to the index-based pagination defined in Section 3.4.2.4 of [RFC7644] ultimately requires the SCIM service provider to fully iterate the underlying cursor, store the results, and then serve indexed pages from the stored results. This task of "pagination translation" increases complexity and memory requirements for implementing a SCIM service provider, and may be an impediment to SCIM adoption for some applications and identity systems.
基礎となるカーソルベースのページネーションパターンから、[RFC7644] のセクション 3.4.2.4 で定義されているインデックスベースのページネーションに変換するには、最終的に、SCIM サービスプロバイダーが基礎となるカーソルを完全に反復し、結果を保存し、保存された結果からインデックス付きページを提供する必要があります。この「ページネーション変換」タスクは、SCIM サービス プロバイダーを実装するための複雑さとメモリ要件を増大させ、一部のアプリケーションや ID システムでは SCIM の導入を妨げる可能性があります。
This document defines a simple addition to the SCIM protocol that allows SCIM service providers to reuse underlying cursors without expensive translation. Support for cursor-based pagination in SCIM encourages broader cross-application identity management interoperability by encouraging SCIM service provider implementations for applications and identity systems where cursor-based pagination is already well established.
この文書は、SCIM サービス プロバイダーがコストのかかる変換を行わずに基になるカーソルを再利用できるようにする、SCIM プロトコルへの簡単な追加機能を定義します。SCIM でのカーソル ベースのページネーションのサポートにより、カーソル ベースのページネーションがすでに確立されているアプリケーションおよび ID システムに対する SCIM サービス プロバイダーの実装が促進され、より広範なアプリケーション間の ID 管理の相互運用性が促進されます。
This document updates RFCs 7643 and 7644 because it adds attributes to existing structures from those documents, as described in Section 2. These changes are invoked when using the "cursor" parameter when making SCIM search requests using GET or POST methods.
この文書は、セクション 2 で説明されているように、RFC 7643 および 7644 の既存の構造に属性を追加するため、RFC 7643 および 7644 を更新します。これらの変更は、GET または POST メソッドを使用して SCIM 検索リクエストを行うときに「cursor」パラメーターを使用するときに呼び出されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the terms defined in Section 1.2 of [RFC7643].
この文書では、[RFC7643] のセクション 1.2 で定義されている用語を使用します。
The following table describes the URL pagination query parameters for requesting cursor-based pagination:
次の表では、カーソルベースのページネーションを要求するための URL ページネーション クエリ パラメーターについて説明します。
+===========+=====================================================+
| Parameter | Description |
+===========+=====================================================+
| cursor | The string value of the nextCursor attribute from a |
| | previous result page. The cursor value MUST be |
| | empty or omitted for the first request of a cursor- |
| | paginated query. This value may only contain |
| | characters from the unreserved character set |
| | defined in Section 2.3 of [RFC3986]. |
+-----------+-----------------------------------------------------+
| count | Specifies the desired maximum number of query |
| | results per page, e.g., 10. A negative value SHALL |
| | be interpreted as "0". A value of "0" indicates |
| | that no resource results are to be returned except |
| | for "totalResults". When specified, the service |
| | provider MUST NOT return more, although it MAY |
| | return fewer, results. If unspecified, the maximum |
| | number returned is set by the service provider. |
+-----------+-----------------------------------------------------+
Table 1: Query Parameters
表 1: クエリパラメータ
The following table describes cursor-based pagination attributes returned in a paged query response:
次の表では、ページ化されたクエリ応答で返されるカーソルベースのページネーション属性について説明します。
+================+================================================+
| Element | Description |
+================+================================================+
| nextCursor | A cursor value string that MAY be used in a |
| | subsequent request to obtain the next page of |
| | results. Service providers supporting cursor- |
| | based pagination MUST include nextCursor in |
| | all paged query responses except when |
| | returning the last page. nextCursor MUST be |
| | omitted from a response only to indicate that |
| | there are no more result pages. |
+----------------+------------------------------------------------+
| previousCursor | A cursor value string that MAY be used in a |
| | subsequent request to obtain the previous page |
| | of results. Returning previousCursor is |
| | OPTIONAL. previousCursor MUST NOT be returned |
| | with the first page. |
+----------------+------------------------------------------------+
Table 2: Response Attributes
表 2: 応答の属性
Cursor values are URL-safe strings that are opaque to the client. To retrieve another result page for a query, the client MUST query the same service provider endpoint with all query parameters and values being identical to the initial query with the exception of the cursor value, which SHOULD be set to a nextCursor (or previousCursor) value that was returned by the service provider in a previous response.
カーソル値は、クライアントに対して不透明な URL セーフな文字列です。クエリの別の結果ページを取得するには、クライアントは、カーソル値を除き、最初のクエリと同じすべてのクエリ パラメータと値を使用して、同じサービス プロバイダーのエンドポイントをクエリしなければなりません。カーソル値は、前の応答でサービス プロバイダーによって返された nextCursor (またはpreviousCursor) 値に設定される必要があります (SHOULD)。
For example, to retrieve the first 10 users with userName starting with J, use an empty cursor and set the count to 10:
たとえば、J で始まる userName を持つ最初の 10 人のユーザーを取得するには、空のカーソルを使用してカウントを 10 に設定します。
GET /Users?filter=userName%20sw%20J&cursor&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD
The SCIM service provider in response to the query above returns metadata regarding pagination similar to the following example (Resources omitted for brevity):
SCIM サービス プロバイダーは、上記のクエリに応答して、次の例のようなページネーションに関するメタデータを返します (簡潔にするためにリソースは省略しています)。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"totalResults":100,
"itemsPerPage":10,
"nextCursor":"VZUTiyhEQJ94IR",
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{
...
}]
}
Given the example above, to request the next page of results, use the same query parameters and values except set the cursor to the value of nextCursor (VZUTiyhEQJ94IR):
上記の例で、結果の次のページをリクエストするには、カーソルを nextCursor (VZUTiyhEQJ94IR) の値に設定することを除き、同じクエリ パラメーターと値を使用します。
GET /Users?filter=username%20sw%20J&cursor=VZUTiyhEQJ94IR&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD
The service provider responds with:
サービスプロバイダーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"totalResults": 100,
"itemsPerPage": 10,
"previousCursor: "ze7L30kMiiLX6x",
"nextCursor": "YkU3OF86Pz0rGv",
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{
...
}]
}
In the example above, the response includes the optional previousCursor indicating that the service provider supports forward and reverse traversal of result pages.
上記の例では、応答にはオプションのpreviousCursorが含まれており、サービスプロバイダーが結果ページの順方向および逆方向のトラバーサルをサポートしていることを示します。
As described in Section 3.4.1 of [RFC7644], service providers should return an accurate value for totalResults, which is the total number of resources for all pages. Service providers implementing cursor pagination that are unable to estimate totalResults MAY choose to omit the totalResults attribute.
[RFC7644] のセクション 3.4.1 で説明されているように、サービスプロバイダーは、全ページのリソースの合計数である totalResults の正確な値を返さなければなりません。totalResults を推定できないカーソル ページネーションを実装するサービス プロバイダーは、totalResults 属性を省略することを選択してもよい(MAY)。
If a service provider encounters invalid pagination query parameters (invalid cursor value, count value, etc) or other error conditions, the service provider SHOULD return the appropriate HTTP response status code and detailed JSON error response as defined in Section 3.12 of [RFC7644].
サービスプロバイダーが無効なページ分割クエリパラメーター (無効なカーソル値、カウント値など) またはその他のエラー状態に遭遇した場合、サービスプロバイダーは、[RFC7644] のセクション 3.12 で定義されているように、適切な HTTP 応答ステータス コードと詳細な JSON エラー応答を返す必要があります (SHOULD)。
For HTTP status code 400 (Bad Request) responses, the following detail error types are defined. These error types extend the list defined in Table 9 ("SCIM Detail Error Keyword Values") of Section 3.12 of [RFC7644]
HTTP ステータス コード 400 (Bad Request) 応答の場合、次の詳細エラー タイプが定義されています。これらのエラー タイプは、[RFC7644] セクション 3.12 の表 9 (「SCIM 詳細エラー キーワード値」) で定義されているリストを拡張します。
+===============+==================================+===============+
| scimType | Description | Applicability |
+===============+==================================+===============+
| invalidCursor | Cursor value is invalid. Cursor | GET (Section |
| | value SHOULD be empty to request | 3.4.2 of |
| | the first page and set to the | [RFC7644]) |
| | nextCursor or previousCursor | |
| | value for subsequent queries. | |
+---------------+----------------------------------+---------------+
| expiredCursor | Cursor has expired. Do not wait | GET (Section |
| | longer than service provider's | 3.4.2 of |
| | cursorTimeout to request | [RFC7644]) |
| | additional pages. | |
+---------------+----------------------------------+---------------+
| invalidCount | Count value is invalid. Count | GET (Section |
| | value must be between 0 and | 3.4.2 of |
| | service provider's maxPageSize | [RFC7644]) |
| | and must be equal to the count | |
| | value of the initial query. | |
+---------------+----------------------------------+---------------+
Table 3: Pagination Errors
表 3: ページネーション エラー
If sorting is implemented as described Section 3.4.2.3 of [RFC7644], then cursor-paged results should be sorted.
[RFC7644] のセクション 3.4.2.3 で説明されているようにソートが実装されている場合、カーソルでページングされた結果はソートされる必要があります。
A service provider MAY require cursor-based pagination to retrieve all results for a query by including a nextCursor value in the response, even when the query does not include the cursor parameter.
サービスプロバイダーは、クエリにカーソルパラメータが含まれていない場合でも、応答に nextCursor 値を含めることによってクエリのすべての結果を取得するために、カーソルベースのページネーションを必要とする場合があります (MAY)。
For example:
例えば：
GET /Users
Host: example.com
Accept: application/scim+json
The service provider may respond to the above query with a page containing defaultPageSize results and a nextCursor value as shown in the below example (Resources omitted for brevity):
サービス プロバイダーは、以下の例に示すように、defaultPageSize の結果と nextCursor 値を含むページで上記のクエリに応答する場合があります (簡潔にするためにリソースは省略しています)。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"totalResults": 5000,
"itemsPerPage": 100,
"nextCursor": "HPq72Pax3JUaNa",
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources": [{
...
}]
}
When a service provider supports both index-based and cursor-based pagination, clients can use the 'startIndex' or 'cursor' query parameters to request a specific method. Additionally, service providers supporting both pagination methods MUST choose a default pagination method to use when responding to requests that have not specified a pagination query parameter.
サービス プロバイダーがインデックス ベースとカーソル ベースの両方のページネーションをサポートしている場合、クライアントは 'startIndex' または 'cursor' クエリ パラメーターを使用して特定のメソッドをリクエストできます。さらに、両方のページネーション方法をサポートするサービスプロバイダーは、ページネーションクエリパラメータが指定されていないリクエストに応答するときに使用するデフォルトのページネーション方法を選択しなければなりません(MUST)。
Implementers of SCIM service providers that previously supported only index-based pagination and are adding support for cursor-based pagination should use index as the default pagination method to avoid incompatibility with clients that expect index-based pagination behaviors when no pagination query parameters are specified.
以前はインデックス ベースのページネーションのみをサポートしていて、カーソル ベースのページネーションのサポートを追加する SCIM サービス プロバイダーの実装者は、ページネーション クエリ パラメータが指定されていない場合にインデックス ベースのページネーション動作を期待するクライアントとの非互換性を避けるために、デフォルトのページネーション方法としてインデックスを使用する必要があります。
SCIM clients can query the Service Provider Configuration (Section 4) endpoint to determine if index-based, cursor-based, or both types of pagination are supported and which of these is the default.
SCIM クライアントは、サービス プロバイダーの構成 (セクション 4) エンドポイントをクエリして、インデックス ベース、カーソル ベース、または両方のタイプのページネーションがサポートされているかどうか、およびどちらがデフォルトであるかを判断できます。
Section 3.4.3 of [RFC7644] defines how clients may execute queries without passing parameters on the URL by using the POST verb combined with the /.search path extension execute. When posting to /.search, the client would pass the parameters defined in Section 2 in the body of the POST request. For example:
[RFC7644] のセクション 3.4.3 では、クライアントが URL にパラメータを渡さずに、/.search パス拡張子の実行と組み合わせた POST 動詞を使用してクエリを実行する方法を定義しています。/.search に投稿する場合、クライアントはセクション 2 で定義されたパラメータを POST リクエストの本文に渡します。例えば：
POST /User/.search
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
"attributes": ["displayName", "userName"],
"filter": "displayName sw \"smith\"",
"cursor": "",
"count": 10
}
Which would return a result containing a nextCursor value that may be used by the client in a subsequent call to return the next page of resources:
これは、クライアントが後続の呼び出しでリソースの次のページを返すために使用できる nextCursor 値を含む結果を返します。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"totalResults": 100,
"itemsPerPage": 10,
"nextCursor": "VZUTiyhEQJ94IR",
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources": [{
...
}]
}
The /ServiceProviderConfig resource defined in Section 4 of [RFC7644] facilitates discovery of SCIM service provider features. A SCIM service provider implementing cursor-based pagination SHOULD include the following additional attribute in a JSON document returned by the /ServiceProviderConfig endpoint:
[RFC7644] のセクション 4 で定義されている /ServiceProviderConfig リソースは、SCIM サービス プロバイダー機能の検出を容易にします。カーソルベースのページネーションを実装する SCIM サービス プロバイダーは、/ServiceProviderConfig エンドポイントによって返される JSON ドキュメントに次の追加属性を含めるべきです (SHOULD)。
pagination
ページネーション
A complex type that indicates pagination configuration options. OPTIONAL.
ページネーション構成オプションを示す複合タイプ。オプション。
The following sub-attributes are defined:
次のサブ属性が定義されています。
cursor
カーソル
A Boolean value specifying support of cursor-based pagination. REQUIRED.
カーソルベースのページネーションのサポートを指定するブール値。必須。
index
索引
A Boolean value specifying support of index-based pagination. REQUIRED.
インデックスベースのページネーションのサポートを指定するブール値。必須。
defaultPaginationMethod
デフォルトのページネーションメソッド
A string value specifying the type of pagination that the service provider defaults to when the client has not specified which method it wishes to use. Possible values are "cursor" and "index". OPTIONAL.
クライアントが使用するメソッドを指定していない場合に、サービス プロバイダーがデフォルトで使用するページネーションのタイプを指定する文字列値。可能な値は「カーソル」と「インデックス」です。オプション。
defaultPageSize
デフォルトのページサイズ
Positive integer value specifying the default number of results returned in a page when a count is not specified in the query. OPTIONAL.
クエリでカウントが指定されていない場合に、ページで返される結果のデフォルトの数を指定する正の整数値。オプション。
maxPageSize
maxPageSize
Positive integer specifying the maximum number of results returned in a page regardless of what is specified for the count in a query. The maximum number of results returned may be further restricted by other criteria. OPTIONAL.
クエリでのカウントの指定に関係なく、ページで返される結果の最大数を指定する正の整数。返される結果の最大数は、他の基準によってさらに制限される場合があります。オプション。
cursorTimeout
カーソルタイムアウト
Positive integer specifying the minimum number of seconds that a cursor is valid between page requests. Clients waiting too long between cursor pagination requests may receive an invalid cursor error response. No value being specified may mean that there is no cursor timeout or that the cursor timeout is not a static duration. OPTIONAL.
ページ要求間でカーソルが有効である最小秒数を指定する正の整数。カーソル ページネーション要求間の待ち時間が長すぎるクライアントは、無効なカーソル エラー応答を受け取る可能性があります。値が指定されていない場合は、カーソル タイムアウトがないこと、またはカーソル タイムアウトが静的期間ではないことを意味する可能性があります。オプション。
Service providers may choose not to advertise Service Provider Configuration information regarding default pagination method, page size, or cursor validity. Clients MUST NOT interpret the lack of published Service Provider Configuration values to mean that no defaults or limits on page sizes or cursor lifetimes exist, or that there is no default pagination method. Service providers may choose not to publish values for the pagination sub-attributes for many reasons. Examples include:
サービス プロバイダーは、デフォルトのページネーション方法、ページ サイズ、またはカーソルの有効性に関するサービス プロバイダー構成情報をアドバタイズしないことを選択できます。クライアントは、公開されたサービス プロバイダー設定値の欠如を、ページ サイズやカーソルの有効期間に関するデフォルトや制限が存在しない、またはデフォルトのページ分割方法が存在しないことを意味すると解釈してはなりません (MUST NOT)。サービスプロバイダーは、さまざまな理由により、ページネーションのサブ属性の値を公開しないことを選択する場合があります。例としては次のものが挙げられます。
* Service providers containing multiple resource types may have different values set for each resource type.
* 複数のリソース タイプを含むサービス プロバイダーは、リソース タイプごとに異なる値が設定されている場合があります。
* Default and maximum page size may be determined by factors besides or in addition to the number of resources returned, such as the size of each resource on the page.
* デフォルトおよび最大のページ サイズは、返されるリソースの数に加えて、またはページ上の各リソースのサイズなどの要因によって決定される場合があります。
Before using cursor-based pagination, a SCIM client MAY fetch the Service Provider Configuration document from the SCIM service provider and verify that cursor-based pagination is supported.
カーソルベースのページネーションを使用する前に、SCIM クライアントは SCIM サービスプロバイダからサービスプロバイダ設定文書をフェッチし、カーソルベースのページネーションがサポートされていることを確認してもよい(MAY)。
For example:
例えば：
GET /ServiceProviderConfig
Host: example.com
Accept: application/scim+json
A service provider supporting both cursor-based pagination and index-based pagination would return a document similar to the following (full ServiceProviderConfig schema defined in Section 5 of [RFC7643] has been omitted for brevity):
カーソルベースのページネーションとインデックスベースのページネーションの両方をサポートするサービスプロバイダーは、次のようなドキュメントを返します ([RFC7643] のセクション 5 で定義されている完全な ServiceProviderConfig スキーマは、簡潔にするために省略されています)。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"],
...
"pagination": {
"cursor": true,
"index": true,
"defaultPaginationMethod": "cursor",
"defaultPageSize": 100,
"maxPageSize": 250,
"cursorTimeout": 3600
},
...
}
This section elaborates on the security considerations associated with the implementation of cursor pagination in SCIM. This document is under the same security and privacy considerations of those described in [RFC7644]. It is imperative that implementers additionally consider the following security aspects to safeguard against both deliberate attacks and inadvertent misuse that may compromise the system's security posture.
このセクションでは、SCIM でのカーソル ページネーションの実装に関連するセキュリティ上の考慮事項について詳しく説明します。この文書は、[RFC7644] で説明されているものと同じセキュリティとプライバシーの考慮事項の下にあります。実装者は、システムのセキュリティ体制を損なう可能性のある意図的な攻撃と不注意による誤用の両方を防ぐために、次のセキュリティ面をさらに考慮することが不可欠です。
The threat landscape is characterized by two primary types of actors:
脅威の状況は、主に 2 つのタイプの攻撃者によって特徴付けられます。
1. Unauthenticated and Authenticated Malicious Actors: These individuals or entities represent a malevolent threat. Their objectives include unauthorized access to data, alteration, or deletion through cursor-enabled queries. They may also seek to deplete service provider resources deliberately, aiming to cause a denial-of-service state, thereby reducing service availability.
1. 未認証および認証済みの悪意のある行為者: これらの個人または団体は、悪意のある脅威を表します。その目的には、カーソル対応クエリによるデータへの不正アクセス、変更、削除が含まれます。また、サービス拒否状態を引き起こし、サービスの可用性を低下させることを目的として、サービス プロバイダーのリソースを意図的に枯渇させようとする場合もあります。
2. Authenticated Benign Users: This category includes legitimate users who, due to confusion or a lack of understanding, inadvertently engage in actions that consume service-provider resources excessively. Such actions, while not ill intended, can lead to unintended denial of service by overwhelming the service provider's capacity.
2. 認証された無害なユーザー: このカテゴリには、混乱または理解不足により、サービス プロバイダーのリソースを過度に消費するアクションを不用意に行ってしまう正規のユーザーが含まれます。このようなアクションは、悪意があるわけではありませんが、サービス プロバイダーの能力を超えて、意図しないサービス拒否につながる可能性があります。
To ensure that confidential data remains appropriately secured:
機密データが適切に保護された状態に保たれるようにするには、次の手順を実行します。
* Implementers MUST ensure that pagination through results sets is strictly confined to the data that the actor's current identity has been authorized to access. This holds true even in cases where the actor has obtained a cursor pertaining to a result set that was generated by a different actor.
* 実装者は、結果セットのページネーションが、アクターの現在の ID がアクセスを許可されているデータに厳密に限定されることを保証しなければなりません (MUST)。これは、アクターが別のアクターによって生成された結果セットに関連するカーソルを取得した場合にも当てはまります。
* Authorization checks MUST be continuously applied as an actor navigates through the result set associated with a cursor. Under no circumstances should possession of a cursor be interpreted as granting any supplementary access privileges to the actor.
* 認可チェックは、アクターがカーソルに関連付けられた結果セットをナビゲートする際に継続的に適用しなければなりません (MUST)。いかなる状況においても、カーソルの所有はアクターに追加のアクセス権限を与えるものとして解釈されるべきではありません。
* When possible, service providers SHOULD invalidate all cursors corresponding to an actor immediately following a change in permissions. This ensures that any queries executed post-permission change, utilizing old cursors, will be denied. As an alternative approach, service providers may opt to retain the existing cursors but must ensure that any metadata tied to the result set, such as record counts, is updated to reflect the new permissions accurately.
* 可能な場合、サービスプロバイダーは、アクセス許可の変更直後に、アクターに対応するすべてのカーソルを無効にする必要があります (SHOULD)。これにより、古いカーソルを利用して権限変更後に実行されたクエリは確実に拒否されます。別のアプローチとして、サービス プロバイダーは既存のカーソルを保持することを選択することもできますが、レコード数などの結果セットに関連付けられたメタデータが新しい権限を正確に反映するように更新されるようにする必要があります。
* In alignment with Section 2, cursor values are URL-safe strings that are opaque to clients. Service providers should obfuscate cursors values to prevent clients from interpreting cursors or forging new cursors. Service providers should be able to easily detect forged cursor values and immediately return an invalidCursor as described in Section 2.1.
* セクション 2 に従って、カーソル値はクライアントに対して不透明な URL セーフな文字列です。サービスプロバイダーは、クライアントがカーソルを解釈したり、新しいカーソルを偽造したりするのを防ぐために、カーソル値を難読化する必要があります。サービス プロバイダーは、セクション 2.1 で説明されているように、偽造されたカーソル値を簡単に検出し、ただちに validCursor を返せる必要があります。
* The service provider MUST handle error scenarios without exposing sensitive data. For instance, if an actor attempts to access a page of results outside their authorized scope, or if a request is made for a non-existent page, the service provider should respond with identical error messages, so as not to disclose any details of the underlying data or the nature of the authorization failure. It is acceptable, however, for the service provider to log different messages to a log accessible by administrators or other authorized personnel.
* サービスプロバイダーは、機密データを公開せずにエラーシナリオを処理しなければなりません。たとえば、攻撃者が承認された範囲外の結果のページにアクセスしようとした場合、または存在しないページに対してリクエストが行われた場合、サービス プロバイダーは、基礎となるデータの詳細や承認失敗の性質を開示しないように、同一のエラー メッセージで応答する必要があります。ただし、サービス プロバイダーが、管理者またはその他の権限のある担当者がアクセスできるログにさまざまなメッセージを記録することは許容されます。
The concern for availability primarily stems from the potential for Denial-of-Service (DoS) attacks. If the service provider elects to retain substantial data or metadata for each cursor, numerous initial queries that allocate cursors could strain and eventually exhaust service-provider resources. Such an attack could be orchestrated by an attacker with malicious intent or could occur unintentionally as a result of client testing or bugs.
可用性に対する懸念は主に、サービス拒否 (DoS) 攻撃の可能性から生じています。サービス プロバイダーが各カーソルの実質的なデータまたはメタデータを保持することを選択した場合、カーソルを割り当てる多数の初期クエリによって負荷がかかり、最終的にはサービス プロバイダーのリソースが使い果たされる可能性があります。このような攻撃は、悪意を持って攻撃者によって組織化される可能性もあれば、クライアントのテストやバグの結果として意図せず発生する可能性もあります。
To mitigate risks, the following strategies are recommended for service providers:
リスクを軽減するために、サービス プロバイダーには次の戦略が推奨されます。
* Clients should authenticate to retrieve large result sets. Anonymous queries yielding numerous results may return an HTTP status code 400 (Bad Request) with the error type "tooMany," as outlined in Section 3.12 of [RFC7644].
* クライアントは、大規模な結果セットを取得するために認証する必要があります。[RFC7644] のセクション 3.12 で概説されているように、多数の結果を生成する匿名クエリは、エラー タイプ「tooMany」とともに HTTP ステータス コード 400 (Bad Request) を返す場合があります。
* Implement rate limiting to control the volume and cadence of cursor requests. This approach should adhere to established standards for rate limiting; details can be found in [RFC6585].
* レート制限を実装して、カーソル要求の量と頻度を制御します。このアプローチは、確立されたレート制限の標準に準拠する必要があります。詳細は[RFC6585]を参照してください。
* Allow administrator of the service provider to set a ceiling on the number of cursors permissible at any given time or to specify a maxPageSize value. Guidance on configuring such values should be documented in the implementation administrator/installation guide.
* サービス プロバイダーの管理者は、いつでも許容されるカーソル数の上限を設定したり、maxPageSize 値を指定したりできます。このような値の構成に関するガイダンスは、実装管理者/インストール ガイドに文書化する必要があります。
* Cursor invalidation mechanisms (including mechanisms triggered by permissions changes) must be designed to be resource-efficient to prevent them from being exploited for DoS attacks.
* カーソル無効化メカニズム (権限の変更によってトリガーされるメカニズムを含む) は、DoS 攻撃に悪用されないようにリソース効率が高くなるように設計する必要があります。
Using URIs to describe and locate resources has its own set of security considerations, as discussed in Section 7 of [RFC3986]. Implementations should also refer to [BCP195] and [RFC9110] for additional security considerations that are relevant for underlying TLS and HTTP protocols.
[RFC3986] のセクション 7 で説明されているように、URI を使用してリソースを記述および検索するには、独自のセキュリティ上の考慮事項があります。実装では、基礎となる TLS および HTTP プロトコルに関連する追加のセキュリティ考慮事項について、[BCP195] および [RFC9110] も参照する必要があります。
IANA has amended the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group established by [RFC7643] as described below.
IANA は、[RFC7643] によって確立された「System for Cross-domain Identity Management (SCIM) Schema URIs」レジストリ グループを以下のように修正しました。
IANA has updated the "SCIM Schema URIs for Data Resources" registry as follows:
IANA は、「データ リソースの SCIM スキーマ URI」レジストリを次のように更新しました。
* For the urn:ietf:params:scim:api:messages:2.0:ListResponse, Section 2 of this document has been added to the References column.
* urn:ietf:params:scim:api:messages:2.0:ListResponse については、このドキュメントのセクション 2 が「参考文献」列に追加されました。
* For the urn:ietf:params:scim:api:messages:2.0:SearchRequest, Section 2 of this document has been added to the References column.
* urn:ietf:params:scim:api:messages:2.0:SearchRequest については、このドキュメントのセクション 2 が「参考文献」列に追加されました。
IANA has updated the "SCIM Server-Related Schema URIs" registry as follows:
IANA は、「SCIM サーバー関連スキーマ URI」レジストリを次のように更新しました。
* For the urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig, Section 4 of this document has been added to the References column.
* urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig については、このドキュメントのセクション 4 が「参考文献」列に追加されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <https://www.rfc-editor.org/info/rfc7643>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
The authors would also like to acknowledge the following individuals who provided valuable feedback while reviewing the document: Aaron Parecki, David Brossard, Dean H. Saxe, and Pamela Dingle.
著者らはまた、この文書のレビュー中に貴重なフィードバックを提供してくれた次の方々に謝意を表します: Aaron Parecki、David Brossard、Dean H. Saxe、および Pamela Dingle。
The authors would like to acknowledge the contribution of Paul Lanzi (IDenovate) in leading the writing of the Security Considerations section.
著者らは、「セキュリティに関する考慮事項」セクションの執筆を主導した Paul Lanzi (IDenovate) の貢献に感謝したいと思います。
Matt Peterson (editor)
Entrust
Email: matt.peterson@entrust.com
Danny Zollner
Independent
Email: danny@zollnerd.com
Anjali Sehgal
Amazon Web Services
Email: anjalisg@amazon.com