[要約] RFC 9967は、SCIM（System for Cross-domain Identity Management）サービスプロバイダーと受信者間でのメッセージの非同期交換を可能にするため、Security Event Token（SET）仕様（RFC 8417）を用いたSCIMセキュリティイベント（非同期リクエスト完了、リソース複製、プロビジョニング調整など）のセットを規定する標準化トラック文書です。
Internet Engineering Task Force (IETF) P. Hunt, Ed.
Request for Comments: 9967 Independent Id
Updates: 7643, 7644 N. Cam-Winget
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Kiser
Sailpoint
J. Schreiber
Workday
May 2026
This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token (SET) specification (RFC 8417) to enable the asynchronous exchange of messages between SCIM service providers and receivers.
この仕様は、セキュリティ イベント トークン (SET) 仕様 (RFC 8417) を使用してクロスドメイン ID 管理システム (SCIM) セキュリティ イベントのセットを定義し、SCIM サービス プロバイダーと受信者間のメッセージの非同期交換を可能にします。
This specification updates RFC 7643 by defining additional attributes for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema, and it updates RFC 7644 with an optional new asynchronous SCIM request capability.
この仕様は、「urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig」スキーマの追加属性を定義することで RFC 7643 を更新し、オプションの新しい非同期 SCIM 要求機能で RFC 7644 を更新します。
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/rfc9967.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9967 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 and Overview
1.1. Requirements Language
1.2. Notational Conventions
1.3. Definitions
2. SCIM Events
2.1. Identifying the Subject of an Event
2.2. Common Event Attributes
2.3. SCIM Feed Events
2.3.1. urn:ietf:params:scim:event:feed:add
2.3.2. urn:ietf:params:scim:event:feed:remove
2.4. SCIM Provisioning Events
2.4.1. urn:ietf:params:scim:event:prov:create:{notice|full}
2.4.2. urn:ietf:params:scim:event:prov:patch:{notice|full}
2.4.3. urn:ietf:params:scim:event:prov:put:{notice|full}
2.4.4. urn:ietf:params:scim:event:prov:delete
2.4.5. urn:ietf:params:scim:event:prov:activate
2.4.6. urn:ietf:params:scim:event:prov:deactivate
2.5. Miscellaneous Events
2.5.1. Asynchronous Events
3. Set-Txn HTTP Response Header for Asynchronous Requests
4. Events Discovery Schema for Service Provider Configuration
5. Security Considerations
6. Privacy Considerations
7. IANA Considerations
7.1. SCIM Asynchronous Set-Txn Header Registration
7.2. Registering Event Capability with SCIM Service Provider
Configuration
7.3. Creation of the SCIM Event URIs Registry
7.4. Initial Contents of the SCIM Event URIs Registry
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Use Cases
A.1. Domain-Based Replication
A.2. Coordinated Provisioning
Acknowledgements
Authors' Addresses
This specification defines Security Events for SCIM service providers and receivers as specified by Security Event Tokens (SETs) [RFC8417]. In this specification, SCIM Security Events include asynchronous request completion, resource replication, and provisioning coordination.
この仕様は、セキュリティ イベント トークン (SET) [RFC8417] で指定されているように、SCIM サービス プロバイダーおよび受信者向けのセキュリティ イベントを定義します。この仕様では、SCIM セキュリティ イベントには、非同期リクエストの完了、リソース レプリケーション、およびプロビジョニング調整が含まれます。
This specification defines the use of the HTTP header "Prefer: respond-async" [RFC7240] to allow a SCIM client [RFC7644] to request an asynchronous response (see Section 2.5.1.1).
この仕様は、SCIM クライアント [RFC7644] が非同期応答を要求できるようにするための HTTP ヘッダー「Prefer: Reply-async」[RFC7240] の使用を定義します (セクション 2.5.1.1 を参照)。
Using the HTTP protocol, a SCIM client issues commands to a SCIM service provider using HTTP methods such as POST, PATCH, and DELETE [RFC7644] that cause a state change to a SCIM resource. When multiple independent SCIM clients update SCIM resources, individual clients become out of date as state changes occur. Some clients may need to be informed of these changes for coordination or reconciliation purposes. This could be done using periodic SCIM GET requests over time, but this rapidly becomes problematic as the number of changes and the number of resources increases.
HTTP プロトコルを使用すると、SCIM クライアントは、SCIM リソースの状態変更を引き起こす POST、PATCH、DELETE [RFC7644] などの HTTP メソッドを使用して SCIM サービス プロバイダーにコマンドを発行します。複数の独立した SCIM クライアントが SCIM リソースを更新すると、状態の変化が発生するため、個々のクライアントは古くなります。一部のクライアントには、調整または調整の目的でこれらの変更について通知する必要がある場合があります。これは、時間をかけて定期的な SCIM GET リクエストを使用して実行できますが、変更の数とリソースの数が増加すると、これは急速に問題になります。
SCIM Events can be shared over an established event feed enabling receivers to monitor and trigger independent asynchronous action. This approach enables greater scale and timeliness, where only changed information is exchanged between parties.
SCIM イベントは、確立されたイベント フィードを介して共有できるため、受信者は独立した非同期アクションを監視してトリガーできます。このアプローチにより、変更された情報のみが関係者間で交換されるため、より大きな規模と適時性が可能になります。
A SET conveys information about a state change that has occurred at a SCIM service provider. That SET may be of interest to one or more receivers. But instead of interpreting SETs as commands, each Event Receiver is able to determine the best local follow-up action to take within its own context. For example, a receiver can reconcile schema and resource type differences between domains.
SET は、SCIM サービス プロバイダーで発生した状態変化に関する情報を伝えます。その SET は 1 つ以上の受信機にとって興味深いものである可能性があります。ただし、SET をコマンドとして解釈する代わりに、各イベント レシーバーは、独自のコンテキスト内で実行する最適なローカル フォローアップ アクションを決定できます。たとえば、受信者はドメイン間のスキーマとリソース タイプの違いを調整できます。
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] で説明されているように解釈されます。
Throughout this document, all figures may contain spaces and extra line wrapping for readability and space limitations. Similarly, some URIs contained within examples have been shortened for space and readability reasons.
このドキュメント全体を通じて、読みやすさとスペースの制限のために、すべての図にスペースや余分な行の折り返しが含まれる場合があります。同様に、例に含まれる一部の URI は、スペースと読みやすさの理由から短縮されています。
This specification uses definitions from the following specifications:
この仕様は、次の仕様の定義を使用します。
* "JSON Web Token (JWT)" [RFC7519],
* 「JSON Web トークン (JWT)」[RFC7519]、
* "Security Event Token (SET)" [RFC8417], and
* 「セキュリティ イベント トークン (SET)」[RFC8417]、および
* "System for Cross-domain Identity Management: Protocol" [RFC7644].
* 「クロスドメイン ID 管理のためのシステム: プロトコル」[RFC7644]。
In JSON Web Tokens (JWTs) and Security Event Tokens, the term "claim" refers to JSON attribute values contained in a JWT [RFC7519] structure. The term "claim" in tokens is used to indicate that an attribute value may not be verified and its accuracy can be questioned. In the context of SCIM, this distinction is not made. For this specification, the terms "claims" and "attributes" are interchangeable. For consistency, JWT and SET attributes registered by IANA will continue to be called "claims", while event information attributes (i.e., those in an event payload) will be referred to as "attributes".
JSON Web トークン (JWT) およびセキュリティ イベント トークンでは、「クレーム」という用語は、JWT [RFC7519] 構造に含まれる JSON 属性値を指します。トークンの「クレーム」という用語は、属性値が検証されていない可能性があり、その正確性に疑問がある可能性があることを示すために使用されます。SCIM のコンテキストでは、この区別は行われません。この明細書では、「特許請求の範囲」と「属性」という用語は交換可能です。一貫性を保つため、IANA によって登録された JWT および SET 属性は引き続き「クレーム」と呼ばれますが、イベント情報属性 (つまり、イベント ペイロード内の属性) は「属性」と呼ばれます。
Additionally, the following terms are defined:
さらに、次の用語が定義されています。
Attributes and Claims:
属性とクレーム:
The JWT specification [RFC7519], upon which SET is based, uses the term "claims" to refer to attributes in a JSON Web Token. In contrast, SCIM uses the term "attributes" to refer to JSON attributes. For the purposes of this document, the terms "attributes" and "claims" are equivalent.
SET の基礎となっている JWT 仕様 [RFC7519] では、JSON Web トークンの属性を指すために「クレーム」という用語が使用されています。対照的に、SCIM では、JSON 属性を指すために「属性」という用語が使用されます。この文書の目的上、「属性」と「クレーム」という用語は同等です。
Coordinated Provisioning (CP):
調整されたプロビジョニング (CP):
As defined in Appendix A.2, in CP relationships, an Event Publisher and Receiver typically exchange resource change events without exchanging data (see Section 2.4). For a receiver to know the value of the data, the Event Receiver usually calls back to the SCIM Event Publisher domain to receive a new copy of data (e.g., uses a SCIM GET request).
付録 A.2 で定義されているように、CP 関係では、イベント パブリッシャーとレシーバーは通常、データを交換せずにリソース変更イベントを交換します (セクション 2.4 を参照)。受信者がデータの値を知るために、イベント レシーバーは通常、SCIM イベント パブリッシャー ドメインにコールバックして、データの新しいコピーを受信します (たとえば、SCIM GET リクエストを使用します)。
Domain-Based Replication (DBR):
ドメインベースのレプリケーション (DBR):
As defined in Appendix A.1, in the DBR mode, there is an administrative relationship spanning multiple operational domains; data shared in Events typically uses the "full" mode variation of change events (see Section 2.4) including the "data" payload attribute. This eliminates the need for a callback to retrieve additional data.
付録 A.1 で定義されているように、DBR モードでは、複数の運用ドメインにわたる管理関係が存在します。イベントで共有されるデータは通常、「データ」ペイロード属性を含む変更イベント (セクション 2.4 を参照) の「フル」モード バリエーションを使用します。これにより、追加のデータを取得するためのコールバックが不要になります。
Event Feed / Event Stream:
イベントフィード/イベントストリーム:
An event feed (or equivalently an event stream) is a logical series of events shared with a unique receiving client. A SET transfer (see [RFC8935] and [RFC8936]) service provider may offer to allow Event Receivers to "subscribe" to specific event types or events about specific resources (see feed events in Section 2.3).
イベント フィード (または同等のイベント ストリーム) は、固有の受信クライアントと共有される論理的な一連のイベントです。SET 転送 ([RFC8935] および [RFC8936] を参照) サービスプロバイダーは、イベントレシーバーが特定のイベントタイプまたは特定のリソースに関するイベントを「サブスクライブ」できるように提案する場合があります (セクション 2.3 のフィードイベントを参照)。
Event Receiver:
イベントレシーバー:
An entity typically receives events as described in [RFC8935] and [RFC8936] or via HTTP GET (see Section 2.5.1.1). In the case of push-based SET delivery [RFC8935], the Event Receiver is an HTTP endpoint that receives requests. In the case of poll-based SET delivery [RFC8936], the receiver is an HTTP client that initiates HTTP requests to an Event Publisher endpoint.
エンティティは通常、[RFC8935] および [RFC8936] で説明されているように、または HTTP GET (セクション 2.5.1.1 を参照) 経由でイベントを受信します。プッシュベースの SET 配信 [RFC8935] の場合、イベント レシーバーはリクエストを受信する HTTP エンドポイントです。ポーリングベースの SET 配信 [RFC8936] の場合、受信者は、イベント パブリッシャー エンドポイントへの HTTP リクエストを開始する HTTP クライアントです。
Event Publisher:
イベント発行者:
A system that issues SETs based on a resource state change that has occurred at a SCIM service provider. For example, events may be the result of a SCIM Create, Modify, or Delete operation as defined in Section 3 of [RFC7644]. A SCIM service provider may be an Event Publisher or an independent service that aggregates events into Event Receiver feeds. As described above, when using [RFC8935], the Event Publisher is an HTTP client that initiates HTTP POST requests to a defined Event Receiver endpoint. When using [RFC8936], the Event Publisher provides an HTTP endpoint, which a receiver may use to "poll" for Security Events.
SCIM サービス プロバイダーで発生したリソース状態の変更に基づいて SET を発行するシステム。たとえば、イベントは、[RFC7644] のセクション 3 で定義されている SCIM の作成、変更、または削除操作の結果である可能性があります。SCIM サービス プロバイダーは、イベント パブリッシャー、またはイベントをイベント レシーバー フィードに集約する独立したサービスの場合があります。上で説明したように、[RFC8935] を使用する場合、イベント パブリッシャーは、定義されたイベント レシーバー エンドポイントへの HTTP POST リクエストを開始する HTTP クライアントになります。[RFC8936] を使用する場合、イベント パブリッシャーは HTTP エンドポイントを提供し、受信者はこれを使用してセキュリティ イベントを「ポーリング」することができます。
SCIM Client:
SCIM クライアント:
An HTTP client that initiates SCIM protocol [RFC7644] requests and receives responses that may cause SCIM Events to be issued by the SCIM service provider. A SCIM client may also be an Event Receiver, typically when making an asynchronous SCIM request (see Section 2.5.1.1).
SCIM プロトコル [RFC7644] を開始する HTTP クライアントは、SCIM サービス プロバイダーによる SCIM イベントの発行を引き起こす可能性のある応答を要求および受信します。SCIM クライアントは、通常は非同期 SCIM リクエストを行う場合にイベント レシーバーになることもあります (セクション 2.5.1.1 を参照)。
SCIM Service Provider:
SCIM サービスプロバイダー:
An HTTP server that implements the SCIM protocol [RFC7644] and SCIM schema [RFC7643]. Upon processing a state change to a SCIM resource, it issues a SCIM Event or causes an Event Publisher to issue a SCIM Event.
SCIM プロトコル [RFC7644] および SCIM スキーマ [RFC7643] を実装する HTTP サーバー。SCIM リソースの状態変更を処理すると、SCIM イベントが発行されるか、イベント パブリッシャーに SCIM イベントが発行されます。
Security Event Token (SET):
セキュリティ イベント トークン (SET):
As defined in [RFC8417].
[RFC8417]で定義されているとおり。
A SCIM Event is a signal, in the form of a Security Event Token [RFC8417], that describes some event that has occurred. A SET event consists of a set of standard JWT "top-level" claims and an "events" claim that contains one or more event URI subclaims (JSON attributes) each with a JSON object containing relevant event information.
SCIM イベントは、セキュリティ イベント トークン [RFC8417] の形式で、発生したイベントを説明するシグナルです。SET イベントは、一連の標準 JWT の「トップレベル」クレームと、関連するイベント情報を含む JSON オブジェクトを含む 1 つ以上のイベント URI サブクレーム (JSON 属性) を含む「イベント」クレームで構成されます。
This specification defines the new URI prefix "urn:ietf:params:scim:event", which is used as the prefix for the defined SCIM Events (see Section 7.3). Events are grouped into one of two sub-namespaces: "feed" (feed control notices) or "prov" (provisioning).
この仕様では、新しい URI プレフィックス「urn:ietf:params:scim:event」を定義します。これは、定義された SCIM イベントのプレフィックスとして使用されます (セクション 7.3 を参照)。イベントは、「feed」 (フィード制御通知) または「prov」 (プロビジョニング) の 2 つのサブ名前空間のいずれかにグループ化されます。
SCIM Events MUST use the "sub_id" claim, defined by [RFC9493], to identify the subject of events. The "sub_id" claim MUST be contained within the main JWT claims body and MUST NOT be located within an event payload within the "events" claim. A SET with multiple event URIs indicates that the events arise from the same transaction or resource state change for a single resource or subject.
SCIM イベントは、イベントの主題を識別するために、[RFC9493] で定義されている「sub_id」クレームを使用しなければなりません (MUST)。「sub_id」クレームは、メインの JWT クレーム本文内に含める必要があり、「events」クレーム内のイベント ペイロード内に配置してはなりません。複数のイベント URI を持つ SET は、イベントが単一のリソースまたはサブジェクトの同じトランザクションまたはリソース状態の変化から発生することを示します。
The JWT "sub" claim MUST NOT be used to identify subjects to prevent confusion with JWT authorization tokens (originally recommended in Section 3 of [RFC8417]).
JWT 認可トークン (当初は [RFC8417] のセクション 3 で推奨) との混同を避けるために、JWT の「サブ」クレームをサブジェクトの識別に使用してはなりません (MUST NOT)。
{
"iss": "issuer.example.com",
"iat": 1508184845,
"aud": "aud.example.com",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "alice@example.com"
},
"events": {
...
}
}
Figure 1: Example SCIM Subject Id
図 1: SCIM サブジェクト ID の例
Instead of "sub", the top-level claim "sub_id" SHALL be used. "sub_id" contains the subclaim attribute "format" set to "scim" to indicate that the attributes present in the "sub_id" object are SCIM attributes. The following "sub_id" attributes are defined:
「sub」の代わりに、最上位クレーム「sub_id」を使用する必要があります(SHALL)。「sub_id」には、「sub_id」オブジェクトに存在する属性が SCIM 属性であることを示すために、「scim」に設定されたサブクレーム属性「format」が含まれています。次の「sub_id」属性が定義されています。
uri:
uri:
The SCIM relative path for the resource that usually consists of the resource type endpoint plus the resource "id" (see Section 3.2 of [RFC7644]), for example, "/Users/2b2f880af6674ac284bae9381673d462". This attribute MUST be provided in a SCIM Event "sub_id" claim. Note that the relative path is the path component after the SCIM service provider Base URI as defined in Section 1.3 of [RFC7644]. In cases where the Event Receiver is unable to match a URI, the Event Receiver MAY issue a callback to a previously agreed SCIM service provider Base URI plus the relative "uri" value and perform a SCIM GET request per Section 3.4.1 of [RFC7644].
リソースの SCIM 相対パス。通常、リソース タイプ エンドポイントとリソース「id」で構成されます ([RFC7644] のセクション 3.2 を参照)。たとえば、「/Users/2b2f880af6674ac284bae9381673d462」です。この属性は、SCIM イベントの「sub_id」クレームで指定する必要があります。相対パスは、[RFC7644] のセクション 1.3 で定義されている SCIM サービスプロバイダーのベース URI の後のパスコンポーネントであることに注意してください。イベント レシーバーが URI と一致できない場合、イベント レシーバーは、以前に合意された SCIM サービス プロバイダーのベース URI と相対的な "uri" 値にコールバックを発行し、[RFC7644] のセクション 3.4.1 に従って SCIM GET リクエストを実行してもよい(MAY)。
externalId:
外部ID:
If known, the "externalId" value (defined in Section 3.1 of [RFC7643]) of the SCIM resource that MAY be used by a receiver to identify the corresponding resource in the Event Receiver's domain.
既知の場合、SCIM リソースの「externalId」値 ([RFC7643] のセクション 3.1 で定義)。イベント受信側のドメイン内の対応するリソースを識別するために受信側で使用してもよい(MAY)。
id:
id:
The SCIM "id" attribute (defined in Section 3.1 of [RFC7643]) MAY be used for backwards compatibility reasons in addition to the "uri" claim.
SCIM の "id" 属性 ([RFC7643] のセクション 3.1 で定義) は、"uri" クレームに加えて、下位互換性の理由から使用してもよい(MAY)。
In cases where SCIM identifiers ("id" and "externalId") are not enough to identify a common resource between an Event Publisher and Event Receiver, the "sub_id" object MAY contain attributes whose SCIM attribute types have "uniqueness" set to "server" or "global" as per Section 7 of [RFC7643]. For example, attributes such as "emails" or "userName" (defined in Section 4 of [RFC7643]) are unique within a SCIM service provider. Such attributes should allow an Event Publisher and Event Receiver to identify a commonly understood subject resource of an event.
SCIM 識別子 (「id」と「externalId」) がイベント パブリッシャーとイベント レシーバー間の共通リソースを識別するのに十分でない場合、[RFC7643] のセクション 7 に従って、SCIM 属性タイプの「一意性」が「サーバー」または「グローバル」に設定されている属性を「sub_id」オブジェクトに含めてもよい(MAY)。たとえば、「emails」や「userName」（[RFC7643] のセクション 4 で定義）などの属性は、SCIM サービスプロバイダー内で一意です。このような属性により、イベント発行者とイベント受信者は、共通に理解されているイベントの主題リソースを識別できるようになります。
The following attributes are available for all events defined. Some attributes are defined as SET/JWT claims, while others are "event payload" claims as defined in Section 1.2 of [RFC8417]. Only one of the claims, "data" or "attributes", MUST be provided depending on the event definition.
次の属性は、定義されたすべてのイベントで使用できます。一部の属性は SET/JWT クレームとして定義されていますが、その他の属性は [RFC8417] のセクション 1.2 で定義されている「イベント ペイロード」クレームです。イベント定義に応じて、クレームの「データ」または「属性」の 1 つだけを指定する必要があります。
txn:
txn:
A SET-defined claim with a STRING value (see Section 2.2 of [RFC8417]) that uniquely identifies a transaction originating at a SCIM service provider and/or its underlying data repository or database where one or more SCIM Events may be subsequently issued. In contrast to a "jti" claim (see Section 4.1.7 of [RFC7519]), which uniquely identifies a token, the "txn" remains the same when one or more SETs are generated for various purposes such as retransmission, publication to multiple receivers, etc. A distinct state change or transaction within a SCIM service provider MAY result in multiple SETs issued each with distinct "jit" values and a common "txn" value. "txn" is REQUIRED to support asynchronous SCIM requests, CP, and replication to disambiguate or detect duplicate SETs regarding the same underlying transaction.
STRING 値を持つ SET 定義のクレーム ([RFC8417] のセクション 2.2 を参照)。これは、SCIM サービス プロバイダーおよび/またはその基礎となるデータ リポジトリまたはデータベースで発生するトランザクションを一意に識別します。このトランザクションでは、1 つ以上の SCIM イベントがその後発行される可能性があります。トークンを一意に識別する「jti」クレーム ([RFC7519] のセクション 4.1.7 を参照) とは対照的に、再送信、複数の受信者への公開などのさまざまな目的で 1 つ以上の SET が生成される場合、「txn」は同じままです。 SCIM サービスプロバイダー内での個別の状態変更またはトランザクションにより、それぞれ個別の「jit」値と共通の「txn」値を持つ複数の SET が発行される場合があります (MAY)。「txn」は、非同期 SCIM リクエスト、CP、および同じ基になるトランザクションに関する重複 SET を曖昧さをなくすか検出するレプリケーションをサポートするために必須です。
version:
バージョン:
The ETag version of the resource as a result of the event. Corresponds to the ETag response header described in Section 3.14 of [RFC7644].
イベントの結果としてのリソースの ETag バージョン。[RFC7644] のセクション 3.14 で説明されている ETag 応答ヘッダーに対応します。
data:
データ：
An event payload attribute that contains information described in the SCIM Bulk Operations "data" attribute in Section 3.7 of [RFC7644]. The JSON object contains the equivalent SCIM command processed by the SCIM service provider. For example, after processing a SCIM Create operation, the data contained includes the final representation of the entity created by the SCIM service provider including the assigned "id" value.
[RFC7644] のセクション 3.7 の SCIM Bulk Operations の「data」属性で説明されている情報を含むイベント ペイロード属性。JSON オブジェクトには、SCIM サービス プロバイダーによって処理される同等の SCIM コマンドが含まれています。たとえば、SCIM Create 操作を処理した後、含まれるデータには、割り当てられた「id」値を含む、SCIM サービス プロバイダーによって作成されたエンティティの最終表現が含まれます。
attributes:
属性:
A payload that contains an array of attributes that were added, revised, or removed. Names of modified attributes SHOULD conform to the ABNF syntax rule for "path" (Section 3.5.2 of [RFC7644]). For example: "attributes": ["userName","emails","name.familyName"].
追加、変更、または削除された属性の配列を含むペイロード。変更された属性の名前は、「パス」の ABNF 構文規則 ([RFC7644] のセクション 3.5.2) に準拠する必要があります (SHOULD)。例: "属性": ["userName","emails","name.familyName"]。
This section defines events related to changes in the content of an event feed such as SCIM resources that are being added or removed from an event feed or events used in Coordinated Provisioning scenarios where only a subset of entities are shared across an event feed. The URI prefix for these events is "urn:ietf:params:scim:event:feed".
このセクションでは、イベント フィードに追加または削除される SCIM リソースや、エンティティのサブセットのみがイベント フィード間で共有される調整プロビジョニング シナリオで使用されるイベントなど、イベント フィードのコンテンツの変更に関連するイベントを定義します。これらのイベントの URI プレフィックスは「urn:ietf:params:scim:event:feed」です。
The specified resource has been added to the event feed. A "feed:add" does not indicate that a resource is new or has been recently created. For example, an existing user has had a new role (e.g., CRM_User) added to their profile, which has caused their resource to join a feed.
指定されたリソースがイベント フィードに追加されました。「feed:add」は、リソースが新しいか、最近作成されたかを示すものではありません。たとえば、既存のユーザーのプロファイルに新しいロール (CRM_User など) が追加され、これによりそのユーザーのリソースがフィードに参加するようになりました。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"txn": "b7b953f11cc6489bbfb87834747cc4c1",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe"
},
"events":{
"urn:ietf:params:scim:event:feed:add": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 2: Example SCIM Feed Add Event
図 2: SCIM フィード追加イベントの例
The specified resource has been removed from the feed. Removal does not indicate that the resource was deleted or otherwise deactivated.
指定されたリソースはフィードから削除されました。削除は、リソースが削除されたか、非アクティブ化されたことを示すものではありません。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe",
},
"events":{
"urn:ietf:params:scim:event:feed:remove": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 3: Example SCIM Feed Remove Event
図 3: SCIM フィード削除イベントの例
This section defines resource changes that have occurred within a SCIM service provider. These events are used in both Domain-Based Replication (DBR) and Coordinated Provisioning (CP) mode. The URI prefix for these events is "urn:ietf:params:scim:event:prov".
このセクションでは、SCIM サービス プロバイダー内で発生したリソースの変更を定義します。これらのイベントは、ドメインベース レプリケーション (DBR) モードと調整プロビジョニング (CP) モードの両方で使用されます。これらのイベントの URI プレフィックスは「urn:ietf:params:scim:event:prov」です。
When the "data" payload attribute is included for each of the following events, the event URI MUST end with "full"; otherwise, the event URI ends with "notice". In "full" mode, the set of values reflecting the final representation of the resource (such as would be returned in a SCIM protocol response) at the service provider are provided using the "data" attribute (see Figure 4). In "notice" mode, the "attributes" attribute is returned and lists the set of attributes created or modified in the request (see Figure 5). Exactly one of the payload attributes, "data" or "attributes", MUST be present. Both MUST NOT be present simultaneously.
次の各イベントに「data」ペイロード属性が含まれる場合、イベント URI は「full」で終わる必要があります。それ以外の場合、イベント URI は「notice」で終わります。「フル」モードでは、サービス プロバイダーでのリソースの最終表現 (SCIM プロトコル応答で返されるものなど) を反映する値のセットが、「data」属性を使用して提供されます (図 4 を参照)。「notice」モードでは、「attributes」属性が返され、リクエスト内で作成または変更された属性のセットがリストされます (図 5 を参照)。ペイロード属性、「データ」または「属性」のいずれか 1 つが存在する必要があります。両方が同時に存在してはなりません。
The specified resource indicates that a new SCIM resource has been created by the SCIM service provider and has been added to the event feed. Note that because the event may be used for replication, the "id" attribute that was assigned by the SCIM service provider is shared so that all replicas in the domain MAY use the same resource identifier.
指定されたリソースは、新しい SCIM リソースが SCIM サービス プロバイダーによって作成され、イベント フィードに追加されたことを示します。イベントはレプリケーションに使用される可能性があるため、ドメイン内のすべてのレプリカが同じリソース識別子を使用できるように、SCIM サービス プロバイダーによって割り当てられた「id」属性が共有されることに注意してください。
{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9",
"externalId":"jdoe"
},
"events":{
"urn:ietf:params:scim:event:prov:create:full":{
"data":{
"schemas":[ "urn:ietf:params:scim:schemas:core:2.0:User"],
"emails":[
{"type":"work","value":"jdoe@example.com"}
],
"userName":"jdoe",
"name":{
"givenName":"John",
"familyName":"Doe"
}
}
}
}
}
Figure 4: Example SCIM Create Event (Full)
図 4: SCIM 作成イベントの例 (完全)
{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9",
"externalId": "jdoe"
},
"events": {
"urn:ietf:params:scim:event:prov:create:notice": {
"attributes": [
"id",
"name",
"userName",
"password",
"emails"
]
}
}
}
Figure 5: Example SCIM Create Event (Notice)
図 5: SCIM 作成イベントの例 (通知)
The event shown in Figure 5 notifies the Event Receiver of which attributes have changed, but it does not convey the actual information. The Event Receiver MAY retrieve that information by performing a SCIM GET based on the "sub_id" value provided.
図 5 に示すイベントは、どの属性が変更されたかをイベント レシーバーに通知しますが、実際の情報は伝えません。イベント レシーバーは、提供された "sub_id" 値に基づいて SCIM GET を実行することにより、その情報を取得してもよい (MAY)。
The specified resource has been updated using SCIM PATCH. In "full" mode, the "data" payload attribute is included (see Figure 6). When the event URI ends with "notice", the list of modified attributes is provided (see Figure 7).
指定されたリソースは SCIM PATCH を使用して更新されました。「フル」モードでは、「データ」ペイロード属性が含まれます (図 6 を参照)。イベント URI が「notice」で終わる場合、変更された属性のリストが提供されます (図 7 を参照)。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers"
},
"events":{
"urn:ietf:params:scim:event:prov:patch:full": {
"version": "a330bc54f0671c9",
"data": {
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"add",
"path":"members",
"value":[{
"display": "Babs Jensen",
"$ref": "/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646"
}]
}]
}
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 6: Example SCIM Patch Event (Full)
図 6: SCIM パッチ イベントの例 (フル)
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers"
},
"events":{
"urn:ietf:params:scim:event:prov:patch:notice": {
"attributes": ["members"],
"version": "a330bc54f0671c9"
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 7: Example SCIM Patch Event (Notice)
図 7: SCIM パッチ イベントの例 (通知)
The specified resource has been updated (e.g., one or more attributes has changed). In "full" mode, the SCIM PUT request body is included in the "data" attribute (see Figure 8). In "notice" mode, the modified attributes are listed using "attributes" (see Figure 9).
指定されたリソースが更新されました (たとえば、1 つ以上の属性が変更されました)。「フル」モードでは、SCIM PUT リクエストの本文が「データ」属性に含まれます (図 8 を参照)。「通知」モードでは、変更された属性が「属性」を使用してリストされます (図 9 を参照)。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"events":{
"urn:ietf:params:scim:event:prov:put:full": {
"version": "a330bc54f0671c9",
"data": {
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"jdoe",
"externalId":"jdoe",
"name":{
"formatted":"Mr. Jon Jack Doe III",
"familyName":"Doe",
"givenName":"Jon",
"middleName":"Jack"
},
"roles":[],
"emails":[
{"value":"jdoe@example.com"},
{"value":"anon@jdoe.org"}
]
}
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 8: Example SCIM Put Event (Full)
図 8: SCIM Put イベントの例 (フル)
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"events":{
"urn:ietf:params:scim:event:prov:put:notice": {
"version": "a330bc54f0671c9",
"attributes": ["userName","externalId","name","roles","emails"]
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 9: Example SCIM Put Event (Notice)
図 9: SCIM Put イベントの例 (通知)
The specified resource has been deleted from the SCIM service provider. The resource is also removed from the feed. When a DELETE is sent, a corresponding "feedRemove" SHALL NOT be issued. A delete event has no payload attributes. Note that because the delete event has no attributes, the qualifiers "full" and "notice" SHALL NOT be used.
指定されたリソースは SCIM サービス プロバイダーから削除されました。リソースはフィードからも削除されます。DELETE が送信されるとき、対応する "feedRemove" は発行されません (SHALL NOT)。削除イベントにはペイロード属性がありません。削除イベントには属性がないため、修飾子「full」と「notice」は使用してはいけないことに注意してください。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jDoe"
},
"events":{
"urn:ietf:params:scim:event:prov:delete": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 10: Example SCIM Delete Event
図 10: SCIM 削除イベントの例
The specified resource (e.g., User) has been "activated". This does not necessarily reflect any particular state change at the SCIM service provider but may simply indicate that the account defined by the SCIM resource is ready for use as agreed upon by the Event Publisher and Event Receiver. For example, an activated resource can represent an account that may be logged in.
指定されたリソース (例: ユーザー) は「アクティブ化」されています。これは、SCIM サービス プロバイダーでの特定の状態変化を必ずしも反映しているわけではなく、SCIM リソースによって定義されたアカウントが、イベント パブリッシャーとイベント レシーバーの合意に従って使用する準備ができていることを単に示している可能性があります。たとえば、アクティブ化されたリソースは、ログインできるアカウントを表すことができます。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462"
},
"events":{
"urn:ietf:params:scim:event:prov:activate": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 11: Example SCIM Activate Event
図 11: SCIM アクティブ化イベントの例
The specified resource (e.g., User) has been deactivated and disabled. The exact meaning SHOULD be agreed to by the Event Publisher and its corresponding Event Receiver. Typically, this means the subject may no longer have an active security session.
指定されたリソース (例: ユーザー) は非アクティブ化され、無効になっています。正確な意味については、イベント発行者とそれに対応するイベント受信者が同意する必要があります。通常、これは、サブジェクトがアクティブなセキュリティ セッションを持たなくなっている可能性があることを意味します。
This section defines related miscellaneous events such as asynchronous request completion that has occurred within a SCIM service provider. The URI prefix for these events is "urn:ietf:params:scim:event:misc".
このセクションでは、SCIM サービス プロバイダー内で発生した非同期リクエストの完了など、関連するさまざまなイベントを定義します。これらのイベントの URI プレフィックスは「urn:ietf:params:scim:event:misc」です。
A SCIM client making SCIM HTTP requests defined in Section 3 of [RFC7644] MAY request asynchronous processing using the "Prefer" HTTP header as defined in Section 4.1 of [RFC7240]. The client may do this for a number of reasons such as avoiding holding HTTP connections open during long requests because the result of the request is not needed or the result is delivered to another entity for further action for coordination reasons.
[RFC7644] のセクション 3 で定義されている SCIM HTTP リクエストを行う SCIM クライアントは、[RFC7240] のセクション 4.1 で定義されている「Prefer」HTTP ヘッダーを使用して非同期処理をリクエストしてもよい(MAY)。クライアントは、リクエストの結果が必要ないため、または調整上の理由からさらなるアクションのために結果が別のエンティティに配信されるため、長いリクエスト中に HTTP 接続を開いたままにすることを避けるなど、さまざまな理由でこれを行う可能性があります。
To initiate an asynchronous SCIM request, a normal SCIM protocol POST, PUT, PATCH, or DELETE request is performed with the HTTP "Prefer" header set to "respond-async" (Section 4.1 of [RFC7240]). The HTTP "Accept" header MUST be ignored for purposes of an asynchronous response. Additionally, per Section 4.3 of [RFC7240], the "wait" preference SHOULD be supported to establish a maximum time before a SCIM service provider MAY choose to respond asynchronously.
非同期 SCIM リクエストを開始するには、通常の SCIM プロトコルの POST、PUT、PATCH、または DELETE リクエストが、HTTP "Prefer" ヘッダーを "respond-async" に設定して実行されます ([RFC7240] のセクション 4.1)。HTTP "Accept" ヘッダーは、非同期応答の目的では無視しなければなりません (MUST)。さらに、[RFC7240] のセクション 4.3 に従って、SCIM サービスプロバイダーが非同期応答を選択してもよい (MAY) までの最大時間を確立するために、「待機」設定をサポートすべきです (SHOULD)。
In response, the SCIM service provider returns either a normal SCIM response or HTTP status code 202 (Accepted). The asynchronous response MUST contain no response body. To enable correlation of the future event, the HTTP response header "Set-Txn" (see Section 3) is returned with a value that MUST match the "txn" claim in a subsequent Security Event Token. Per [RFC7240], Section 3, the response will also include the "Preference-Applied" header. The "Location" header value MUST be one of the following: (a) a URI where the completion SCIM Event Token MAY be retrieved using HTTP GET or (b) the normal SCIM location header response specified by [RFC7644].
これに応じて、SCIM サービス プロバイダーは通常の SCIM 応答または HTTP ステータス コード 202 (Accepted) を返します。非同期応答には応答本文が含まれていてはなりません (MUST)。将来のイベントの相関を有効にするために、HTTP 応答ヘッダー「Set-Txn」(セクション 3 を参照) が、後続のセキュリティ イベント トークンの「txn」クレームと一致する必要がある値とともに返されます。[RFC7240] のセクション 3 に従って、応答には「Preference-Applied」ヘッダーも含まれます。"Location" ヘッダー値は、(a) HTTP GET を使用して完了 SCIM イベント トークンを取得できる URI、または (b) [RFC7644] で指定された通常の SCIM ロケーション ヘッダー応答のいずれかでなければなりません。
In the following non-normative example, a "Prefer" header is set to "respond-async":
次の非標準的な例では、「Prefer」ヘッダーが「respond-async」に設定されています。
PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: scim.example.com
Prefer: respond-async
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"userName":"bjensen",
"externalId":"bjensen",
"name":{
"formatted":"Ms. Barbara J Jensen III"
},
"roles":[],
"emails":[
{
"value":"bjensen@example.com"
}
]
}
Figure 12: Example Asynchronous SCIM Protocol Request
図 12: 非同期 SCIM プロトコル リクエストの例
The SCIM service provider responds with HTTP status code 202 (Accepted) and includes the Set-Txn header:
SCIM サービス プロバイダーは、Set-Txn ヘッダーを含む HTTP ステータス コード 202 (Accepted) で応答します。
HTTP/1.1 202 Accepted
Set-Txn: 734f0614e3274f288f93ac74119dcf78
Preference-Applied: respond-async
Location:
"/Users/2819c223-7f76-453a-919d-413861904646"
Figure 13: Async SCIM Request with Prefer Header
図 13: 優先ヘッダーを含む非同期 SCIM リクエスト
Section 3.7 of [RFC7644] provides the ability to submit multiple SCIM operations in a single "bulk" request. When an asynchronous response is requested, a single Asynchronous Request Completion Event MUST be generated for each requested operation. For example, if a single "bulk" request had 10 operations, then 10 Asynchronous Event completion events would be generated.
[RFC7644] のセクション 3.7 は、単一の「一括」リクエストで複数の SCIM オペレーションを送信する機能を提供します。非同期応答が要求された場合、要求された操作ごとに 1 つの非同期要求完了イベントを生成しなければなりません (MUST)。たとえば、1 つの「一括」リクエストに 10 個の操作がある場合、10 個の非同期イベント完了イベントが生成されます。
The "txn" claim MUST be set to the value originally returned to the requesting SCIM client (see Section 2.5.1.1) appended with a colon ":" and the zero-based array index of the operation expressed in the "Operations" attribute of the original bulk request. The "bulkId" parameter MUST NOT be used for this purpose as it is a temporary identifier and is not required for every operation.
「txn」クレームは、リクエスト元の SCIM クライアントに最初に返された値 (セクション 2.5.1.1 を参照) にコロン「:」と、元の一括リクエストの「Operations」属性で表現されたオペレーションの 0 から始まる配列インデックスを付加した値に設定しなければなりません (MUST)。「bulkId」パラメータは一時的な識別子であり、すべての操作に必要なわけではないため、この目的で使用してはなりません。
For example, if a SCIM service provider received a bulk request with two or more operations, and had a "txn" claim value of "2d80e537a3f64622b0347b641ebc8f44", then the first Asynchronous Response Event Token representing the first operation has a "txn" claim value of "2d80e537a3f64622b0347b641ebc8f44:0", the second operation has a value of "2d80e537a3f64622b0347b641ebc8f44:1", and so on.
たとえば、SCIM サービス プロバイダーが 2 つ以上の操作を含む一括リクエストを受信し、「txn」クレーム値が「2d80e537a3f64622b0347b641ebc8f44」である場合、最初の操作を表す最初の非同期応答イベント トークンの「txn」クレーム値は次のようになります。「2d80e537a3f64622b0347b641ebc8f44:0」、2 番目の操作の値は「2d80e537a3f64622b0347b641ebc8f44:1」などとなります。
If a SCIM service provider optimizes the sequence of operations (per Section 3.7 of [RFC7644]), the Asynchronous Request Completion Events MAY be generated out of sequence from the original request. In this case, the "txn" claims in those events MUST use operation numbers that correspond to the order in the original request.
SCIM サービスプロバイダーが操作のシーケンスを最適化する場合 ([RFC7644] のセクション 3.7 に従って)、非同期リクエスト完了イベントは元のリクエストとは異なる順序で生成されてもよい(MAY)。この場合、それらのイベントの「txn」クレームは、元のリクエストの順序に対応する操作番号を使用しなければなりません (MUST)。
The Asynchronous Response Event signals the completion of a SCIM request. The event payload contains the attributes defined in Section 3.7 of [RFC7644] and is the same as a single SCIM Bulk Response Operation as per Section 3.7.3 of [RFC7644]. In the event, the "txn" claim MUST be set to the value originally returned to the requesting SCIM client (see Section 2.5.1.1).
非同期応答イベントは、SCIM 要求の完了を通知します。イベントペイロードには、[RFC7644] のセクション 3.7 で定義された属性が含まれており、[RFC7644] のセクション 3.7.3 による単一の SCIM バルク応答オペレーションと同じです。この場合、「txn」クレームは、要求元の SCIM クライアントに最初に返された値に設定されなければなりません (セクション 2.5.1.1 を参照)。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"txn": "734f0614e3274f288f93ac74119dcf78",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 14: Example SCIM Asynchronous Response Event
図 14: SCIM 非同期応答イベントの例
If an error occurs during asynchronous processing, the event operation MUST include a "response" attribute indicating a non-200-series HTTP status as defined in Section 3.7 of [RFC7644], and that "response" attribute MUST contain the sub-attributes defined in Section 3.12 of [RFC7644]. The "status" attribute of the event operation typically matches the "status" attribute of the response.
非同期処理中にエラーが発生した場合、イベント操作には、[RFC7644] のセクション 3.7 で定義されている非 200 シリーズ HTTP ステータスを示す "response" 属性が含まれなければなりません (MUST)。また、その "response" 属性には、[RFC7644] のセクション 3.12 で定義されているサブ属性が含まれなければなりません (MUST)。通常、イベント操作の「ステータス」属性は、応答の「ステータス」属性と一致します。
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"txn": "734f0614e3274f288f93ac74119dcf78",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "400",
"response": {
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
],
"scimType":"invalidSyntax",
"detail": "Request is unparsable",
"status":"400"
}
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 15: Example SCIM Asynchronous Error Response Event
図 15: SCIM 非同期エラー応答イベントの例
The following four figures show asynchronous completion events for the example in Section 3.7.3 of [RFC7644].
次の 4 つの図は、[RFC7644] のセクション 3.7.3 の例の非同期完了イベントを示しています。
{
"jti": "dbae9d7506b34329aa7f2f0d3827848b",
"sub_id": {
"format": "scim",
"uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a"
},
"txn": "2d80e537a3f64622b0347b641ebc8f44:1",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "POST",
"bulkId": "qwerty",
"version": "W\/\"oY4m4wn58tkVjJxK\"",
"status": "201"
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 16: Example SCIM Asynchronous Response Event Operation (1 of 4)
図 16: SCIM 非同期応答イベント操作の例 (1/4)
{
"jti": "ca977d05ba5c43929e3a69023d5392a9",
"sub_id": {
"format": "scim",
"uri": "/Users/b7c14771-226c-4d05-8860-134711653041"
},
"txn": "2d80e537a3f64622b0347b641ebc8f44:2",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
}
},
"iat": 1458505045,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 17: Example SCIM Asynchronous Response Event Operation (2 of 4)
図 17: SCIM 非同期応答イベント操作の例 (2/4)
{
"jti": "4bb87d70a4ab463bbdcd1f99111cbbf1",
"sub_id": {
"format": "scim",
"uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc"
},
"txn": "2d80e537a3f64622b0347b641ebc8f44:3",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PATCH",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
}
},
"iat": 1458505046,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 18: Example SCIM Asynchronous Response Event Operation (3 of 4)
図 18: SCIM 非同期応答イベント操作の例 (3/4)
{
"jti": "6a7843a7f5244d0eb62ca38b641d9139",
"sub_id": {
"format": "scim",
"uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b"
},
"txn": "2d80e537a3f64622b0347b641ebc8f44:4",
"events":{
"urn:ietf:params:scim:event:misc:asyncresp": {
"method": "DELETE",
"status": "204"
}
},
"iat": 1458505047,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 19: Example SCIM Asynchronous Response Event Operation (4 of 4)
図 19: SCIM 非同期応答イベント操作の例 (4/4)
This specification defines a new HTTP header field, "Set-Txn", which serves the purpose of conveying request completion information to SCIM HTTP clients that request an asynchronous response as described in Section 2.5.1.1. The header field MUST be used in SCIM responses when HTTP status code 202 (Accepted) is being returned with no message body.
この仕様では、新しい HTTP ヘッダー フィールド「Set-Txn」を定義します。このフィールドは、セクション 2.5.1.1 で説明されているように、非同期応答を要求する SCIM HTTP クライアントに要求完了情報を伝達する目的を果たします。メッセージ本文なしで HTTP ステータス コード 202 (Accepted) が返される場合、SCIM 応答でヘッダー フィールドを使用しなければなりません (MUST)。
The "Set-Txn" HTTP header field value is a unique STRING (e.g., a Globally Unique Identifier (GUID)) used by the SCIM HTTP client to look for a matching SET event with a matching "txn" claim (see Section 2 of [RFC8417]) confirming the request completion status as described in Section 2.5.1.1.
「Set-Txn」HTTP ヘッダーフィールド値は、セクション 2.5.1.1 で説明されているようにリクエスト完了ステータスを確認する、一致する「txn」クレーム ([RFC8417] のセクション 2 を参照) を持つ一致する SET イベントを探すために SCIM HTTP クライアントによって使用される一意の STRING (例: Globally Unique Identifier (GUID)) です。
Intermediaries SHOULD NOT insert, modify, or delete the field's value.
仲介者はフィールドの値を挿入、変更、削除してはなりません。
SCIM clients MAY ignore the header in cases where confirmation of completion is not required. For example, a SCIM client may simply not want to wait for synchronous completion.
SCIM クライアントは、完了の確認が必要ない場合、ヘッダーを無視してもよい(MAY)。たとえば、SCIM クライアントは単に同期の完了を待ちたくない場合があります。
Section 5 of [RFC7643] defines SCIM service provider configuration schemas. This section defines additional attributes that enable a SCIM client to discover the additional capabilities defined by this specification.
[RFC7643] のセクション 5 では、SCIM サービスプロバイダーの構成スキーマを定義しています。このセクションでは、SCIM クライアントがこの仕様で定義されている追加機能を検出できるようにする追加の属性を定義します。
securityEvents:
セキュリティイベント:
A SCIM complex attribute that specifies the available capabilities related to asynchronous Security Events based on [RFC8417]. This attribute is OPTIONAL, and when absent, it indicates the SCIM service provider does not support or is not currently configured for Security Events. The following sub-attributes are defined:
[RFC8417] に基づいて、非同期セキュリティ イベントに関連する利用可能な機能を指定する SCIM 複合属性。この属性はオプションであり、存在しない場合は、SCIM サービス プロバイダーがセキュリティ イベントをサポートしていないか、現在セキュリティ イベント用に構成されていないことを示します。次のサブ属性が定義されています。
asyncRequest:
非同期リクエスト:
A case-insensitive string value specifying one of the following:
次のいずれかを指定する、大文字と小文字を区別しない文字列値。
* "none" indicates that asynchronous SCIM requests defined in Section 2.5.1.1 are not supported;
* 「none」は、セクション 2.5.1.1 で定義された非同期 SCIM リクエストがサポートされていないことを示します。
* "long" indicates that the server completes requests asynchronously at the server's discretion (e.g., based on a max wait time); and
* 「long」は、サーバーがサーバーの裁量で (たとえば、最大待機時間に基づいて) リクエストを非同期で完了することを示します。そして
* "request" indicates that the server completes requests asynchronously when requested by the SCIM client.
* 「request」は、SCIM クライアントから要求されたときにサーバーが非同期で要求を完了することを示します。
eventUris:
イベントUris:
A multivalued string listing the SET Event URIs (defined in [RFC8417]) that the server is capable of generating and delivering via a SET Stream (see [RFC8935] and [RFC8936]). This information is informational only. Stream registration and configuration are out of scope of this specification.
サーバーが生成し、SET ストリーム経由で配信できる SET イベント URI ([RFC8417] で定義) をリストする複数値の文字列 ([RFC8935] および [RFC8936] を参照)。この情報は情報提供のみを目的としています。ストリームの登録と構成は、この仕様の範囲外です。
As this specification is based upon the SETs specification and the associated delivery specifications, the following security considerations are also applicable to this specification:
この仕様は SET 仕様および関連する配信仕様に基づいているため、次のセキュリティ上の考慮事項もこの仕様に適用されます。
* Section 5 of [RFC8417] (Security Event Token)
* [RFC8417] のセクション 5 (セキュリティ イベント トークン)
* Section 5 of [RFC8935] (Push-Based SET Delivery Using HTTP)
* [RFC8935] のセクション 5 (HTTP を使用したプッシュベースの SET 配信)
* Section 4 of [RFC8936] (Poll-Based SET Delivery Using HTTP)
* [RFC8936] のセクション 4 (HTTP を使用したポーリングベースの SET 配信)
SETs may contain sensitive information, including Personally Identifiable Information (PII). In such cases, SET Transmitters and SET Recipients MUST protect the confidentiality of the SET contents in transit using TLS [BCP195].
SET には、個人を特定できる情報 (PII) などの機密情報が含まれる場合があります。このような場合、SET 送信者と SET 受信者は、TLS [BCP195] を使用して、送信中の SET コンテンツの機密性を保護しなければなりません (MUST)。
When coordinating provisioning between entities, the long-term series of changes may be critical to the information integrity and recovery requirements of both sides. To address this, Event Publishers can make events available for receivers for longer periods of time than might typically be used for recovering from momentary delivery failures and retries per [RFC8935] or [RFC8936]. Similarly, Event Receivers MUST ensure events are persisted directly or indirectly to meet local recovery needs before acknowledging the SET Events were received.
エンティティ間のプロビジョニングを調整する場合、長期にわたる一連の変更は、双方の情報の完全性と回復要件にとって重要となる場合があります。これに対処するために、イベント パブリッシャーは、[RFC8935] または [RFC8936] に従って、一時的な配信失敗や再試行からの回復に通常使用されるよりも長い期間、受信者がイベントを利用できるようにすることができます。同様に、イベント レシーバーは、SET イベントの受信を確認する前に、ローカルの回復ニーズを満たすために、イベントが直接的または間接的に永続化されていることを確認しなければなりません (MUST)。
An attacker might leverage transaction and/or signal information contained in a SET Event Publisher or Receiver system. To mitigate this, access to event recovery and forwarding MUST be limited to the parties needed to support recovery or SET forwarding.
攻撃者は、SET イベント パブリッシャー システムまたはレシーバー システムに含まれるトランザクション情報やシグナル情報を利用する可能性があります。これを軽減するには、イベントの回復と転送へのアクセスを、回復または SET 転送をサポートするために必要な関係者に限定しなければなりません (MUST)。
When SET Events are transferred in such a way that the Event Publisher is not communicating directly to the Event Receiver, it may become possible for an attacker or other system to insert an event. To mitigate, Event Receivers MUST verify the originator of a SET using JSON Web Signature (JWS) [RFC7515] signatures when the Event Publisher is not communicating directly with the Event Receiver. Validating event signatures may also be useful for auditing purposes as signed SET Events are protected from tampering in the event that an intermediate system, such as a TLS-terminating proxy, decrypts the SET payload before sending it onward to its intended recipient.
イベント パブリッシャーがイベント レシーバーと直接通信しない方法で SET イベントが転送されると、攻撃者または他のシステムがイベントを挿入できる可能性があります。軽減するために、イベント パブリッシャーがイベント レシーバーと直接通信していない場合、イベント レシーバーは JSON Web Signature (JWS) [RFC7515] 署名を使用して SET の発信者を検証しなければなりません (MUST)。イベント署名の検証は、TLS 終端プロキシなどの中間システムが SET ペイロードを目的の受信者に送信する前に復号化する場合に、署名付き SET イベントが改ざんから保護されるため、監査目的にも役立ちます。
In operation, some SCIM resources such as SCIM Groups may have a high rate of change. For example, groups with more than a few thousand member values could lead to excessive change rates, which could lead to a loss of SET Events between Event Publishers and Event Receivers. To mitigate this risk, consider the following to help with throughput issues:
運用中、SCIM グループなどの一部の SCIM リソースは、変更率が高い場合があります。たとえば、数千を超えるメンバー値を持つグループでは、過度の変更率が発生し、イベント パブリッシャーとイベント レシーバーの間で SET イベントが失われる可能性があります。このリスクを軽減するには、スループットの問題を解決するために次の点を考慮してください。
* The use of SCIM PUT (Section 3.5.1 of [RFC7644]), particularly with large SCIM Groups, can result in excessive data being conveyed in Security Event payloads. Instead, it is RECOMMENDED to use SCIM PATCH (Section 3.5.2 of [RFC7644]) to focus on updating and notifying about changed information. Alternatively, use SCIM PUT Event Notice (urn:ietf:params:scim:event:prov:put:notice) as a trigger to later retrieve the full information when needed.
* 特に大規模な SCIM グループで SCIM PUT ([RFC7644] のセクション 3.5.1) を使用すると、セキュリティ イベント ペイロードで過剰なデータが伝達される可能性があります。代わりに、SCIM PATCH ([RFC7644] のセクション 3.5.2) を使用して、変更された情報の更新と通知に重点を置くことが推奨されます。あるいは、SCIM PUT イベント通知 (urn:ietf:params:scim:event:prov:put:notice) をトリガーとして使用し、後で必要なときに完全な情報を取得します。
* Use SCIM Patch Event Notice (urn:ietf:params:scim:event:prov:patch:notice) to reduce event content combined with periodic SCIM GETs (see Section 3.4 of [RFC7644]) to retrieve current group state.
* SCIM パッチ イベント通知 (urn:ietf:params:scim:event:prov:patch:notice) を使用してイベント コンテンツを削減し、定期的な SCIM GET ([RFC7644] のセクション 3.4 を参照) と組み合わせて現在のグループ状態を取得します。
* Aggregate multiple PATCH Events into a single event. If providing the exact date of each membership change is not critical, consider using a PATCH to aggregate multiple membership changes into a single event.
* 複数の PATCH イベントを 1 つのイベントに集約します。各メンバーシップ変更の正確な日付を提供することが重要ではない場合は、PATCH を使用して複数のメンバーシップ変更を 1 つのイベントに集約することを検討してください。
When using asynchronous SCIM requests (see Section 2.5.1.1), a SCIM service provider returns a SCIM Accepted response with a URI for retrieving the event result. An unauthorized entity or attacker could obtain Asynchronous Request Completion Event information by querying the asynchronous operation result endpoint used by a SCIM service provider. To mitigate, the returned URI endpoint MUST be protected and requires an HTTP Authorization header or some other form of client authentication.
非同期 SCIM リクエスト (セクション 2.5.1.1 を参照) を使用する場合、SCIM サービス プロバイダーは、イベント結果を取得するための URI を含む SCIM Accepted 応答を返します。権限のないエンティティまたは攻撃者は、SCIM サービス プロバイダーが使用する非同期操作結果エンドポイントにクエリを実行することにより、非同期要求完了イベント情報を取得する可能性があります。軽減するには、返された URI エンドポイントを保護する必要があり、HTTP Authorization ヘッダーまたはその他の形式のクライアント認証が必要です。
As this specification is based upon the SET specification and the associated delivery specifications, the following privacy considerations are also applicable to this specification:
この仕様は SET 仕様および関連する配信仕様に基づいているため、次のプライバシーに関する考慮事項もこの仕様に適用されます。
* Section 6 of [RFC8417] (Security Event Token)
* [RFC8417] のセクション 6 (セキュリティ イベント トークン)
* Section 6 of [RFC8935] (Push-Based SET Delivery Using HTTP)
* [RFC8935] のセクション 6 (HTTP を使用したプッシュベースの SET 配信)
* Section 5 of [RFC8936] (Poll-Based SET Delivery Using HTTP)
* [RFC8936] のセクション 5 (HTTP を使用したポーリングベースの SET 配信)
This specification enables the sharing of information between domains; therefore, it is assumed that implementers and deployers are operating under one of the following scenarios:
この仕様により、ドメイン間での情報の共有が可能になります。したがって、実装者と展開者は次のいずれかのシナリオで動作していると想定されます。
* A common administrative domain where there is one administrative owner of the data. In these cases, the goal is to protect privacy and security of the owner and user data by keeping information systems coordinated and up to date. For example, the domains decide to use DBR mode to keep employee information synchronized.
* データの管理所有者が 1 人いる共通の管理ドメイン。このような場合、目標は、情報システムを調整して最新の状態に保つことで、所有者とユーザーのデータのプライバシーとセキュリティを保護することです。たとえば、ドメインは従業員情報の同期を維持するために DBR モードを使用することを決定します。
* In a cooperative or coordinated relationship, parties have decided to share a limited amount of data and/or signals for the benefits of their users. Depending on end-user consent, information is shared on an as-authorized and/or as-needed basis. For example, the domains agree to use CP mode that exchanges things such as account status or specific minimal attribute information that must be fetched on request after receiving notice of a change. This enables authorization to be verified each time data is transferred.
* 協力または調整された関係では、当事者は、ユーザーの利益のために、限られた量のデータおよび/または信号を共有することを決定しました。エンドユーザーの同意に応じて、情報は承認された場合および/または必要に応じて共有されます。たとえば、ドメインは、変更通知の受信後に要求に応じて取得する必要があるアカウント ステータスや特定の最小限の属性情報などを交換する CP モードを使用することに同意します。これにより、データが転送されるたびに認証を検証できます。
In general, the sharing of SCIM Event information falls within a pre-existing SCIM client and service provider relationship and carries no additional personal information.
一般に、SCIM イベント情報の共有は、既存の SCIM クライアントとサービス プロバイダーの関係の範囲内で行われ、追加の個人情報は含まれません。
This specification registers the HTTP "Set-Txn" field name in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in Section 16.3.1 of [RFC9110].
この仕様は、[RFC9110] のセクション 16.3.1 で定義されている「ハイパーテキスト転送プロトコル (HTTP) フィールド名レジストリ」に HTTP の「Set-Txn」フィールド名を登録します。
Field name:
フィールド名:
Set-Txn
セット送信
Status:
状態：
permanent
永続
Reference:
参照：
Section 3 of RFC 9967.
RFC 9967 のセクション 3。
A reference to Section 4 of this document has been added to the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" entry in the "SCIM Server-Related Schema URIs" registry (Section 10.4 of [RFC7643]) under the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group.
このドキュメントのセクション 4 への参照が、「System for Cross-domain Identity Management (SCIM) Schema URIs」レジストリ グループの下にある「SCIM Server- Associated Schema URIs」レジストリ ([RFC7643] のセクション 10.4) の「urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig」エントリに追加されました。
IANA has created a new registry called "SCIM Event URIs" under the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group (Section 10.1 of [RFC7643]) at <https://www.iana.org/assignments/scim>.
IANA は、<https://www.iana.org/assignments/scim> にある「System for Cross-domain Identity Management (SCIM) Schema URIs」レジストリ グループ ([RFC7643] のセクション 10.1) の下に「SCIM Event URIs」と呼ばれる新しいレジストリを作成しました。
The registration procedure is Expert Review [RFC8126]. New registrations for this registry are evaluated by designated expert(s) for relevance to SCIM-based systems and to avoid possible duplication or conflict with other event definitions that may lie outside SCIM (e.g., Shared Signals [SSF]).
登録手順はエキスパートレビュー[RFC8126]です。このレジストリへの新規登録は、指定された専門家によって SCIM ベースのシステムとの関連性が評価され、SCIM の外部に存在する可能性のある他のイベント定義 (共有シグナル [SSF] など) との重複や競合の可能性が回避されます。
Namespace ID:
ネームスペースID:
The sub-namespace ID of "event" is assigned within the "scim" namespace.
「event」のサブ名前空間 ID は、「scim」名前空間内で割り当てられます。
Syntactic Structure:
構文構造:
The Namespace Specific String (NSS) of all URNs that use the "event" Namespace ID has the following structure:
「event」名前空間 ID を使用するすべての URN の名前空間固有文字列 (NSS) は、次の構造になっています。
"urn:ietf:params:scim:event:{class}:{name}:{other}"
The keywords have the following meaning:
キーワードには次の意味があります。
class
クラス
The class of events, which is one of: "feed", "prov", or "misc".
イベントのクラス。「feed」、「prov」、または「misc」のいずれかです。
name
名前
An ASCII string that conforms to URN syntax requirements (see [RFC8141]) and defines a descriptive event name (e.g., "create").
URN 構文要件 ([RFC8141] を参照) に準拠し、説明的なイベント名 (例: 「create」) を定義する ASCII 文字列。
other
他の
An optional ASCII string that conforms to URN syntax requirements (see [RFC8141]) and serves as an additional sub-category or qualifier, for example, "full" and "notice".
URN 構文要件 ([RFC8141] を参照) に準拠し、追加のサブカテゴリまたは修飾子として機能するオプションの ASCII 文字列 (たとえば、「full」や「notice」)。
Identifier Uniqueness Considerations:
識別子の一意性に関する考慮事項:
The designated contact is responsible for reviewing and enforcing uniqueness.
指定された連絡先は、一意性を確認して適用する責任があります。
Identifier Persistence Considerations:
識別子の永続性に関する考慮事項:
Once a name has been allocated, it MUST NOT be reallocated for a different purpose. The rules provided for the assignment of values within a sub-namespace MUST be constructed so that the meaning of values cannot change. This registration mechanism is not appropriate for naming values whose meaning may change over time.
一度割り当てられた名前は、別の目的のために再割り当てしてはなりません。サブ名前空間内での値の割り当てに提供されるルールは、値の意味が変更できないように構築されなければなりません (MUST)。この登録メカニズムは、時間の経過とともに意味が変わる可能性のある値に名前を付けるのには適していません。
Registration Format:
登録フォーマット:
An event registration MUST include the following fields:
イベント登録には次のフィールドを含める必要があります。
* Event URI
* イベントURI
* Descriptive name
* わかりやすい名前
* Reference to event definition
* イベント定義への参照
IANA has added the following initial entries to the "SCIM Event URIs" registry:
IANA は、次の初期エントリを「SCIM イベント URI」レジストリに追加しました。
+==========================================+==============+=========+
|Event URI |Name |Reference|
+==========================================+==============+=========+
|urn:ietf:params:scim:event:feed:add |Resource |Section |
| |added to Feed |2.3.1 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:feed:remove |Remove |Section |
| |resource from |2.3.2 of |
| |Feed Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource |Section |
|notice |Event (notice |2.4.1 of |
| |only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:create: |New Resource |Section |
|full |Event (full |2.4.1 of |
| |data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|notice |Patch Event |2.4.2 of |
| |(notice only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:patch: |Resource |Section |
|full |Patch Event |2.4.2 of |
| |(full data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:put: |Resource Put |Section |
|notice |Event (notice |2.4.3 of |
| |only) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:put:full |Resource Put |Section |
| |Event (full |2.4.3 of |
| |data) |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:delete |Resource |Section |
| |Deleted Event |2.4.4 of |
| | |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:activate |Resource |Section |
| |Activated |2.4.5 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:prov:deactivate|Resource |Section |
| |Deactivated |2.4.6 of |
| |Event |RFC 9967 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:scim:event:misc:asyncresp |Asynchronous |Section |
| |Request |2.5.1 of |
| |Completion |RFC 9967 |
+------------------------------------------+--------------+---------+
Table 1
[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>.
[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>.
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
DOI 10.17487/RFC7240, June 2014,
<https://www.rfc-editor.org/info/rfc7240>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
[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>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/info/rfc8417>.
[RFC8935] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari,
M., and A. Nadalin, "Push-Based Security Event Token (SET)
Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935,
November 2020, <https://www.rfc-editor.org/info/rfc8935>.
[RFC8936] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari,
M., and A. Nadalin, "Poll-Based Security Event Token (SET)
Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936,
November 2020, <https://www.rfc-editor.org/info/rfc8936>.
[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>.
[RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens", RFC 9493,
DOI 10.17487/RFC9493, December 2023,
<https://www.rfc-editor.org/info/rfc9493>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[SCIM-EVENT-EXT]
Hunt, P., Ed., Denniss, W., and M. Ansari, "SCIM Event
Extension", Work in Progress, Internet-Draft, draft-hunt-
idevent-scim-00, 20 March 2016,
<https://datatracker.ietf.org/doc/html/draft-hunt-idevent-
scim-00>.
[SSF] Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman,
A., Bradley, J., and S. Miel, "OpenID Shared Signals
Framework Specification 1.0", 29 August 2025,
<https://openid.net/specs/openid-sharedsignals-framework-
1_0.html>.
SCIM Events may be used in a number of ways. The following non-normative sections describe some of the expected uses.
SCIM イベントはさまざまな方法で使用できます。以下の非規範的なセクションでは、予想される用途のいくつかについて説明します。
The objective of DBR events is to synchronize resource changes between SCIM service providers in a common administrative domain. In this mode, complete information about modified resources are shared between replicas for immediate processing.
DBR イベントの目的は、共通の管理ドメイン内の SCIM サービス プロバイダー間でリソースの変更を同期することです。このモードでは、変更されたリソースに関する完全な情報がレプリカ間で共有され、即時に処理されます。
+-------------+ +---------------------+ +------------------------+
|SCIM Client A| |SCIM Service Provider| |Service Provider Replica|
+-------------+ +---------------------+ +------------------------+
| | |
| [1] SCIM Operation | |
|-------------------->| |
| [2] SCIM Response | |
|<--------------------| |
| | |
| | [3] Event SCIM:prov:<op> |
| | id:xyz |
| |- - - - - - - - - - - - - >|
| | |
| | [4] Update local node |--+
| | | |
| | |<-+
| | |
v v v
Figure 20: Domain-Based Replication Sequence
図 20: ドメインベースのレプリケーション シーケンス
From a security perspective, it is assumed that servers sharing DBR events are secured by a common access policy and all servers are required to be up to date. From a privacy perspective, because all servers are in the same administrative domain, the primary objective is to keep individual service provider nodes or clusters synchronized.
セキュリティの観点からは、DBR イベントを共有するサーバーは共通のアクセス ポリシーによって保護されており、すべてのサーバーが最新である必要があると想定されています。プライバシーの観点から見ると、すべてのサーバーが同じ管理ドメイン内にあるため、主な目的は、個々のサービス プロバイダーのノードまたはクラスターの同期を維持することです。
In CP, SCIM resource change events perform the function of change notification without the need to provide raw data. In any Event Publisher and Receiver relationship, the set of SCIM resources (e.g., Users) that are linked or coordinated is managed within the context of an event feed and may be a subset of the total set of resources on either side. For example, an event feed could be limited to users who have consented to the sharing of information between domains. To support capability, "feed" specific events are defined to indicate the addition and removal of SCIM resources from a feed. For example, when a user consents to the sharing of information between domains, events about the User may be added to the feed between the Event Publisher and Receiver.
CP では、SCIM リソース変更イベントは、生データを提供することなく、変更通知の機能を実行します。イベント発行者と受信者の関係では、リンクまたは調整される SCIM リソースのセット (ユーザーなど) はイベント フィードのコンテキスト内で管理され、どちらかの側のリソースの合計セットのサブセットである可能性があります。たとえば、イベント フィードは、ドメイン間での情報の共有に同意したユーザーに限定できます。機能をサポートするために、フィードへの SCIM リソースの追加と削除を示す「フィード」固有のイベントが定義されています。たとえば、ユーザーがドメイン間での情報の共有に同意すると、そのユーザーに関するイベントがイベント発行者と受信者間のフィードに追加される場合があります。
+-----------+ +---------------+ +-----------------+ +---------------+
|SCIM Client| | SCIM Service | | Event Receiver | | Coord. Action |
| | | Provider | | | | Endpoint |
+-----------+ +---------------+ +-----------------+ +---------------+
| | | |
| [1] SCIM | | |
| Operation | | |
|--------------->| | |
| | | |
| [2] SCIM | | |
| Response | | |
|<---------------| | |
| | | |
| +=== loop ==========+===================+
| | | |
| | [3] Event | |
| | SCIM:prov:<op> | |
| | id:xyz | |
| |- - - - - - - - - >| |
| | | |
| | | Note: Receiver |
| | | may accumulate |
| | | events for |
| | | periodic action. |
| | | |
| | [4] SCIM GET <id> | |
| |<------------------| |
| | | |
| | [5] Filtered | |
| | Resource | |
| | Response | |
| |------------------>| |
| | | |
| | | [6] Coordinated |
| | | Action |
| | |------------------>|
| | | |
| +=== end loop ======+===================+
v v v v
Figure 21: Coordinated Provisioning Sequence
図 21: 調整されたプロビジョニングのシーケンス
In CP mode, the receiver of an event must call back to the originating SCIM service provider (e.g., using a SCIM GET request) to reconcile the newly changed resource in order to obtain the changes.
CP モードでは、イベントの受信者は、変更を取得するために、発信元の SCIM サービス プロバイダー (SCIM GET リクエストなどを使用して) にコールバックして、新しく変更されたリソースを調整する必要があります。
CP has the following benefits:
CPには以下のようなメリットがあります。
* Differences in schema (e.g., attributes) between domains. For example, a receiving domain may only be interested in or allowed to access to a few attributes (e.g., role-based access data) to enable access to an application.
* ドメイン間のスキーマ (属性など) の違い。たとえば、受信側ドメインは、アプリケーションへのアクセスを可能にするために、いくつかの属性 (たとえば、役割ベースのアクセス データ) にのみ関心があるか、アクセスが許可されている場合があります。
* Different Event Receivers may have differing needs when accessing information and thus may be assigned varying access rights. Minimal information events combined with callbacks for data allows data filtering to be applied.
* イベント レシーバーが異なれば、情報にアクセスする際のニーズも異なる場合があるため、さまざまなアクセス権が割り当てられる場合があります。最小限の情報イベントとデータのコールバックを組み合わせることで、データ フィルタリングを適用できます。
* Receivers can take independent action such as deciding which attributes or resource life cycle changes to accept. For example, in the case of a conflict, a receiver can prioritize one domain source over another.
* 受信者は、どの属性またはリソースのライフサイクル変更を受け入れるかを決定するなど、独立したアクションを実行できます。たとえば、競合が発生した場合、受信者は 1 つのドメイン ソースを別のドメイン ソースよりも優先できます。
* A receiver may throttle or buffer changes rather than act immediately on a notification. For example, for a frequently changing resource, the receiver may choose to make a scheduled SCIM GET for resources that have been marked "dirty" by events received in the last scheduled cycle.
* 受信者は、通知に基づいてすぐに動作するのではなく、変更を抑制したりバッファリングしたりする場合があります。たとえば、頻繁に変更されるリソースの場合、受信側は、最後にスケジュールされたサイクルで受信したイベントによって「ダーティ」とマークされたリソースに対して、スケジュールされた SCIM GET を実行することを選択する場合があります。
A disadvantage of the CP approach is that it may be considered costly in the sense that each event received might trigger a callback to the event issuer. This cost should be weighed against the cost producing filtered information in each event for each receiver. Furthermore, a receiver is not required to make a callback on every provisioning event.
CP アプローチの欠点は、受信した各イベントがイベント発行者へのコールバックをトリガーする可能性があるという意味でコストがかかると考えられることです。このコストは、各受信機の各イベントでフィルタリングされた情報を生成するコストと比較検討する必要があります。さらに、受信者はプロビジョニング イベントごとにコールバックを行う必要はありません。
It is assumed that an underlying relationship between domains exists that permits the exchange of personal information and credentials. For example, in a cross-domain scenario, a SCIM service provider would have been previously authorized to perform SCIM provisioning operations and publish change events. As such, appropriate confidentiality and privacy agreements should be in place between the domains.
ドメイン間には、個人情報と資格情報の交換を許可する基礎的な関係が存在すると想定されます。たとえば、クロスドメインのシナリオでは、SCIM サービス プロバイダーは、SCIM プロビジョニング操作を実行し、変更イベントを公開する権限を事前に付与されていると考えられます。したがって、ドメイン間で適切な機密保持およびプライバシーに関する協定を締結する必要があります。
When sharing information between parties, CP Events minimize the information shared in each message and require the Security Event Receiver to receive more information from the Event Publisher as needed. In this way, the Event Receiver is able to have regular access to information through normal SCIM protocol access restrictions. The Event Receiver and Publisher may agree to communicate these updates through a variety of transmission methods such as push- and pull-based HTTP [RFC8935] [RFC8936] or HTTP GET (see Section 2.5.1.1); streaming technologies (e.g., Kafka or Kinesis); or webhooks such as in the Shared Signals Framework [SSF].
関係者間で情報を共有する場合、CP イベントは各メッセージで共有される情報を最小限に抑え、必要に応じてセキュリティ イベント レシーバーがイベント パブリッシャーからより多くの情報を受信することを要求します。このようにして、イベント レシーバーは、通常の SCIM プロトコル アクセス制限を通じて情報に定期的にアクセスできるようになります。イベント受信者と発行者は、プッシュおよびプルベースの HTTP [RFC8935] [RFC8936] または HTTP GET (セクション 2.5.1.1 を参照) などのさまざまな送信方法を通じてこれらの更新を伝達することに同意する場合があります。ストリーミングテクノロジー (Kafka や Kinesis など)。または Shared Signals Framework [SSF] などの Webhook。
The authors would like to thank the following contributors:
著者らは以下の貢献者に感謝の意を表します。
* Morteza Ansari and William Denniss, who contributed significantly to [SCIM-EVENT-EXT] upon which this document is based.
* Morteza Ansari と William Denniss は、この文書の基礎となっている [SCIM-EVENT-EXT] に多大な貢献をしました。
* The participants of the SCIM Working Group and the IETF id-event mailing list for their support of this specification.
* この仕様をサポートする SCIM ワーキング グループおよび IETF id-event メーリング リストの参加者。
* Deb Cooley, Dean Saxe, Elliot Lear, Pamela Dingle, Mark Nottingham, R Gideon, Paulo Jorge Correia, Shuping Peng, Elwyn Davies, Luigi Lannone, Mohamed Boucadair, Roman Danyliw, Ketan Talaulikar, Mahesh Jethanandani, and Mike Bishop for their write-ups and reviews.
* Deb Cooley、Dean Saxe、Elliot Lear、Pamela Dingle、Mark Nottingham、R Gideon、Paulo Jorge Correia、Shuping Peng、Elwyn Davies、Luigi Lannone、Mohamed Boucadair、Roman Danyliw、Ketan Talaulikar、Mahesh Jethanandani、Mike Bishop の執筆とレビューにご協力ください。
Phil Hunt (editor)
Independent Identity Inc
Email: phil.hunt@independentid.com
Nancy Cam-Winget
Cisco Systems
Email: ncamwing@cisco.com
Mike Kiser
Sailpoint Technologies
Email: mike.kiser@sailpoint.com
Jen Schreiber
Workday, Inc.
Email: jwschreib@gmail.com