[要約] RFC 7644は、異なるドメイン間でのアイデンティティ管理を行うためのプロトコルです。その目的は、異なるシステム間でのアイデンティティ情報の共有と管理を効率的かつ安全に行うことです。
Internet Engineering Task Force (IETF) P. Hunt, Ed.
Request for Comments: 7644 Oracle
Category: Standards Track K. Grizzle
ISSN: 2070-1721 SailPoint
M. Ansari
Cisco
E. Wahlstroem
Nexus Technology
C. Mortimore
Salesforce
September 2015
System for Cross-domain Identity Management: Protocol
クロスドメインID管理のシステム：プロトコル
Abstract
概要
The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.
System for Cross-domain Identity Management（SCIM）仕様は、HTTPベースのプロトコルであり、標準化されたサービスを介してマルチドメインシナリオでのID管理をサポートしやすくします。例には、エンタープライズからクラウドへのサービスプロバイダーやクラウド間のシナリオが含まれますが、これらに限定されません。仕様スイートは、既存のスキーマとデプロイメントでの経験に基づいて構築し、開発と統合のシンプルさを特に重視しながら、既存の認証、承認、プライバシーモデルを適用しようとしています。 SCIMの目的は、このドキュメントで定義されている共通のユーザースキーマ、拡張モデル、およびサービスプロトコルを提供することにより、ユーザー管理操作のコストと複雑さを軽減することです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7644.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7644で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Overview .......................................3
1.1. Intended Audience ..........................................3
1.2. Notational Conventions .....................................4
1.3. Definitions ................................................4
2. Authentication and Authorization ................................5
2.1. Use of Tokens as Authorizations ............................7
2.2. Anonymous Requests .........................................7
3. SCIM Protocol ...................................................8
3.1. Background .................................................8
3.2. SCIM Endpoints and HTTP Methods ............................9
3.3. Creating Resources ........................................11
3.3.1. Resource Types .....................................13
3.4. Retrieving Resources ......................................13
3.4.1. Retrieving a Known Resource ........................14
3.4.2. Query Resources ....................................15
3.4.3. Querying Resources Using HTTP POST .................27
3.5. Modifying Resources .......................................29
3.5.1. Replacing with PUT .................................30
3.5.2. Modifying with PATCH ...............................32
3.6. Deleting Resources ........................................48
3.7. Bulk Operations ...........................................49
3.7.1. Circular Reference Processing ......................51
3.7.2. "bulkId" Temporary Identifiers .....................53
3.7.3. Response and Error Handling ........................58
3.7.4. Maximum Operations .................................63
3.8. Data Input/Output Formats .................................64
3.9. Additional Operation Response Parameters ..................64
3.10. Attribute Notation .......................................66
3.11. "/Me" Authenticated Subject Alias ........................66
3.12. HTTP Status and Error Response Handling ..................67
3.13. SCIM Protocol Versioning .................................71
3.14. Versioning Resources .....................................71
4. Service Provider Configuration Endpoints .......................73
5. Preparation and Comparison of Internationalized Strings ........76
6. Multi-Tenancy ..................................................76
6.1. Associating Clients to Tenants ............................77
6.2. SCIM Identifiers with Multiple Tenants ....................78
7. Security Considerations ........................................78
7.1. HTTP Considerations .......................................78
7.2. TLS Support Considerations ................................78
7.3. Authorization Token Considerations ........................78
7.4. Bearer Token and Cookie Considerations ....................79
7.5. Privacy Considerations ....................................79
7.5.1. Personal Information ...............................79
7.5.2. Disclosure of Sensitive Information in URIs ........80
7.6. Anonymous Requests ........................................80
7.7. Secure Storage and Handling of Sensitive Data .............81
7.8. Case-Insensitive Comparison and International Languages ...82
8. IANA Considerations ............................................82
8.1. Media Type Registration ...................................82
8.2. Registering URIs for SCIM Messages ........................84
9. References .....................................................85
9.1. Normative References ......................................85
9.2. Informative References ....................................87
Acknowledgements ..................................................88
Contributors ......................................................88
Authors' Addresses ................................................89
The SCIM protocol is an application-level HTTP-based protocol for provisioning and managing identity data on the web and in cross-domain environments such as enterprise-to-cloud service providers or inter-cloud scenarios. The protocol supports creation, modification, retrieval, and discovery of core identity resources such as Users and Groups, as well as custom resources and resource extensions.
SCIMプロトコルは、Web上のエンタープライズデータからクラウドサービスプロバイダーやクラウド間シナリオなどのクロスドメイン環境でIDデータをプロビジョニングおよび管理するためのアプリケーションレベルのHTTPベースのプロトコルです。このプロトコルは、ユーザーやグループなどのコアIDリソースの作成、変更、取得、および検出と、カスタムリソースおよびリソース拡張をサポートします。
The definition of resources, attributes, and overall schema are defined in the SCIM Core Schema document [RFC7643].
リソース、属性、および全体的なスキーマの定義は、SCIMコアスキーマドキュメント[RFC7643]で定義されています。
This document is intended to serve as a guide to SCIM protocol usage for both SCIM HTTP service providers and HTTP clients who may provision information to service providers or retrieve information from them.
このドキュメントは、SCIM HTTPサービスプロバイダーと、サービスプロバイダーに情報をプロビジョニングしたり、それらから情報を取得したりするHTTPクライアントの両方に対するSCIMプロトコルの使用法のガイドとして機能することを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These key words are capitalized when used to unambiguously specify requirements of the protocol or application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。これらのキーワードは、実装の相互運用性とセキュリティに影響を与えるプロトコルまたはアプリケーションの機能と動作の要件を明確に指定するために使用される場合、大文字になります。これらの単語が大文字ではない場合、それらは自然言語の意味で意味されます。
For purposes of readability, examples are not URL encoded. Implementers MUST percent-encode URLs as described in Section 2.1 of [RFC3986].
読みやすくするために、例はURLエンコードされていません。 [RFC3986]のセクション2.1で説明されているように、実装者はURLをパーセントエンコードする必要があります。
Throughout this document, figures may contain spaces and extra line wrapping to improve readability and accommodate space limitations. Similarly, some URIs contained within examples have been shortened for space and readability reasons (as indicated by "...").
このドキュメント全体で、図にはスペースと余分な行の折り返しが含まれ、読みやすさを向上させ、スペースの制限に対応しています。同様に、例に含まれる一部のURIは、スペースと読みやすさの理由で短縮されています（「...」で示されています）。
This specification uses the definitions from [RFC7643] and defines the following additional term:
この仕様では、[RFC7643]の定義を使用し、次の追加の用語を定義しています。
Base URI The SCIM HTTP protocol is described in terms of a path relative to a Base URI. The Base URI MUST NOT contain a query string, as clients MAY append additional path information and query parameters as part of forming the request. The base URI is a URL that most often consists of the "https" protocol scheme, a domain name, and some initial path [RFC3986]. For example:
ベースURI SCIM HTTPプロトコルは、ベースURIからの相対パスで記述されます。クライアントはリクエストの形成の一部として追加のパス情報とクエリパラメータを追加する可能性があるため、ベースURIにはクエリ文字列を含めてはなりません（MUST NOT）。ベースURIは、ほとんどの場合「https」プロトコルスキーム、ドメイン名、およびいくつかの初期パス[RFC3986]で構成されるURLです。例えば：
"https://example.com/scim/"
For readability, all examples in this document assume that the SCIM service root and the server root are the same (no path prefix). It is expected that SCIM servers may be deployed using any URI path prefix. For example, a SCIM server might have a prefix of "https://example.com/" or "https://example.com/scim/tenancypath/". Additionally, a client MAY apply a version number to the server root prefix (see Section 3.13).
読みやすくするために、このドキュメントのすべての例では、SCIMサービスルートとサーバールートが同じ（パスプレフィックスなし）であると想定しています。 SCIMサーバーは、任意のURIパスプレフィックスを使用して展開できることが予想されます。たとえば、SCIMサーバーには「https://example.com/」または「https://example.com/scim/tenancypath/」のプレフィックスが付いている場合があります。さらに、クライアントはバージョン番号をサーバーのルートプレフィックスに適用してもよい（セクション3.13を参照）。
The SCIM protocol is based upon HTTP and does not itself define a SCIM-specific scheme for authentication and authorization. SCIM depends on the use of Transport Layer Security (TLS) and/or standard HTTP authentication and authorization schemes as per [RFC7235]. For example, the following methodologies could be used, among others:
SCIMプロトコルはHTTPに基づいており、認証と承認のためのSCIM固有のスキームを定義していません。 SCIMは、[RFC7235]のように、トランスポート層セキュリティ（TLS）や標準のHTTP認証および承認スキームの使用に依存しています。たとえば、特に次の方法を使用できます。
TLS Client Authentication The SCIM service provider MAY request TLS client authentication (also known as mutual authentication). See Section 7.3 of [RFC5246].
TLSクライアント認証SCIMサービスプロバイダーは、TLSクライアント認証（相互認証とも呼ばれます）を要求できます（MAY）。 [RFC5246]のセクション7.3をご覧ください。
HOBA Authentication HTTP Origin-Bound Authentication (HOBA) is a variation on TLS client authentication and uses a digital-signature-based design for an HTTP authentication method (see [RFC7486]). The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.
HOBA認証HTTP Origin-Bound Authentication（HOBA）はTLSクライアント認証のバリエーションであり、HTTP認証方式にデジタル署名ベースの設計を使用します（[RFC7486]を参照）。このデザインは、HTMLに埋め込まれたJavaScriptベースの認証でも使用できます。 HOBAは、パスワードを必要とするHTTP認証スキームの代替手段であり、サーバー側のパスワードデータベースの漏洩など、パスワードに関連するすべての問題を回避します。
Bearer Tokens Bearer tokens [RFC6750] MAY be used when combined with TLS and a token framework such as OAuth 2.0 [RFC6749]. Tokens that are issued based on weak or no authentication of authorizing users and/or OAuth clients SHOULD NOT be used, unless, for example, they are being used as single-use tokens to permit one-time requests such as anonymous registration (see Section 3.3). For security considerations regarding the use of bearer tokens in SCIM, see Section 7.4. While bearer tokens most often represent an authorization, it is assumed that the authorization was based upon a successful authentication of the SCIM client. Accordingly, the SCIM service provider must have a method for validating, parsing, and/or "introspecting" the bearer token for the relevant authentication and authorization information. The method for this is assumed to be defined by the token-issuing system and is beyond the scope of this specification.
ベアラートークンベアラートークン[RFC6750]は、TLSおよびOAuth 2.0 [RFC6749]などのトークンフレームワークと組み合わせる場合に使用できます。承認ユーザーやOAuthクライアントの認証が弱いかまったくないことに基づいて発行されたトークンは、匿名登録などの1回限りのリクエストを許可するための使い捨てトークンとして使用されている場合を除き、使用しないでください（セクションを参照）。 3.3）。 SCIMでのベアラートークンの使用に関するセキュリティの考慮事項については、セクション7.4を参照してください。ベアラートークンはほとんどの場合承認を表しますが、承認はSCIMクライアントの認証の成功に基づいていると想定されています。したがって、SCIMサービスプロバイダーは、関連する認証および承認情報のベアラートークンを検証、解析、および/または「イントロスペクト」するための方法を備えている必要があります。この方法は、トークン発行システムによって定義されていると想定されており、この仕様の範囲を超えています。
PoP Tokens A proof-of-possession (PoP) token demonstrates that the presenter of the token possesses a particular key and that the recipient can cryptographically confirm proof of possession of the key by the presenter. This property is sometimes also described as the presenter being a holder of the key. See [OAuth-PoP-Arch] for an example of such a token and its use.
PoPトークン所有証明（PoP）トークンは、トークンのプレゼンターが特定のキーを所有し、受信者がプレゼンターによるキーの所有の証拠を暗号で確認できることを示します。このプロパティは、プレゼンターがキーの保持者であると説明されることもあります。そのようなトークンとその使用の例については、[OAuth-PoP-Arch]を参照してください。
Cookies JavaScript clients MAY assert HTTP cookies over TLS that contain an authentication state that is understood by the SCIM service provider (see [RFC6265]). An example of this is scenarios where web-form authentication has taken place with the user and HTTP cookies were set representing the authentication state. For the purposes of SCIM, the security considerations in Section 7.4 apply.
Cookies JavaScriptクライアントは、SCIMサービスプロバイダーが理解する認証状態を含むTLS経由のHTTP Cookieをアサートできます（[RFC6265]を参照）。この例は、ユーザーでWebフォーム認証が行われ、認証状態を表すHTTP Cookieが設定されたシナリオです。 SCIMの目的のために、セクション7.4のセキュリティに関する考慮事項が適用されます。
Basic Authentication Usage of basic authentication should be avoided, due to its use of a single factor that is based upon a relatively static, symmetric secret. Implementers SHOULD combine the use of basic authentication with other factors. The security considerations of HTTP Basic are well documented in [HTTP-BASIC-AUTH]; therefore, implementers are encouraged to use stronger authentication methods. Designating the specific methods of authentication and authorization is out of scope for SCIM; however, this information is provided as a resource to implementers.
基本認証基本認証の使用は、比較的静的で対称的な秘密に基づく単一の要素を使用するため、避ける必要があります。実装者は、基本認証の使用を他の要素と組み合わせる必要があります（SHOULD）。 HTTP Basicのセキュリティに関する考慮事項は、[HTTP-BASIC-AUTH]で詳細に文書化されています。したがって、実装者はより強力な認証方法を使用することをお勧めします。認証と承認の特定の方法を指定することは、SCIMの範囲外です。ただし、この情報はリソースとして実装者に提供されます。
As per Section 4.1 of [RFC7235], a SCIM service provider SHALL indicate supported HTTP authentication schemes via the "WWW-Authenticate" header.
[RFC7235]のセクション4.1に従って、SCIMサービスプロバイダーは、「WWW-Authenticate」ヘッダーを介して、サポートされているHTTP認証スキームを示す必要があります（SHALL）。
Regardless of methodology, the SCIM service provider MUST be able to map the authenticated client to an access control policy in order to determine the client's authorization to retrieve and update SCIM resources. For example, while a browser session may have been established via HTTP cookie or TLS client authentication, the unique client MUST be mapped to a security subject (e.g., User). The authorization model and the process by which this is done are beyond the scope of this specification.
方法論に関係なく、SCIMサービスプロバイダーは、SCIMリソースを取得および更新するクライアントの承認を決定するために、認証されたクライアントをアクセス制御ポリシーにマップできる必要があります。たとえば、ブラウザセッションはHTTP CookieまたはTLSクライアント認証を介して確立されている可能性がありますが、一意のクライアントはセキュリティサブジェクト（ユーザーなど）にマップする必要があります。認可モデルとこれを行うプロセスは、この仕様の範囲を超えています。
When processing requests, the service provider SHOULD consider the subject performing the request and whether or not the action is appropriate given the subject and the resource affected by the request. The subject performing the request is usually determined directly or indirectly from the "Authorization" header present in the request. For example, a subject MAY be permitted to retrieve and update their own "User" resource but will normally have restricted ability to access resources associated with other Users. In other cases, the SCIM service provider might only grant access to a subject's own associated "User" resource (e.g., for the purpose of updating personal contact attributes).
リクエストを処理するとき、サービスプロバイダーは、リクエストを実行するサブジェクトと、サブジェクトとリクエストの影響を受けるリソースを考慮してアクションが適切かどうかを検討する必要があります（SHOULD）。リクエストを実行するサブジェクトは通常、リクエストに含まれる「Authorization」ヘッダーから直接的または間接的に決定されます。たとえば、サブジェクトは自分の「ユーザー」リソースを取得および更新することを許可される場合がありますが、通常、他のユーザーに関連付けられたリソースへのアクセスは制限されています。他の場合では、SCIMサービスプロバイダーは、サブジェクト自身に関連付けられた「ユーザー」リソースへのアクセスのみを許可する場合があります（たとえば、個人の連絡先属性を更新する目的で）。
For illustrative purposes only, SCIM protocol examples show an OAuth 2.0 bearer token value [RFC6750] in the authorization header, e.g.,
例示のみを目的として、SCIMプロトコルの例では、認証ヘッダーにOAuth 2.0ベアラートークン値[RFC6750]が示されています。
GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8
This is not intended to imply that bearer tokens are preferred. However, the use of bearer tokens in the specification does reflect common implementation practice.
これは、無記名トークンが好ましいことを意味するものではありません。ただし、仕様での無記名トークンの使用は、一般的な実装方法を反映しています。
When using bearer tokens or PoP tokens that represent an authorization grant, such as a grant issued by OAuth (see [RFC6749]), implementers SHOULD consider the type of authorization granted, any authorized scopes (see Section 3.3 of [RFC6749]), and the security subject(s) that SHOULD be mapped from the authorization when considering local access control rules. Section 6 of [RFC7521] documents common scenarios for authorization, including:
OAuthによって発行された許可などの許可付与を表すベアラートークンまたはPoPトークンを使用する場合（[RFC6749]を参照）、実装者は許可された許可のタイプ、許可されたスコープ（[RFC6749]のセクション3.3を参照）を考慮する必要があります。ローカルアクセスコントロールルールを検討するときに、承認からマップする必要があるセキュリティサブジェクト。 [RFC7521]のセクション6には、次のような承認の一般的なシナリオが記載されています。
o A client using an assertion to authenticate and/or act on behalf of itself,
o アサーションを使用して、認証またはクライアント自身のために行動するクライアント、
o A client acting on behalf of a user, and
o ユーザーに代わって行動するクライアント、および
o A client acting on behalf of an anonymous user (for example, see Section 2.2).
o 匿名ユーザーに代わって動作するクライアント（たとえば、セクション2.2を参照）。
When using OAuth authorization tokens, implementers MUST take into account the threats and countermeasures related to the use of client authorizations, as documented in Section 8 of [RFC7521]. When using other token formats or frameworks, implementers MUST take into account similar threats and countermeasures, especially those documented by the relevant specifications.
[RFC7521]のセクション8に記載されているように、OAuth認証トークンを使用する場合、実装者はクライアント認証の使用に関連する脅威と対策を考慮する必要があります。他のトークン形式またはフレームワークを使用する場合、実装者は同様の脅威と対策、特に関連する仕様で文書化されているものを考慮する必要があります。
In some SCIM deployments, it MAY be acceptable to permit unauthenticated (anonymous) requests -- for example, a user self-registration request where the service provider chooses to accept a SCIM Create request (see Section 3.3) from an anonymous client. See Section 7.6 for security considerations regarding anonymous requests.
一部のSCIM展開では、認証されていない（匿名）要求を許可することが許容される場合があります-たとえば、サービスプロバイダーが匿名クライアントからのSCIM作成要求（セクション3.3を参照）を受け入れることを選択するユーザー自己登録要求。匿名リクエストに関するセキュリティの考慮事項については、セクション7.6を参照してください。
SCIM is a protocol that is based on HTTP [RFC7230]. Along with HTTP headers and URIs, SCIM uses JSON [RFC7159] payloads to convey SCIM resources, as well as protocol-specific payload messages that convey request parameters and response information such as errors. Both resources and messages are passed in the form of JSON-based structures in the message body of an HTTP request or response. To identify this content, SCIM uses a media type of "application/scim+json" (see Section 8.1).
SCIMは、HTTP [RFC7230]に基づくプロトコルです。 SCIMはHTTPヘッダーとURIに加えて、JSON [RFC7159]ペイロードを使用してSCIMリソースを送信するほか、リクエストパラメータやエラーなどの応答情報を送信するプロトコル固有のペイロードメッセージも送信します。リソースとメッセージの両方が、HTTP要求または応答のメッセージ本文でJSONベースの構造の形式で渡されます。このコンテンツを識別するために、SCIMは「application / scim + json」のメディアタイプを使用します（セクション8.1を参照）。
A SCIM "resource" is a JSON object [RFC7159] that may be created, maintained, and retrieved via HTTP request methods as described in this document. Each JSON resource representation contains a "schemas" attribute that contains a list of one or more URIs that indicate included SCIM schemas that are used to indicate the attributes contained within a resource. Specific information about what attributes are defined within a schema MAY be obtained by querying a SCIM service provider's "/Schemas" endpoint for a schema definition (see Section 8.7 of [RFC7643]). Responses from this endpoint describe the schema supported by a service provider, including attribute characteristics such as cardinality, case-exactness, mutability, uniqueness, returnability, and whether or not attributes are required. While SCIM schemas and an associated extension model are defined in [RFC7643], SCIM clients should expect that some attribute schema may change from service provider to service provider, particularly across administrative domains. In cases where SCIM may be used as an open protocol in front of an application service, it is quite reasonable to expect that some service providers may only support a subset of the schema defined in [RFC7643].
SCIMの「リソース」はJSONオブジェクト[RFC7159]であり、このドキュメントで説明されているように、HTTPリクエストメソッドを介して作成、維持、および取得できます。各JSONリソース表現には、リソース内に含まれる属性を示すために使用される、含まれるSCIMスキーマを示す1つ以上のURIのリストを含む「スキーマ」属性が含まれます。スキーマ内で定義されている属性に関する特定の情報は、スキーマ定義についてSCIMサービスプロバイダーの「/ Schemas」エンドポイントにクエリを実行することで取得できます（[RFC7643]のセクション8.7を参照）。このエンドポイントからの応答は、カーディナリティ、大文字と小文字の正確さ、可変性、一意性、戻り可能性などの属性特性、および属性が必要かどうかなど、サービスプロバイダーがサポートするスキーマを記述します。 SCIMスキーマおよび関連する拡張モデルは[RFC7643]で定義されていますが、SCIMクライアントは、一部の属性スキーマがサービスプロバイダー間で、特に管理ドメイン全体で変更される可能性があることを予期する必要があります。 SCIMがアプリケーションサービスの前でオープンプロトコルとして使用される場合、一部のサービスプロバイダーが[RFC7643]で定義されているスキーマのサブセットしかサポートしないことを期待するのはかなり合理的です。
A SCIM message conveys protocol parameters related to a SCIM request or response; this specification defines these parameters. As with a SCIM resource, a SCIM message is a JSON object [RFC7159] that contains a "schemas" attribute with a URI whose namespace prefix MUST begin with "urn:ietf:params:scim:api:". As SCIM protocol messages are fixed and defined by SCIM specifications and registered extensions, SCIM message schemas using the above prefix URN SHALL NOT be discoverable using the "/Schemas" endpoint.
SCIMメッセージは、SCIM要求または応答に関連するプロトコルパラメータを伝達します。この仕様はこれらのパラメーターを定義します。 SCIMリソースと同様に、SCIMメッセージはJSONオブジェクト[RFC7159]であり、名前空間の接頭辞が「urn：ietf：params：scim：api：」で始まる必要があるURIを持つ「スキーマ」属性が含まれています。 SCIMプロトコルメッセージはSCIM仕様および登録済み拡張機能によって修正および定義されるため、上記の接頭辞URNを使用するSCIMメッセージスキーマは、「/ Schemas」エンドポイントを使用して検出できません。
As SCIM is intended for use in cross-domain scenarios where schema and implementations may vary, techniques such as document validation (e.g., [XML-Schema]) are not recommended. A SCIM service provider interprets a request in the context of its own schema (which may be different from the client's schema) and following the defined processing rules for each request. The sections that follow define the processing rules for SCIM and provide allowances for schema differences where appropriate. For example, in a SCIM PUT request, "readOnly" attributes are ignored, while "readWrite" attributes are updated. There is no need for a SCIM client to discover which attributes are "readOnly", and the client does not need to remove them from a PUT request in order to be accepted. Similarly, a SCIM client SHOULD NOT expect a service provider to return SCIM resources with exactly the same schema and values as submitted. SCIM responses SHALL reflect resource state as interpreted by the SCIM service provider.
SCIMは、スキーマと実装が異なる可能性があるクロスドメインシナリオでの使用を目的としているため、ドキュメント検証（[XML-Schema]など）などの手法は推奨されません。 SCIMサービスプロバイダーは、独自のスキーマ（クライアントのスキーマとは異なる場合があります）のコンテキストで要求を解釈し、各要求に対して定義された処理ルールに従います。以下のセクションでは、SCIMの処理ルールを定義し、必要に応じてスキーマの違いを考慮します。たとえば、SCIM PUTリクエストでは、「readOnly」属性は無視されますが、「readWrite」属性は更新されます。 SCIMクライアントは、どの属性が「読み取り専用」であるかを検出する必要はありません。クライアントは、受け入れるためにPUT要求からそれらを削除する必要はありません。同様に、SCIMクライアントは、サービスプロバイダーが送信されたものとまったく同じスキーマと値を持つSCIMリソースを返すことを期待すべきではありません（SHOULD NOT）。 SCIM応答は、SCIMサービスプロバイダーによって解釈されるリソースの状態を反映するものとします（SHALL）。
The SCIM protocol specifies well-known endpoints and HTTP methods for managing resources defined in the SCIM Core Schema document ([RFC7643]); i.e., "User" and "Group" resources correspond to "/Users" and "/Groups", respectively. Service providers that support extended resources SHOULD define resource endpoints using the convention of pluralizing the resource name defined in the extended schema, by appending an 's'. Given that there are cases where resource pluralization is ambiguous, e.g., a resource named "Person" is legitimately "Persons" and "People", clients SHOULD discover resource endpoints via the "/ResourceTypes" endpoint.
SCIMプロトコルは、SCIMコアスキーマドキュメント（[RFC7643]）で定義されたリソースを管理するための既知のエンドポイントとHTTPメソッドを指定します。つまり、「ユーザー」リソースと「グループ」リソースは、それぞれ「/ユーザー」と「/グループ」に対応します。拡張リソースをサポートするサービスプロバイダーは、「s」を追加することにより、拡張スキーマで定義されたリソース名を複数形にする規則を使用して、リソースエンドポイントを定義する必要があります（SHOULD）。リソース「Person」という名前のリソースが合法的に「Persons」と「People」であるなど、リソースの複数化が曖昧な場合があるとすると、クライアントは「/ ResourceTypes」エンドポイントを介してリソースエンドポイントを検出する必要があります。
HTTP SCIM Usage
Method
------ --------------------------------------------------------------
GET Retrieves one or more complete or partial resources.
POST Depending on the endpoint, creates new resources, creates a search request, or MAY be used to bulk-modify resources.
POSTエンドポイントに応じて、新しいリソースを作成するか、検索リクエストを作成するか、リソースを一括変更するために使用できます。
PUT Modifies a resource by replacing existing attributes with a specified set of replacement attributes (replace). PUT MUST NOT be used to create new resources.
PUT既存の属性を指定された置換属性のセットで置き換えることにより、リソースを変更します（replace）。 PUTを使用して新しいリソースを作成することはできません。
PATCH Modifies a resource with a set of client-specified changes (partial update).
PATCHクライアント指定の変更のセットでリソースを変更します（部分的な更新）。
DELETE Deletes a resource.
DELETEリソースを削除します。
Table 1: SCIM HTTP Methods
表1：SCIM HTTPメソッド
Resource Endpoint Operations Description
-------- ---------------- ---------------------- --------------------
User /Users GET (Section 3.4.1), Retrieve, add,
POST (Section 3.3), modify Users.
PUT (Section 3.5.1),
PATCH (Section 3.5.2),
DELETE (Section 3.6)
Group /Groups GET (Section 3.4.1), Retrieve, add, POST (Section 3.3), modify Groups. PUT (Section 3.5.1), PATCH (Section 3.5.2), DELETE (Section 3.6)
グループ/ Groups GET（セクション3.4.1）、取得、追加、POST（セクション3.3）、グループの変更。 PUT（セクション3.5.1）、PATCH（セクション3.5.2）、DELETE（セクション3.6）
Self /Me GET, POST, PUT, PATCH, Alias for operations DELETE (Section 3.11) against a resource mapped to an authenticated subject (e.g., User).
Self / Me GET、POST、PUT、PATCH、認証済みサブジェクト（ユーザーなど）にマップされたリソースに対する操作DELETE（セクション3.11）のエイリアス。
Service /ServiceProvider GET (Section 4) Retrieve service provider Config provider's config. configuration.
Service / ServiceProvider GET（セクション4）サービスプロバイダーの構成プロバイダーの構成を取得します。構成。
Resource /ResourceTypes GET (Section 4) Retrieve supported type resource types.
Resource / ResourceTypes GET（セクション4）サポートされているタイプのリソースタイプを取得します。
Schema /Schemas GET (Section 4) Retrieve one or more supported schemas.
Schema / Schemas GET（セクション4）1つ以上のサポートされているスキーマを取得します。
Bulk /Bulk POST (Section 3.7) Bulk updates to one or more resources.
一括/ Bulk POST（セクション3.7）1つ以上のリソースに対する一括更新。
Search [prefix]/.search POST (Section 3.4.3) Search from system root or within a resource endpoint for one or more resource types using POST.
Search [prefix] /。search POST（セクション3.4.3）POSTを使用して、システムルートから、またはリソースエンドポイント内で1つ以上のリソースタイプを検索します。
Table 2: Defined Endpoints
表2：定義されたエンドポイント
All requests to the service provider are made via HTTP methods as per Section 4.3 of [RFC7231] on a URL derived from the Base URL. Responses are returned in the body of the HTTP response, formatted as JSON. Error status codes SHOULD be transmitted via the HTTP status code of the response (if possible) and SHOULD also be specified in the body of the response (see Section 3.12).
サービスプロバイダーへのすべてのリクエストは、[RFC7231]のセクション4.3に従って、ベースURLから派生したURLでHTTPメソッドを介して行われます。応答は、JSON形式のHTTP応答の本文で返されます。エラーステータスコードは、レスポンスのHTTPステータスコードを介して送信する必要があり（可能な場合）、レスポンスの本文にも指定する必要があります（セクション3.12を参照）。
To create new resources, clients send HTTP POST requests to the resource endpoint, such as "/Users" or "/Groups", as defined by the associated resource type endpoint discovery (see Section 4).
新しいリソースを作成するために、クライアントは関連するリソースタイプのエンドポイントディスカバリで定義されているように、「/ Users」や「/ Groups」などのリソースエンドポイントにHTTP POSTリクエストを送信します（セクション4を参照）。
The server SHALL process attributes according to the following mutability rules:
サーバーは、以下の可変性ルールに従って属性を処理する必要があります（SHALL）。
o In the request body, attributes whose mutability is "readOnly" (see Sections 2.2 and 7 of [RFC7643]) SHALL be ignored.
o リクエストボディでは、変更可能性が「readOnly」である属性（[RFC7643]のセクション2.2および7を参照）は無視される必要があります。
o Attributes whose mutability is "readWrite" (see Section 2.2 of [RFC7643]) and that are omitted from the request body MAY be assumed to be not asserted by the client. The service provider MAY assign a default value to non-asserted attributes in the final resource representation.
o 変更可能性が「readWrite」（[RFC7643]のセクション2.2を参照）であり、リクエストの本文から省略されている属性は、クライアントによってアサートされていないと見なされる場合があります。サービスプロバイダーは、最終的なリソース表現のアサートされていない属性にデフォルト値を割り当ててもよい（MAY）。
o Service providers MAY take into account whether or not a client has access to all of the resource's attributes when deciding whether or not non-asserted attributes should be defaulted.
o サービスプロバイダーは、アサートされていない属性をデフォルトにするかどうかを決定するときに、クライアントがリソースのすべての属性にアクセスできるかどうかを考慮してもよい（MAY）。
o Clients that intend to override existing or server-defaulted values for attributes MAY specify "null" for a single-valued attribute or an empty array "[]" for a multi-valued attribute to clear all values.
o 属性の既存の値またはサーバーのデフォルト値をオーバーライドするクライアントは、単一値の属性に「null」を指定するか、複数値の属性に空の配列「[]」を指定して、すべての値をクリアすることができます。
When the service provider successfully creates the new resource, an HTTP response SHALL be returned with HTTP status code 201 (Created). The response body SHOULD contain the service provider's representation of the newly created resource. The URI of the created resource SHALL include, in the HTTP "Location" header and the HTTP body, a JSON representation [RFC7159] with the attribute "meta.location". Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the client, enabling it to correlate the client's and server's views of the new resource.
サービスプロバイダーが新しいリソースを正常に作成すると、HTTPステータスコード201（Created）でHTTP応答が返される必要があります（SHALL）。応答本文には、新しく作成されたリソースのサービスプロバイダーの表現が含まれている必要があります（SHOULD）。作成されたリソースのURIは、HTTP "Location"ヘッダーとHTTP本文に、属性 "meta.location"を持つJSON表現[RFC7159]を含める必要があります（SHALL）。サーバーはPOSTされたコンテンツを自由に変更したり無視したりできるため、完全な表現を返すことはクライアントにとって有用であり、クライアントとサーバーの新しいリソースのビューを関連付けることができます。
If the service provider determines that the creation of the requested resource conflicts with existing resources (e.g., a "User" resource with a duplicate "userName"), the service provider MUST return HTTP status code 409 (Conflict) with a "scimType" error code of "uniqueness", as per Section 3.12.
要求されたリソースの作成が既存のリソース（たとえば、「userName」が重複する「User」リソース）と競合するとサービスプロバイダーが判断した場合、サービスプロバイダーは「scimType」エラーでHTTPステータスコード409（競合）を返す必要がありますセクション3.12の「一意性」のコード。
In the following example, a client sends a POST request containing a "User" to the "/Users" endpoint.
次の例では、クライアントは「User」を含むPOSTリクエストを「/ Users」エンドポイントに送信します。
POST /Users HTTP/1.1 Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / Users HTTP / 1.1 Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"bjensen",
"externalId":"bjensen",
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
}
}
In response to the example request above, the server signals a
successful creation with an HTTP status code 201 (Created) and
returns a representation of the resource created:
HTTP/1.1 201 Created
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"externalId":"bjensen",
"meta":{
"resourceType":"User",
"created":"2011-08-01T21:32:44.882Z",
"lastModified":"2011-08-01T21:32:44.882Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"e180ee84f0671b1\""
},
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
},
"userName":"bjensen"
}
When adding a resource to a specific endpoint, the meta attribute "resourceType" SHALL be set by the HTTP service provider to the corresponding resource type for the endpoint. For example, a POST to the endpoint "/Users" will set "resourceType" to "User", and "/Groups" will set "resourceType" to "Group".
リソースを特定のエンドポイントに追加するとき、メタ属性 "resourceType"は、HTTPサービスプロバイダーによってエンドポイントの対応するリソースタイプに設定される必要があります（SHALL）。たとえば、エンドポイント「/ Users」へのPOSTは「resourceType」を「User」に設定し、「/ Groups」は「resourceType」を「Group」に設定します。
Resources MAY be retrieved via opaque, unique URLs or via queries (see Section 3.4.2). The attributes returned are defined in the server's attribute schema (see Section 8.7 of [RFC7643]) and may be modified by request parameters (see Section 3.9). By default, resource attributes returned in a response are those attributes whose characteristic "returned" setting is "always" or "default" (see Section 2.2 of [RFC7643]).
リソースは、不透明な一意のURLまたはクエリを介して取得できます（セクション3.4.2を参照）。返される属性はサーバーの属性スキーマで定義され（[RFC7643]のセクション8.7を参照）、リクエストパラメータによって変更される場合があります（セクション3.9を参照）。デフォルトでは、レスポンスで返されるリソース属性は、特性「返される」設定が「常に」または「デフォルト」である属性です（[RFC7643]のセクション2.2を参照）。
To retrieve a known resource, clients send GET requests to the resource endpoint, e.g., "/Users/{id}", "/Groups/{id}", or "/Schemas/{id}", where "{id}" is a resource identifier (for example, the value of the "id" attribute).
既知のリソースを取得するために、クライアントはGETリクエストをリソースエンドポイントに送信します（例： "/ Users / {id}"、 "/ Groups / {id}"、または "/ Schemas / {id}"、ここで "{id} "はリソース識別子です（たとえば、" id "属性の値）。
If the resource exists, the server responds with HTTP status code 200 (OK) and includes the result in the body of the response.
リソースが存在する場合、サーバーはHTTPステータスコード200（OK）で応答し、結果を応答の本文に含めます。
The example below retrieves a single User via the "/Users" endpoint.
以下の例では、「/ Users」エンドポイントを介して単一のユーザーを取得します。
GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
The server responds with:
サーバーは次のように応答します。
HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"f250dd84f0671c3"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"externalId":"bjensen",
"meta":{
"resourceType":"User",
"created":"2011-08-01T18:29:49.793Z",
"lastModified":"2011-08-01T18:29:49.793Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"f250dd84f0671c3\""
},
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
},
"userName":"bjensen",
"phoneNumbers":[
{
"value":"555-555-8377",
"type":"work"
}
],
"emails":[
{
"value":"bjensen@example.com",
"type":"work"
}
]
}
The SCIM protocol defines a standard set of query parameters that can be used to filter, sort, and paginate to return zero or more resources in a query response. Queries MAY be made against a single resource or a resource type endpoint (e.g., "/Users"), or the service provider Base URI. SCIM service providers MAY support additional query parameters not specified here and SHOULD ignore any query parameters they do not recognize instead of rejecting the query for versioning compatibility reasons.
SCIMプロトコルは、クエリパラメータの標準セットを定義します。これを使用して、クエリ応答で0個以上のリソースを返すためにフィルター処理、並べ替え、およびページ分割を行うことができます。クエリは、単一のリソースまたはリソースタイプのエンドポイント（「/ Users」など）、またはサービスプロバイダーのベースURIに対して行われる場合があります。 SCIMサービスプロバイダーは、ここで指定されていない追加のクエリパラメーターをサポートする場合があり（MAY）、バージョニングの互換性の理由でクエリを拒否する代わりに、認識しないクエリパラメータを無視する必要があります（SHOULD）。
Responses MUST be identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:ListResponse". The following attributes are defined for responses:
応答は、次のURIを使用して識別される必要があります： "urn：ietf：params：scim：api：messages：2.0：ListResponse"。以下の属性が応答に対して定義されています。
totalResults The total number of results returned by the list or query operation. The value may be larger than the number of resources returned, such as when returning a single page (see Section 3.4.2.4) of results where multiple pages are available. REQUIRED.
totalResultsリストまたはクエリ操作によって返された結果の総数。値は、複数のページが利用可能な結果の単一ページ（セクション3.4.2.4を参照）を返す場合など、返されるリソースの数よりも大きい場合があります。必須。
Resources A multi-valued list of complex objects containing the requested resources. This MAY be a subset of the full set of resources if pagination (Section 3.4.2.4) is requested. REQUIRED if "totalResults" is non-zero.
リソース要求されたリソースを含む複合オブジェクトの多値リスト。ページネーション（セクション3.4.2.4）が要求された場合、これはリソースの完全なセットのサブセットになる場合があります。 「totalResults」がゼロ以外の場合は必須です。
startIndex The 1-based index of the first result in the current set of list results. REQUIRED when partial results are returned due to pagination.
startIndex現在のリスト結果セットの最初の結果の1から始まるインデックス。ページ分割のために部分的な結果が返される場合に必要です。
itemsPerPage The number of resources returned in a list response page. REQUIRED when partial results are returned due to pagination.
itemsPerPageリスト応答ページで返されたリソースの数。ページ分割のために部分的な結果が返される場合に必要です。
A query that does not return any matches SHALL return success (HTTP status code 200) with "totalResults" set to a value of 0.
一致を返さないクエリは、「totalResults」の値を0に設定して成功（HTTPステータスコード200）を返す必要があります。
The example query below requests the userName for all Users:
以下のクエリ例は、すべてのユーザーのuserNameを要求します。
GET /Users?attributes=userName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
The following is an example response to the query above:
以下は、上記のクエリに対する応答例です。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults":2,
"Resources":[
{
"id":"2819c223-7f76-453a-919d-413861904646",
"userName":"bjensen"
},
{
"id":"c75ad752-64ae-4823-840d-ffa80929976c",
"userName":"jsmith"
}
]
}
Note that in the above example, "id" is returned because the "id" attribute has the "returned" characteristic of "always".
上記の例では、「id」属性に「always」の「返される」特性があるため、「id」が返されることに注意してください。
Queries MAY be performed against a SCIM resource object, a resource type endpoint, or a SCIM server root. For example:
クエリは、SCIMリソースオブジェクト、リソースタイプエンドポイント、またはSCIMサーバールートに対して実行される場合があります。例えば：
"/Users/{id}"
"/Users"
「/ユーザー」
"/Groups"
「/グループ」
A query against a server root indicates that all resources within the server SHALL be included, subject to filtering. A filter expression using "meta.resourceType" MAY be used to restrict results to one or more specific resource types (to exclude others). For example:
サーバールートに対するクエリは、サーバー内のすべてのリソースが含まれる必要があることを示し、フィルタリングの対象となります。 「meta.resourceType」を使用するフィルター式を使用して、結果を1つ以上の特定のリソースタイプに制限できます（他を除外するため）。例えば：
filter=(meta.resourceType eq User) or (meta.resourceType eq Group)
filter =（meta.resourceType eq User）または（meta.resourceType eq Group）
If a SCIM service provider determines that too many results would be returned (e.g., because a client queried a resource type endpoint or the server base URI), the server SHALL reject the request by returning an HTTP response with HTTP status code 400 (Bad Request) and JSON attribute "scimType" set to "tooMany" (see Table 9).
SCIMサービスプロバイダーが返す結果が多すぎると判断した場合（たとえば、クライアントがリソースタイプのエンドポイントまたはサーバーのベースURIをクエリしたため）、サーバーはHTTPステータスコード400（Bad Request ）およびJSON属性「scimType」が「tooMany」に設定されています（表9を参照）。
When processing query operations using endpoints that include more than one SCIM resource type (e.g., a query from the server root endpoint), filters MUST be processed as outlined in Section 3.4.2.2. For filtered attributes that are not part of a particular resource type, the service provider SHALL treat the attribute as if there is no attribute value. For example, a presence or equality filter for an undefined attribute evaluates to false.
複数のSCIMリソースタイプを含むエンドポイント（サーバールートエンドポイントからのクエリなど）を使用してクエリ操作を処理する場合、セクション3.4.2.2で概説されているようにフィルターを処理する必要があります。特定のリソースタイプの一部ではないフィルタリングされた属性の場合、サービスプロバイダーは、属性値がないかのように属性を処理する必要があります（SHALL）。たとえば、未定義の属性のプレゼンスまたは等価フィルターはfalseと評価されます。
Filtering is an OPTIONAL parameter for SCIM service providers. Clients MAY discover service provider filter capabilities by looking at the "filter" attribute of the "ServiceProviderConfig" endpoint (see Section 4). Clients MAY request a subset of resources by specifying the "filter" query parameter containing a filter expression. When specified, only those resources matching the filter expression SHALL be returned. The expression language that is used with the filter parameter supports references to attributes and literals.
フィルタリングは、SCIMサービスプロバイダーのオプションパラメーターです。クライアントは、「ServiceProviderConfig」エンドポイントの「filter」属性を調べることで、サービスプロバイダーのフィルター機能を検出できます（セクション4を参照）。クライアントは、フィルタ式を含む「filter」クエリパラメータを指定することにより、リソースのサブセットをリクエストできます。指定すると、フィルター式に一致するリソースのみが返されます。 filterパラメーターで使用される式言語は、属性およびリテラルへの参照をサポートしています。
Attribute names and attribute operators used in filters are case insensitive. For example, the following two expressions will evaluate to the same logical value:
フィルターで使用される属性名と属性演算子は、大文字と小文字を区別しません。たとえば、次の2つの式は同じ論理値に評価されます。
filter=userName Eq "john"
filter = userName Eq "john"
filter=Username eq "john"
filter =ユーザー名eq "john"
The filter parameter MUST contain at least one valid expression (see Table 3). Each expression MUST contain an attribute name followed by an attribute operator and optional value. Multiple expressions MAY be combined using logical operators (see Table 4). Expressions MAY be grouped together using round brackets "(" and ")" (see Table 5).
フィルターパラメーターには、少なくとも1つの有効な式が含まれている必要があります（表3を参照）。各式には、属性名とそれに続く属性演算子とオプションの値が含まれている必要があります。論理演算子を使用して複数の式を組み合わせることができます（表4を参照）。式は、丸括弧「（」と「）」を使用してグループ化できます（表5を参照）。
The operators supported in the expression are listed in Table 3.
式でサポートされている演算子を表3に示します。
+----------+-------------+------------------------------------------+
| Operator | Description | Behavior |
+----------+-------------+------------------------------------------+
| eq | equal | The attribute and operator values must |
| | | be identical for a match. |
| | | |
| ne | not equal | The attribute and operator values are |
| | | not identical. |
| | | |
| co | contains | The entire operator value must be a |
| | | substring of the attribute value for a |
| | | match. |
| | | |
| sw | starts with | The entire operator value must be a |
| | | substring of the attribute value, |
| | | starting at the beginning of the |
| | | attribute value. This criterion is |
| | | satisfied if the two strings are |
| | | identical. |
| | | |
| ew | ends with | The entire operator value must be a |
| | | substring of the attribute value, |
| | | matching at the end of the attribute |
| | | value. This criterion is satisfied if |
| | | the two strings are identical. |
| | | |
| pr | present | If the attribute has a non-empty or |
| | (has value) | non-null value, or if it contains a |
| | | non-empty node for complex attributes, |
| | | there is a match. |
| | | |
| gt | greater | If the attribute value is greater than |
| | than | the operator value, there is a match. |
| | | The actual comparison is dependent on |
| | | the attribute type. For string |
| | | attribute types, this is a |
| | | lexicographical comparison, and for |
| | | DateTime types, it is a chronological |
| | | comparison. For integer attributes, it |
| | | is a comparison by numeric value. |
| | | Boolean and Binary attributes SHALL |
| | | cause a failed response (HTTP status |
| | | code 400) with "scimType" of |
| | | "invalidFilter". |
| | | |
| ge | greater | If the attribute value is greater than |
| | than or | or equal to the operator value, there is |
| | equal to | a match. The actual comparison is |
| | | dependent on the attribute type. For |
| | | string attribute types, this is a |
| | | lexicographical comparison, and for |
| | | DateTime types, it is a chronological |
| | | comparison. For integer attributes, it |
| | | is a comparison by numeric value. |
| | | Boolean and Binary attributes SHALL |
| | | cause a failed response (HTTP status |
| | | code 400) with "scimType" of |
| | | "invalidFilter". |
| | | |
| lt | less than | If the attribute value is less than the |
| | | operator value, there is a match. The |
| | | actual comparison is dependent on the |
| | | attribute type. For string attribute |
| | | types, this is a lexicographical |
| | | comparison, and for DateTime types, it |
| | | is a chronological comparison. For |
| | | integer attributes, it is a comparison |
| | | by numeric value. Boolean and Binary |
| | | attributes SHALL cause a failed response |
| | | (HTTP status code 400) with "scimType" |
| | | of "invalidFilter". |
| | | |
| le | less than | If the attribute value is less than or |
| | or equal to | equal to the operator value, there is a |
| | | match. The actual comparison is |
| | | dependent on the attribute type. For |
| | | string attribute types, this is a |
| | | lexicographical comparison, and for |
| | | DateTime types, it is a chronological |
| | | comparison. For integer attributes, it |
| | | is a comparison by numeric value. |
| | | Boolean and Binary attributes SHALL |
| | | cause a failed response (HTTP status |
| | | code 400) with "scimType" of |
| | | "invalidFilter". |
+----------+-------------+------------------------------------------+
Table 3: Attribute Operators
表3：属性演算子
+----------+-------------+------------------------------------------+
| Operator | Description | Behavior |
+----------+-------------+------------------------------------------+
| and | Logical | The filter is only a match if both |
| | "and" | expressions evaluate to true. |
| | | |
| or | Logical | The filter is a match if either |
| | "or" | expression evaluates to true. |
| | | |
| not | "Not" | The filter is a match if the expression |
| | function | evaluates to false. |
+----------+-------------+------------------------------------------+
Table 4: Logical Operators
表4：論理演算子
+----------+-------------+------------------------------------------+
| Operator | Description | Behavior |
+----------+-------------+------------------------------------------+
| ( ) | Precedence | Boolean expressions MAY be grouped using |
| | grouping | parentheses to change the standard order |
| | | of operations, i.e., to evaluate logical |
| | | "or" operators before logical "and" |
| | | operators. |
| | | |
| [ ] | Complex | Service providers MAY support complex |
| | attribute | filters where expressions MUST be |
| | filter | applied to the same value of a parent |
| | grouping | attribute specified immediately before |
| | | the left square bracket ("["). The |
| | | expression within square brackets ("[" |
| | | and "]") MUST be a valid filter |
| | | expression based upon sub-attributes of |
| | | the parent attribute. Nested |
| | | expressions MAY be used. See examples |
| | | below. |
+----------+-------------+------------------------------------------+
Table 5: Grouping Operators
表5：グループ化演算子
SCIM filters MUST conform to the following ABNF [RFC5234] rules as specified below:
SCIMフィルターは、以下に示すように、次のABNF [RFC5234]規則に準拠する必要があります。
FILTER = attrExp / logExp / valuePath / *1"not" "(" FILTER ")"
valuePath = attrPath "[" valFilter "]" ; FILTER uses sub-attributes of a parent attrPath
valuePath = attrPath "[" valFilter "]"; FILTERは親attrPathのサブ属性を使用します
valFilter = attrExp / logExp / *1"not" "(" valFilter ")"
attrExp = (attrPath SP "pr") /
(attrPath SP compareOp SP compValue)
logExp = FILTER SP ("and" / "or") SP FILTER
compValue = false / null / true / number / string
; rules from JSON (RFC 7159)
compareOp = "eq" / "ne" / "co" /
"sw" / "ew" /
"gt" / "lt" /
"ge" / "le"
attrPath = [URI ":"] ATTRNAME *1subAttr
; SCIM attribute name
; URI is SCIM "schema" URI
ATTRNAME = ALPHA *(nameChar)
ATTRNAME = ALPHA *（nameChar）
nameChar = "-" / "_" / DIGIT / ALPHA
subAttr = "." ATTRNAME ; a sub-attribute of a complex attribute
subAttr = "。" ATTRNAME;複合属性のサブ属性
Figure 1: ABNF Specification of SCIM Filters
図1：SCIMフィルターのABNF仕様
In the above ABNF rules, the "compValue" (comparison value) rule is built on JSON Data Interchange format ABNF rules as specified in [RFC7159], "DIGIT" and "ALPHA" are defined per Appendix B.1 of [RFC5234], and "URI" is defined per Appendix A of [RFC3986].
上記のABNFルールでは、「compValue」（比較値）ルールは、JSON Data Interchange形式のABNFルールに基づいて構築されており、[RFC7159]で指定されています。「DIGIT」と「ALPHA」は、[RFC5234]の付録B.1に従って定義されています。 「URI」は、[RFC3986]の付録Aに従って定義されています。
Filters MUST be evaluated using the following order of operations, in order of precedence:
フィルターは、次の優先順位の操作を使用して評価する必要があります。
1. Grouping operators
1. グループ化演算子
2. Logical operators - where "not" takes precedence over "and", which takes precedence over "or"
2. 論理演算子-「not」は「and」よりも優先され、「and」は「or」よりも優先されます。
3. Attribute operators
3. 属性演算子
If the specified attribute in a filter expression is a multi-valued attribute, the filter matches if any of the values of the specified attribute match the specified criterion; e.g., if a User has multiple "emails" values, only one has to match for the entire User to match. For complex attributes, a fully qualified sub-attribute MUST be specified using standard attribute notation (Section 3.10). For example, to filter by userName, the parameter value is "userName". To filter by first name, the parameter value is "name.givenName".
フィルター式で指定された属性が複数値属性である場合、指定された属性のいずれかの値が指定された基準に一致すると、フィルターが一致します。たとえば、ユーザーが複数の「メール」値を持っている場合、ユーザー全体が一致するために一致する必要があるのは1つだけです。複雑な属性の場合、標準の属性表記を使用して完全修飾サブ属性を指定する必要があります（セクション3.10）。たとえば、userNameでフィルタリングするには、パラメーター値は「userName」です。名でフィルタリングするには、パラメーター値は "name.givenName"です。
When applying a comparison (e.g., "eq") or presence filter (e.g., "pr") to a defaulted attribute, the service provider SHALL use the value that was returned to the client that last created or modified the attribute.
デフォルトの属性に比較（「eq」など）またはプレゼンスフィルター（「pr」など）を適用する場合、サービスプロバイダーは、属性を最後に作成または変更したクライアントに返された値を使用する必要があります（SHALL）。
Providers MAY support additional filter operations if they choose. Providers MUST decline to filter results if the specified filter operation is not recognized and return an HTTP 400 error with a "scimType" error of "invalidFilter" and an appropriate human-readable response as per Section 3.12. For example, if a client specified an unsupported operator named 'regex', the service provider should specify an error response description identifying the client error, e.g., 'The operator 'regex' is not supported.'
プロバイダーは、必要に応じて追加のフィルター操作をサポートする場合があります。プロバイダーは、指定されたフィルター操作が認識されない場合は結果のフィルターを拒否し、3.12のとおり、「invalidFilter」の「scimType」エラーと適切な人間が読み取れる応答を含むHTTP 400エラーを返す必要があります。たとえば、クライアントが「regex」という名前のサポートされていない演算子を指定した場合、サービスプロバイダーは、クライアントのエラーを識別するエラー応答の説明を指定する必要があります。たとえば、「演算子「regex」はサポートされていません。」
When comparing attributes of type String, the case sensitivity for String type attributes SHALL be determined by the attribute's "caseExact" characteristic (see Section 2.2 of [RFC7643]).
文字列型の属性を比較する場合、文字列型属性の大文字と小文字の区別は、属性の "caseExact"特性によって決定されるものとします（[RFC7643]のセクション2.2を参照）。
Clients MAY query by schema or schema extensions by using a filter expression including the "schemas" attribute (as shown in Figure 2).
クライアントは、「スキーマ」属性を含むフィルター式を使用して、スキーマまたはスキーマ拡張によってクエリを実行できます（図2を参照）。
The following are examples of valid filters. Some attributes (e.g., rooms and rooms.number) are hypothetical extensions and are not part of the SCIM core schema:
以下は、有効なフィルターの例です。一部の属性（roomsやrooms.numberなど）は架空の拡張であり、SCIMコアスキーマの一部ではありません。
filter=userName eq "bjensen"
filter = userName eq "bjensen"
filter=name.familyName co "O'Malley"
filter = name.familyName co "O'Malley"
filter=userName sw "J"
filter = userName sw "J"
filter=urn:ietf:params:scim:schemas:core:2.0:User:userName sw "J"
filter=title pr
フィルター=タイトル
filter=meta.lastModified gt "2011-05-13T04:42:34Z"
filter=meta.lastModified ge "2011-05-13T04:42:34Z"
filter=meta.lastModified lt "2011-05-13T04:42:34Z"
filter=meta.lastModified le "2011-05-13T04:42:34Z"
filter=title pr and userType eq "Employee"
filter = title prおよびuserType eq "Employee"
filter=title pr or userType eq "Intern"
filter = title prまたはuserType eq "Intern"
filter=
schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
filter=userType eq "Employee" and (emails co "example.com" or emails.value co "example.org")
filter = userType eq "Employee" and（emails co "example.com" or emails.value co "example.org"）
filter=userType ne "Employee" and not (emails co "example.com" or emails.value co "example.org")
filter = userType ne「従業員」ではなく（ecos co「example.com」またはemails.value co「example.org」）
filter=userType eq "Employee" and (emails.type eq "work")
filter = userType eq "Employee"および（emails.type eq "work"）
filter=userType eq "Employee" and emails[type eq "work" and value co "@example.com"]
filter = userType eq "Employee" and emails [type eq "work" and value co "@ example.com"]
filter=emails[type eq "work" and value co "@example.com"] or ims[type eq "xmpp" and value co "@foo.com"]
filter = emails [type eq "work" and value co "@ example.com"]またはims [type eq "xmpp" and value co "@ foo.com"]
Figure 2: Example Filters
図2：フィルターの例
Sort is OPTIONAL. Clients MAY discover sort capability by looking at the "sort" attribute of the service provider configuration (see Section 4). Sorting allows clients to specify the order in which resources are returned by specifying a combination of "sortBy" and "sortOrder" URL parameters.
ソートはオプションです。クライアントは、サービスプロバイダー構成の「sort」属性を調べることで、ソート機能を検出できます（セクション4を参照）。並べ替えにより、クライアントは "sortBy"と "sortOrder" URLパラメータの組み合わせを指定することにより、リソースが返される順序を指定できます。
sortBy The "sortBy" parameter specifies the attribute whose value SHALL be used to order the returned responses. If the "sortBy" attribute corresponds to a singular attribute, resources are sorted according to that attribute's value; if it's a multi-valued attribute, resources are sorted by the value of the primary attribute (see Section 2.4 of [RFC7643]), if any, or else the first value in the list, if any. If the attribute is complex, the attribute name must be a path to a sub-attribute in standard attribute notation (Section 3.10), e.g., "sortBy=name.givenName". For all attribute types, if there is no data for the specified "sortBy" value, they are sorted via the "sortOrder" parameter, i.e., they are ordered last if ascending and first if descending.
sortBy "sortBy"パラメータは、返される応答を並べ替えるためにその値を使用する必要がある属性を指定します。 「sortBy」属性が単一の属性に対応する場合、リソースはその属性の値に従ってソートされます。複数値の属性の場合、リソースは、存在する場合はプライマリ属性の値（[RFC7643]のセクション2.4を参照）、または存在する場合はリストの最初の値でソートされます。属性が複雑な場合、属性名は標準の属性表記（セクション3.10）のサブ属性へのパスでなければなりません（例： "sortBy = name.givenName"）。すべての属性タイプについて、指定された「sortBy」値のデータがない場合、「sortOrder」パラメーターを介してソートされます。つまり、昇順の場合は最後に、降順の場合は最初に並べられます。
sortOrder The order in which the "sortBy" parameter is applied. Allowed values are "ascending" and "descending". If a value for "sortBy" is provided and no "sortOrder" is specified, "sortOrder" SHALL default to ascending. String type attributes are case insensitive by default, unless the attribute type is defined as a case-exact string. "sortOrder" MUST sort according to the attribute type; i.e., for case-insensitive attributes, sort the result using case-insensitive Unicode alphabetic sort order with no specific locale implied, and for case-exact attribute types, sort the result using case-sensitive Unicode alphabetic sort order.
sortOrder「sortBy」パラメータが適用される順序。許可される値は、「昇順」と「降順」です。 「sortBy」の値が指定されていて、「sortOrder」が指定されていない場合、「sortOrder」はデフォルトで昇順になります。文字列タイプの属性は、属性タイプが大文字と小文字が正確な文字列として定義されていない限り、デフォルトでは大文字と小文字が区別されません。 「sortOrder」は属性タイプに従ってソートする必要があります。つまり、大文字と小文字を区別しない属性の場合は、特定のロケールを暗黙指定せずに、大文字と小文字を区別しないUnicodeアルファベットの並べ替え順序を使用して結果を並べ替え、大文字小文字を区別する属性タイプの場合は、大文字と小文字を区別するUnicodeアルファベットの並べ替え順序を使用して結果を並べ替えます。
Pagination parameters can be used together to "page through" large numbers of resources so as not to overwhelm the client or service provider. Because pagination is not stateful, clients MUST be prepared to handle inconsistent results. For example, a request for a list of 10 resources beginning with a startIndex of 1 MAY return different results when repeated, since resources on the service provider may have changed between requests. Pagination parameters and general behavior are derived from the OpenSearch Protocol [OpenSearch].
クライアントまたはサービスプロバイダーを圧倒しないように、ページ分割パラメータを一緒に使用して、多数のリソースを「ページスルー」することができます。ページネーションはステートフルではないため、クライアントは一貫性のない結果を処理できるように準備する必要があります。たとえば、サービスプロバイダーのリソースはリクエスト間で変更されている可能性があるため、startIndexが1で始まる10個のリソースのリストに対するリクエストは、繰り返されると異なる結果を返す場合があります。ページ分割パラメータと一般的な動作は、OpenSearch Protocol [OpenSearch]から派生しています。
Table 6 describes the URL pagination parameters.
表6は、URLページ付けパラメーターを説明しています。
+------------+----------------------------+-------------------------+
| Parameter | Description | Default |
+------------+----------------------------+-------------------------+
| startIndex | The 1-based index of the | 1 |
| | first query result. A | |
| | value less than 1 SHALL be | |
| | interpreted as 1. | |
| | | |
| count | Non-negative integer. | None. When specified, |
| | Specifies the desired | the service provider |
| | maximum number of query | MUST NOT return more |
| | results per page, e.g., | results than specified, |
| | 10. A negative value | although it MAY return |
| | SHALL be interpreted as | fewer results. If |
| | "0". A value of "0" | unspecified, the |
| | indicates that no resource | maximum number of |
| | results are to be returned | results is set by the |
| | except for "totalResults". | service provider. |
+------------+----------------------------+-------------------------+
Table 6: Pagination Request Parameters
表6：ページネーション要求パラメーター
Table 7 describes the query response pagination attributes specified by the service provider.
表7は、サービスプロバイダーによって指定されたクエリレスポンスのページネーション属性を示しています。
+--------------+----------------------------------------------------+
| Element | Description |
+--------------+----------------------------------------------------+
| itemsPerPage | Non-negative integer. Specifies the number of |
| | query results returned in a query response page, |
| | e.g., 10. |
| | |
| totalResults | Non-negative integer. Specifies the total number |
| | of results matching the client query, e.g., 1000. |
| | |
| startIndex | The 1-based index of the first result in the |
| | current set of query results, e.g., 1. |
+--------------+----------------------------------------------------+
Table 7: Pagination Response Elements
表7：ページネーション応答要素
For example, to retrieve the first 10 Users, set the startIndex to 1 and the count to 10:
たとえば、最初の10人のユーザーを取得するには、startIndexを1に、カウントを10に設定します。
GET /Users?startIndex=1&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
The response to the query above returns metadata regarding paging similar to the following example (actual resources removed for brevity):
上記のクエリに対する応答は、次の例のようにページングに関するメタデータを返します（簡潔にするために実際のリソースは削除されています）。
{
"totalResults":100,
"itemsPerPage":10,
"startIndex":1,
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{
...
}]
}
Figure 3: ListResponse Format for Returning Multiple Resources
図3：複数のリソースを返すためのListResponse形式
Given the example above, to continue paging, set the startIndex to 11 and re-fetch, i.e., /Users?startIndex=11&count=10.
上記の例の場合、ページングを続行するには、startIndexを11に設定して再フェッチします（つまり、/ Users？startIndex = 11＆count = 10）。
The following attributes control which attributes SHALL be returned with a returned resource. SCIM clients MAY use one of these two OPTIONAL parameters, which MUST be supported by SCIM service providers:
次の属性は、返されるリソースでどの属性を返す必要があるかを制御します。 SCIMクライアントは、SCIMサービスプロバイダーによってサポートされている必要があるこれら2つのOPTIONALパラメーターのいずれかを使用できます（MAY）。
attributes A multi-valued list of strings indicating the names of resource attributes to return in the response, overriding the set of attributes that would be returned by default. Attribute names MUST be in standard attribute notation (Section 3.10) form. See Section 3.9 for additional retrieval query parameters.
attributes応答で返されるリソース属性の名前を示す文字列の多値リスト。デフォルトで返される属性のセットをオーバーライドします。属性名は、標準の属性表記（セクション3.10）の形式にする必要があります。追加の検索クエリパラメータについては、セクション3.9を参照してください。
excludedAttributes A multi-valued list of strings indicating the names of resource attributes to be removed from the default set of attributes to return. This parameter SHALL have no effect on attributes whose schema "returned" setting is "always" (see Sections 2.2 and 7 of [RFC7643]). Attribute names MUST be in standard attribute notation (Section 3.10) form. See Section 3.9 for additional retrieval query parameters.
excludeAttributes返す属性のデフォルトセットから削除されるリソース属性の名前を示す文字列の多値リスト。このパラメータは、スキーマの「返される」設定が「常に」である属性には影響しません（SHALL）（[RFC7643]のセクション2.2および7を参照）。属性名は、標準の属性表記（セクション3.10）の形式にする必要があります。追加の検索クエリパラメータについては、セクション3.9を参照してください。
Clients MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the "/.search" path extension. The inclusion of "/.search" on the end of a valid SCIM endpoint SHALL be used to indicate that the HTTP POST verb is intended to be a query operation.
クライアントは、 "/。search"パス拡張子と組み合わせたHTTP POST動詞を使用して、URLにパラメーターを渡さずにクエリを実行できます。有効なSCIMエンドポイントの末尾に「/.search」を含めることは、HTTP POST動詞がクエリ操作であることを示すために使用する必要があります（SHALL）。
To create a new query result set, a SCIM client sends an HTTP POST request to the desired SCIM resource endpoint (ending in "/.search"). The body of the POST request MAY include any of the parameters defined in Section 3.4.2.
新しいクエリ結果セットを作成するには、SCIMクライアントが目的のSCIMリソースエンドポイント（「/.search」で終わる）にHTTP POST要求を送信します。 POSTリクエストの本文には、セクション3.4.2で定義されているパラメータを含めることができます。
Query requests MUST be identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:SearchRequest". The following attributes are defined for query requests:
クエリ要求は、次のURIを使用して識別される必要があります： "urn：ietf：params：scim：api：messages：2.0：SearchRequest"。クエリリクエストには次の属性が定義されています。
attributes A multi-valued list of strings indicating the names of resource attributes to return in the response, overriding the set of attributes that would be returned by default. Attribute names MUST be in standard attribute notation (Section 3.10) form. See Section 3.9 for additional retrieval query parameters. OPTIONAL.
attributes応答で返されるリソース属性の名前を示す文字列の多値リスト。デフォルトで返される属性のセットをオーバーライドします。属性名は、標準の属性表記（セクション3.10）の形式にする必要があります。追加の検索クエリパラメータについては、セクション3.9を参照してください。オプション。
excludedAttributes A multi-valued list of strings indicating the names of resource attributes to be removed from the default set of attributes to return. This parameter SHALL have no effect on attributes whose schema "returned" setting is "always" (see Sections 2.2 and 7 of [RFC7643]). Attribute names MUST be in standard attribute notation (Section 3.10) form. See Section 3.9 for additional retrieval query parameters. OPTIONAL.
excludeAttributes返す属性のデフォルトセットから削除されるリソース属性の名前を示す文字列の多値リスト。このパラメータは、スキーマの「返される」設定が「常に」である属性には影響しません（SHALL）（[RFC7643]のセクション2.2および7を参照）。属性名は、標準の属性表記（セクション3.10）の形式にする必要があります。追加の検索クエリパラメータについては、セクション3.9を参照してください。オプション。
filter The filter string used to request a subset of resources. The filter string MUST be a valid filter (Section 3.4.2.2) expression. OPTIONAL.
filterリソースのサブセットを要求するために使用されるフィルター文字列。フィルター文字列は、有効なフィルター（セクション3.4.2.2）式である必要があります。オプション。
sortBy A string indicating the attribute whose value SHALL be used to order the returned responses. The "sortBy" attribute MUST be in standard attribute notation (Section 3.10) form. See Section 3.4.2.3. OPTIONAL.
sortBy返された応答を並べ替えるために値を使用する必要がある属性を示す文字列。 "sortBy"属性は、標準の属性表記（セクション3.10）の形式でなければなりません。セクション3.4.2.3を参照してください。オプション。
sortOrder A string indicating the order in which the "sortBy" parameter is applied. Allowed values are "ascending" and "descending". See Section 3.4.2.3. OPTIONAL.
sortOrder「sortBy」パラメータが適用される順序を示す文字列。許可される値は、「昇順」と「降順」です。セクション3.4.2.3を参照してください。オプション。
startIndex An integer indicating the 1-based index of the first query result. See Section 3.4.2.4. OPTIONAL.
startIndex最初のクエリ結果の1から始まるインデックスを示す整数。セクション3.4.2.4を参照してください。オプション。
count An integer indicating the desired maximum number of query results per page. See Section 3.4.2.4. OPTIONAL.
countページあたりのクエリ結果の望ましい最大数を示す整数。セクション3.4.2.4を参照してください。オプション。
After receiving an HTTP POST request, a response is returned as specified in Section 3.4.2.
HTTP POSTリクエストを受信すると、セクション3.4.2で指定されているように応答が返されます。
The following example shows an HTTP POST Query request with search parameters "attributes", "filter", and "count" included:
次の例は、検索パラメーター "attributes"、 "filter"、および "count"を含むHTTP POSTクエリリクエストを示しています。
POST /.search Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST /.search Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
"attributes": ["displayName", "userName"],
"filter":
"displayName sw \"smith\"",
"startIndex": 1,
"count": 10
}
Figure 4: Example POST Query Request
図4：POSTクエリ要求の例
The example below shows a query response with the first page of results. For brevity, only two matches are shown: one User and one Group.
以下の例は、結果の最初のページを含むクエリ応答を示しています。簡潔にするために、1つのユーザーと1つのグループの2つの一致のみが示されています。
HTTP/1.1 200 OK
Content-Type: application/scim+json
Location: https://example.com/.search
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults":100,
"itemsPerPage":10,
"startIndex":1,
"Resources":[
{
"id":"2819c223-7f76-413861904646",
"userName":"jsmith",
"displayName":"Smith, James"
},
{
"id":"c8596b90-7539-4f20968d1908",
"displayName":"Smith Family"
},
...
]
}
Figure 5: Example POST Query Response
図5：POSTクエリ応答の例
Resources can be modified in whole or in part using HTTP PUT or HTTP PATCH, respectively. Implementers MUST support HTTP PUT as specified in Section 4.3 of [RFC7231]. Resources such as Groups may be very large; hence, implementers SHOULD support HTTP PATCH [RFC5789] to enable partial resource modifications. Service provider support for HTTP PATCH may be discovered by querying the service provider configuration (see Section 4).
リソースは、HTTP PUTまたはHTTP PATCHをそれぞれ使用して、全体または一部を変更できます。 [RFC7231]のセクション4.3で指定されているように、実装者はHTTP PUTをサポートする必要があります。グループなどのリソースは非常に大きい場合があります。したがって、実装者は、HTTP PATCH [RFC5789]をサポートして、部分的なリソース変更を可能にする必要があります（SHOULD）。 HTTP PATCHのサービスプロバイダーサポートは、サービスプロバイダーの構成をクエリすることで検出できます（セクション4を参照）。
HTTP PUT is used to replace a resource's attributes. For example, clients that have previously retrieved the entire resource in advance and revised it MAY replace the resource using an HTTP PUT. Because SCIM resource identifiers are assigned by the service provider, HTTP PUT MUST NOT be used to create new resources.
HTTP PUTは、リソースの属性を置き換えるために使用されます。たとえば、以前にリソース全体を事前に取得して修正したクライアントは、HTTP PUTを使用してリソースを置き換える場合があります。 SCIMリソース識別子はサービスプロバイダーによって割り当てられるため、HTTP PUTを使用して新しいリソースを作成してはなりません（MUST NOT）。
As the operation's intent is to replace all attributes, SCIM clients MAY send all attributes, regardless of each attribute's mutability. The server will apply attribute-by-attribute replacements according to the following attribute mutability rules:
操作の目的はすべての属性を置き換えることであるため、SCIMクライアントは、各属性の可変性に関係なく、すべての属性を送信できます（MAY）。サーバーは、次の属性可変性ルールに従って属性ごとの置換を適用します。
readWrite, writeOnly Any values provided SHALL replace the existing attribute values.
readWrite、writeOnly指定された値は、既存の属性値を置き換えるものとします（SHALL）。
Attributes whose mutability is "readWrite" that are omitted from the request body MAY be assumed to be not asserted by the client. The service provider MAY assume that any existing values are to be cleared, or the service provider MAY assign a default value to the final resource representation. Service providers MAY take into account whether or not a client has access to, or understands, all of the resource's attributes when deciding whether non-asserted attributes SHALL be removed or defaulted. Clients that want to override a server's defaults MAY specify "null" for a single-valued attribute, or an empty array "[]" for a multi-valued attribute, to clear all values.
変更可能性が「readWrite」であり、リクエストの本文から省略されている属性は、クライアントによってアサートされていないと見なされる場合があります。サービスプロバイダーは、既存の値がクリアされると想定してもよいし、最終的なリソース表現にデフォルト値を割り当ててもよい（MAY）。サービスプロバイダーは、アサートされていない属性を削除するかデフォルトにするかを決定するときに、クライアントがすべてのリソースの属性にアクセスできるかどうか、またはリソースの属性を理解できるかどうかを考慮してもよい（MAY）。サーバーのデフォルトを上書きしたいクライアントは、単一値属性に「null」を指定するか、複数値属性に空の配列「[]」を指定して、すべての値をクリアすることができます。
immutable If one or more values are already set for the attribute, the input value(s) MUST match, or HTTP status code 400 SHOULD be returned with a "scimType" error code of "mutability". If the service provider has no existing values, the new value(s) SHALL be applied.
immutable属性に1つ以上の値がすでに設定されている場合は、入力値が一致する必要があります。一致しない場合、HTTPステータスコード400が「scabilityType」エラーコード「mutability」とともに返される必要があります。サービスプロバイダーに既存の値がない場合、新しい値が適用されます。
readOnly Any values provided SHALL be ignored.
readOnly指定された値はすべて無視する必要があります。
If an attribute is "required", clients MUST specify the attribute in the PUT request.
属性が「必須」の場合、クライアントはPUTリクエストで属性を指定する必要があります。
Unless otherwise specified, a successful PUT operation returns a 200 OK response code and the entire resource within the response body, enabling the client to correlate the client's and the service provider's views of the updated resource. For example:
特に指定されていない限り、成功したPUT操作は200 OK応答コードと応答本文内のリソース全体を返し、クライアントはクライアントとサービスプロバイダーの更新されたリソースのビューを関連付けることができます。例えば：
PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"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",
"familyName":"Jensen",
"givenName":"Barbara",
"middleName":"Jane"
},
"roles":[],
"emails":[
{
"value":"bjensen@example.com"
},
{
"value":"babs@jensen.org"
}
]
}
The service responds with the entire updated User:
HTTP/1.1 200 OK
Content-Type: application/scim+json
ETag: W/"b431af54f0671a2"
Location:
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
{
"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",
"familyName":"Jensen",
"givenName":"Barbara",
"middleName":"Jane"
},
"emails":[
{
"value":"bjensen@example.com"
},
{
"value":"babs@jensen.org"
}
],
"meta": {
"resourceType":"User",
"created":"2011-08-08T04:56:22Z",
"lastModified":"2011-08-08T08:00:12Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"b431af54f0671a2\""
}
}
HTTP PATCH is an OPTIONAL server function that enables clients to update one or more attributes of a SCIM resource using a sequence of operations to "add", "remove", or "replace" values. Clients may discover service provider support for PATCH by querying the service provider configuration (see Section 4).
HTTP PATCHはオプションのサーバー機能で、クライアントは、値を「追加」、「削除」、または「置換」する一連の操作を使用して、SCIMリソースの1つ以上の属性を更新できます。クライアントは、サービスプロバイダーの構成を照会することにより、PATCHのサービスプロバイダーサポートを検出できます（セクション4を参照）。
The general form of the SCIM PATCH request is based on JSON Patch [RFC6902]. One difference between SCIM PATCH and JSON Patch is that SCIM servers do not support array indexing and do not support [RFC6902] operation types relating to array element manipulation, such as "move".
SCIM PATCHリクエストの一般的な形式は、JSONパッチ[RFC6902]に基づいています。 SCIM PATCHとJSONパッチの1つの違いは、SCIMサーバーが配列のインデックス付けをサポートしておらず、「移動」などの配列要素の操作に関連する[RFC6902]操作タイプをサポートしていないことです。
The body of each request MUST contain the "schemas" attribute with the URI value of "urn:ietf:params:scim:api:messages:2.0:PatchOp".
各リクエストの本文には、URI値が「urn：ietf：params：scim：api：messages：2.0：PatchOp」の「schemas」属性が含まれている必要があります。
The body of an HTTP PATCH request MUST contain the attribute "Operations", whose value is an array of one or more PATCH operations. Each PATCH operation object MUST have exactly one "op" member, whose value indicates the operation to perform and MAY be one of "add", "remove", or "replace". The semantics of each operation are defined in the following subsections.
HTTP PATCHリクエストの本文には、属性「Operations」が含まれている必要があります。その値は、1つ以上のPATCH操作の配列です。各PATCH操作オブジェクトには、1つの「op」メンバーが必ず存在する必要があります。その値は、実行する操作を示し、「追加」、「削除」、または「置換」のいずれかになる場合があります。各操作のセマンティクスは、次のサブセクションで定義されています。
The following is an example representation of a PATCH request showing the basic JSON structure (non-normative):
以下は、基本的なJSON構造（非規範的）を示すPATCHリクエストの例です。
{ "schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[
{
"op":"add",
"path":"members",
"value":[
{
"display": "Babs Jensen",
"$ref":
"https://example.com/v2/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646"
}
]
},
... + additional operations if needed ...
]
}
Figure 6: Example JSON Body for SCIM PATCH Request
図6：SCIM PATCHリクエストのJSON本文の例
The "path" attribute value is a String containing an attribute path describing the target of the operation. The "path" attribute is OPTIONAL for "add" and "replace" and is REQUIRED for "remove" operations. See relevant operation sections below for details.
「パス」属性値は、操作のターゲットを説明する属性パスを含む文字列です。 「パス」属性は、「追加」および「置換」のオプションであり、「削除」操作には必須です。詳細については、以下の関連する操作セクションを参照してください。
The "path" attribute is described by the following ABNF syntax rule:
「パス」属性は、次のABNF構文規則によって記述されます。
PATH = attrPath / valuePath [subAttr]
PATH = attrPath / valuePath [subAttr]
Figure 7: SCIM PATCH PATH Rule
図7：SCIM PATCH PATHルール
The ABNF rules "attrPath", "valuePath", and "subAttr" are defined in Section 3.4.2.2. The "valuePath" rule allows specific values of a complex multi-valued attribute to be selected.
ABNFルール「attrPath」、「valuePath」、および「subAttr」はセクション3.4.2.2で定義されています。 「valuePath」ルールでは、複雑な多値属性の特定の値を選択できます。
Valid examples of "path" are as follows:
「パス」の有効な例は次のとおりです。
"path":"members"
"パス"： "メンバー"
"path":"name.familyName"
「パス」：「name.familyName」
"path":"addresses[type eq \"work\"]"
"パス"： "アドレス[タイプeq \"作業\ "]"
"path":"members[value eq \"2819c223-7f76-453a-919d-413861904646\"]"
"パス"： "メンバー[値eq \" 2819c223-7f76-453a-919d-413861904646 \ "]"
"path":"members[value eq \"2819c223-7f76-453a-919d-413861904646\"].displayName"
"パス"： "メンバー[値eq \" 2819c223-7f76-453a-919d-413861904646 \ "]。displayName"
Figure 8: Example Path Values
図8：パス値の例
Each operation against an attribute MUST be compatible with the attribute's mutability and schema as defined in Sections 2.2 and 2.3 of [RFC7643]. For example, a client MUST NOT modify an attribute that has mutability "readOnly" or "immutable". However, a client MAY "add" a value to an "immutable" attribute if the attribute had no previous value. An operation that is not compatible with an attribute's mutability or schema SHALL return the appropriate HTTP response status code and a JSON detail error response as defined in Section 3.12.
[RFC7643]のセクション2.2および2.3で定義されているように、属性に対する各操作は、属性の可変性およびスキーマと互換性がある必要があります。たとえば、クライアントは、「readOnly」または「immutable」という可変性を持つ属性を変更してはなりません（MUST NOT）。ただし、属性に以前の値がない場合、クライアントは「不変」属性に値を「追加」できます（MAY）。属性の可変性またはスキーマと互換性のない操作は、セクション3.12で定義されているように、適切なHTTP応答ステータスコードとJSON詳細エラー応答を返す必要があります（SHALL）。
The attribute notation rules described in Section 3.10 apply for describing attribute paths. For all operations, the value of the "schemas" attribute on the SCIM service provider's representation of the resource SHALL be assumed by default. If one of the PATCH operations modifies the "schemas" attribute, subsequent operations SHALL assume the modified state of the "schemas" attribute. Clients MAY implicitly modify the "schemas" attribute by adding (or replacing) an attribute with its fully qualified name, including schema URN. For example, adding the attribute "urn:ietf:params:scim: schemas:extension:enterprise:2.0:User:employeeNumber" automatically adds the value "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" to the resource's "schemas" attribute.
属性パスの記述には、セクション3.10で説明されている属性表記規則が適用されます。すべての操作について、SCIMサービスプロバイダーのリソースの表現の「スキーマ」属性の値は、デフォルトで想定されている必要があります。 PATCH操作の1つが「スキーマ」属性を変更する場合、後続の操作は「スキーマ」属性の変更された状態を想定するものとします（SHALL）。クライアントは、スキーマURNを含む完全修飾名で属性を追加（または置換）することにより、「スキーマ」属性を暗黙的に変更できます（MAY）。たとえば、属性「urn：ietf：params：scim：schemas：extension：enterprise：2.0：User：employeeNumber」を追加すると、値「urn：ietf：params：scim：schemas：extension：enterprise：2.0：User」が自動的に追加されますリソースの「スキーマ」属性に。
Each PATCH operation represents a single action to be applied to the same SCIM resource specified by the request URI. Operations are applied sequentially in the order they appear in the array. Each operation in the sequence is applied to the target resource; the resulting resource becomes the target of the next operation. Evaluation continues until all operations are successfully applied or until an error condition is encountered.
各PATCH操作は、要求URIで指定された同じSCIMリソースに適用される単一のアクションを表します。操作は、配列に表示される順序で順番に適用されます。シーケンスの各操作はターゲットリソースに適用されます。結果のリソースは次の操作のターゲットになります。すべての操作が正常に適用されるまで、またはエラー状態が発生するまで、評価は継続されます。
For multi-valued attributes, a PATCH operation that sets a value's "primary" sub-attribute to "true" SHALL cause the server to automatically set "primary" to "false" for any other values in the array.
多値属性の場合、値の「プライマリ」サブ属性を「true」に設定するPATCH操作により、サーバーは配列内の他の値に対して「プライマリ」を「false」に自動的に設定します。
A PATCH request, regardless of the number of operations, SHALL be treated as atomic. If a single operation encounters an error condition, the original SCIM resource MUST be restored, and a failure status SHALL be returned.
PATCHリクエストは、操作の数に関係なく、アトミックとして扱われる必要があります。単一の操作でエラー条件が発生した場合は、元のSCIMリソースを復元する必要があり、失敗ステータスを返す必要があります（SHALL）。
If a request fails, the server SHALL return an HTTP response status code and a JSON detail error response as defined in Section 3.12.
リクエストが失敗した場合、サーバーは、セクション3.12で定義されているHTTPレスポンスステータスコードとJSON詳細エラーレスポンスを返す必要があります（SHALL）。
On successful completion, the server either MUST return a 200 OK response code and the entire resource within the response body, subject to the "attributes" query parameter (see Section 3.9), or MAY return HTTP status code 204 (No Content) and the appropriate response headers for a successful PATCH request. The server MUST return a 200 OK if the "attributes" parameter is specified in the request.
正常に完了すると、サーバーは200 OK応答コードと応答本文内のリソース全体を返し、「属性」クエリパラメータ（3.9節を参照）に従う必要があります。または、HTTPステータスコード204（コンテンツなし）とPATCHリクエストを成功させるための適切な応答ヘッダー。リクエストで「attributes」パラメータが指定されている場合、サーバーは200 OKを返す必要があります。
The "add" operation is used to add a new attribute value to an existing resource.
「追加」操作は、既存のリソースに新しい属性値を追加するために使用されます。
The operation MUST contain a "value" member whose content specifies the value to be added. The value MAY be a quoted value, or it may be a JSON object containing the sub-attributes of the complex attribute specified in the operation's "path".
操作には、追加する値を指定する内容の「値」メンバーを含める必要があります。値は引用符で囲まれた値である場合と、操作の「パス」で指定された複合属性のサブ属性を含むJSONオブジェクトである場合があります。
The result of the add operation depends upon what the target location indicated by "path" references:
追加操作の結果は、「パス」で示されるターゲットの場所が何を参照しているかによって異なります。
o If omitted, the target location is assumed to be the resource itself. The "value" parameter contains a set of attributes to be added to the resource.
o 省略した場合、ターゲットの場所はリソース自体と見なされます。 「value」パラメータには、リソースに追加される一連の属性が含まれています。
o If the target location does not exist, the attribute and value are added.
o ターゲットの場所が存在しない場合は、属性と値が追加されます。
o If the target location specifies a complex attribute, a set of sub-attributes SHALL be specified in the "value" parameter.
o ターゲットの場所で複雑な属性を指定する場合、一連のサブ属性を「値」パラメーターで指定する必要があります（SHALL）。
o If the target location specifies a multi-valued attribute, a new value is added to the attribute.
o ターゲットの場所で複数値の属性が指定されている場合、新しい値が属性に追加されます。
o If the target location specifies a single-valued attribute, the existing value is replaced.
o ターゲットの場所が単一値属性を指定する場合、既存の値が置き換えられます。
o If the target location specifies an attribute that does not exist (has no value), the attribute is added with the new value.
o ターゲットの場所に存在しない（値がない）属性が指定されている場合、その属性には新しい値が追加されます。
o If the target location exists, the value is replaced.
o ターゲットの場所が存在する場合、値は置き換えられます。
o If the target location already contains the value specified, no changes SHOULD be made to the resource, and a success response SHOULD be returned. Unless other operations change the resource, this operation SHALL NOT change the modify timestamp of the resource.
o ターゲットの場所に指定された値がすでに含まれている場合、リソースは変更されず（SHOULD）、成功の応答が返される必要があります（SHOULD）。他の操作がリソースを変更しない限り、この操作はリソースの変更タイムスタンプを変更してはなりません（SHALL NOT）。
The following example shows how to add a member to a group. Some text was removed for readability (indicated by "..."):
次の例は、グループにメンバーを追加する方法を示しています。一部のテキストは読みやすくするために削除されました（「...」で示されています）。
PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{ "schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[
{
"op":"add",
"path":"members",
"value":[
{
"display": "Babs Jensen",
"$ref":
"https://example.com/v2/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646"
}
]
}
]
}
If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:
HTTP/1.1 204 No Content
Authorization: Bearer h480djs93hd8
ETag: W/"b431af54f0671a2"
Location:
"https://example.com/Groups/acbf3ae7-8463-...-9b4da3f908ce"
The following example shows how to add one or more attributes to a User resource without using a "path" attribute.
次の例は、「パス」属性を使用せずに1つ以上の属性をユーザーリソースに追加する方法を示しています。
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"add",
"value":{
"emails":[
{
"value":"babs@jensen.org",
"type":"home"
}
],
"nickname":"Babs"
}]
}
In the above example, an additional value is added to the multi-valued attribute "emails". The second attribute, "nickname", is added to the User resource. If the resource already had an existing "nickname", the value is replaced per the processing rules above for single-valued attributes.
上記の例では、複数の値を持つ属性「emails」に追加の値が追加されています。 2番目の属性「ニックネーム」がユーザーリソースに追加されます。リソースにすでに「ニックネーム」が存在する場合、値は上記の単一値属性の処理ルールに従って置き換えられます。
The "remove" operation removes the value at the target location specified by the required attribute "path". The operation performs the following functions, depending on the target location specified by "path":
「remove」操作は、必須属性「path」で指定されたターゲットの場所の値を削除します。この操作は、「パス」で指定されたターゲットの場所に応じて、次の機能を実行します。
o If "path" is unspecified, the operation fails with HTTP status code 400 and a "scimType" error code of "noTarget".
o 「パス」が指定されていない場合、操作はHTTPステータスコード400と「scimType」エラーコード「noTarget」で失敗します。
o If the target location is a single-value attribute, the attribute and its associated value is removed, and the attribute SHALL be considered unassigned.
o ターゲットの場所が単一値属性の場合、属性とそれに関連付けられた値は削除され、属性は割り当てられていないものと見なされます。
o If the target location is a multi-valued attribute and no filter is specified, the attribute and all values are removed, and the attribute SHALL be considered unassigned.
o ターゲットの場所が複数値の属性であり、フィルターが指定されていない場合、属性とすべての値が削除され、属性は割り当てられていないと見なされます（SHALL）。
o If the target location is a multi-valued attribute and a complex filter is specified comparing a "value", the values matched by the filter are removed. If no other values remain after removal of the selected values, the multi-valued attribute SHALL be considered unassigned.
o ターゲットの場所が複数値の属性であり、「値」を比較する複雑なフィルターが指定されている場合、フィルターで一致した値は削除されます。選択した値を削除した後、他の値が残っていない場合、複数値の属性は割り当てられていないと見なされるものとします（SHALL）。
o If the target location is a complex multi-valued attribute and a complex filter is specified based on the attribute's sub-attributes, the matching records are removed. Sub-attributes whose values have been removed SHALL be considered unassigned. If the complex multi-valued attribute has no remaining records, the attribute SHALL be considered unassigned.
o ターゲットの場所が複雑な多値属性であり、その属性のサブ属性に基づいて複雑なフィルターが指定されている場合、一致するレコードが削除されます。値が削除されたサブ属性は、割り当てられていないものと見なされます。複合多値属性にレコードが残っていない場合、属性は割り当てられていないものと見なされます。
If an attribute is removed or becomes unassigned and is defined as a required attribute or a read-only attribute, the server SHALL return an HTTP response status code and a JSON detail error response as defined in Section 3.12, with a "scimType" error code of "mutability".
属性が削除されるか、割り当てが解除され、必須属性または読み取り専用属性として定義されている場合、サーバーは、セクション3.12で定義されているHTTP応答ステータスコードとJSON詳細エラー応答を、「scimType」エラーコードとともに返す必要があります（SHALL）。 「可変性」の。
The following example shows how to remove a member from a group. As with the previous example, the "display" sub-attribute is optional. If the user was not a member of this group, no changes should be made to the resource, and a success response should be returned.
次の例は、グループからメンバーを削除する方法を示しています。前の例と同様に、「display」サブ属性はオプションです。ユーザーがこのグループのメンバーでない場合は、リソースに変更を加えず、成功の応答を返す必要があります。
Note that server responses have been omitted for the rest of the PATCH examples.
残りのPATCHの例では、サーバーの応答が省略されていることに注意してください。
Remove a single member from a group. Some text was removed for readability (indicated by "..."):
グループから単一のメンバーを削除します。一部のテキストは読みやすくするために削除されました（「...」で示されています）。
PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"remove",
"path":"members[value eq \"2819c223-7f76-...413861904646\"]"
}]
}
Remove all members of a group:
グループのすべてのメンバーを削除します。
PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{ "schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"remove","path":"members"
}]
}
Removal of a value from a complex multi-valued attribute (request headers removed for brevity):
複雑な多値属性からの値の削除（簡潔にするためにリクエストヘッダーを削除）：
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"remove",
"path":"emails[type eq \"work\" and value ew \"example.com\"]"
}]
}
Example request to remove and add a member. Some text was removed
for readability (indicated by "..."):
PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{ "schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op":"remove",
"path":
"members[value eq\"2819c223...919d-413861904646\"]"
},
{
"op":"add",
"path":"members",
"value": [
{
"display": "James Smith",
"$ref":
"https://example.com/v2/Users/08e1d05d...473d93df9210",
"value": "08e1d05d...473d93df9210"
}
]
}
]
}
The following example shows how to replace all of the members of a
group with a different members list. Some text was removed for
readability (indicated by "..."):
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op":"remove","path":"members"
},
{
"op":"add",
"path":"members",
"value":[
{
"display": "Babs Jensen",
"$ref":
"https://example.com/v2/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646"
},
{
"display": "James Smith",
"$ref":
"https://example.com/v2/Users/08e1d05d...473d93df9210",
"value": "08e1d05d-121c-4561-8b96-473d93df9210"
}]
}
]
}
The "replace" operation replaces the value at the target location specified by the "path". The operation performs the following functions, depending on the target location specified by "path":
「replace」操作は、「path」で指定されたターゲットの場所の値を置き換えます。この操作は、「パス」で指定されたターゲットの場所に応じて、次の機能を実行します。
o If the "path" parameter is omitted, the target is assumed to be the resource itself. In this case, the "value" attribute SHALL contain a list of one or more attributes that are to be replaced.
o 「パス」パラメータを省略した場合、ターゲットはリソース自体であると見なされます。この場合、「値」属性には、置き換えられる1つ以上の属性のリストが含まれている必要があります（SHALL）。
o If the target location is a single-value attribute, the attributes value is replaced.
o ターゲットの場所が単一値属性の場合、属性値は置き換えられます。
o If the target location is a multi-valued attribute and no filter is specified, the attribute and all values are replaced.
o ターゲットの場所が複数値の属性であり、フィルターが指定されていない場合、属性とすべての値が置き換えられます。
o If the target location path specifies an attribute that does not exist, the service provider SHALL treat the operation as an "add".
o ターゲットの場所のパスが存在しない属性を指定している場合、サービスプロバイダーはその操作を「追加」として扱うものとします（SHALL）。
o If the target location specifies a complex attribute, a set of sub-attributes SHALL be specified in the "value" parameter, which replaces any existing values or adds where an attribute did not previously exist. Sub-attributes that are not specified in the "value" parameter are left unchanged.
o ターゲットの場所が複雑な属性を指定する場合、既存の値を置き換えるか、以前に属性が存在しなかった場所を追加する「値」パラメーターで一連のサブ属性を指定する必要があります（SHALL）。 「value」パラメーターで指定されていないサブ属性は変更されません。
o If the target location is a multi-valued attribute and a value selection ("valuePath") filter is specified that matches one or more values of the multi-valued attribute, then all matching record values SHALL be replaced.
o ターゲットの場所が複数値属性であり、複数値属性の1つ以上の値に一致する値選択（ "valuePath"）フィルターが指定されている場合、一致するすべてのレコード値が置き換えられる必要があります（SHALL）。
o If the target location is a complex multi-valued attribute with a value selection filter ("valuePath") and a specific sub-attribute (e.g., "addresses[type eq "work"].streetAddress"), the matching sub-attribute of all matching records is replaced.
o ターゲットの場所が、値選択フィルター（ "valuePath"）と特定のサブ属性（例： "addresses [type eq" work "]。streetAddress"）を持つ複雑な多値属性の場合、一致するサブ属性一致するすべてのレコードが置き換えられます。
o If the target location is a multi-valued attribute for which a value selection filter ("valuePath") has been supplied and no record match was made, the service provider SHALL indicate failure by returning HTTP status code 400 and a "scimType" error code of "noTarget".
o ターゲットの場所が、値選択フィルター（ "valuePath"）が指定された複数値の属性であり、レコードが一致しなかった場合、サービスプロバイダーは、HTTPステータスコード400と "scimType"エラーコードを返すことで失敗を示します（SHALL）。 「noTarget」の。
The following example shows how to replace all of the members of a group with a different members list in a single replace operation. Some text was removed for readability (indicated by "..."):
次の例は、単一の置換操作でグループのすべてのメンバーを別のメンバーリストに置き換える方法を示しています。一部のテキストは読みやすくするために削除されました（「...」で示されています）。
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"replace",
"path":"members",
"value":[
{
"display": "Babs Jensen",
"$ref":
"https://example.com/v2/Users/2819c223...413861904646",
"value": "2819c223...413861904646"
},
{
"display": "James Smith",
"$ref":
"https://example.com/v2/Users/08e1d05d...473d93df9210",
"value": "08e1d05d...473d93df9210"
}
]
}]
}
The following example shows how to change a User's entire "work"
address, using a "valuePath" filter. Note that by setting "primary"
to "true", the service provider will reset "primary" to "false" for
any other existing values of "addresses".
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"replace",
"path":"addresses[type eq \"work\"]",
"value":
{
"type": "work",
"streetAddress": "911 Universal City Plaza",
"locality": "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": "US",
"formatted":
"911 Universal City Plaza\nHollywood, CA 91608 US",
"primary": true
}
}]
}
The following example shows how to change a specific sub-attribute
"streetAddress" of complex attribute "emails" selected by a
"valuePath" filter:
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"replace",
"path":"addresses[type eq \"work\"].streetAddress",
"value":"1010 Broadway Ave"
}]
}
The following example shows how to replace all values of one or more
specific attributes of a User resource. Note that other attributes
are unaffected.
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"replace",
"value":{
"emails":[
{
"value":"bjensen@example.com",
"type":"work",
"primary":true
},
{
"value":"babs@jensen.org",
"type":"home"
}
],
"nickname":"Babs"
}]
}
Clients request resource removal via DELETE. Service providers MAY choose not to permanently delete the resource but MUST return a 404 (Not Found) error code for all operations associated with the previously deleted resource. Service providers MUST omit the resource from future query results. In addition, the service provider SHOULD NOT consider the deleted resource in conflict calculation. For example, if a User resource is deleted, a CREATE request for a User resource with the same userName as the previously deleted resource SHOULD NOT fail with a 409 error due to userName conflict.
クライアントは、DELETEによるリソースの削除を要求します。サービスプロバイダーは、リソースを完全に削除しないことを選択してもかまいませんが、以前に削除されたリソースに関連付けられたすべての操作に対して404（Not Found）エラーコードを返す必要があります。サービスプロバイダーは、今後のクエリ結果からリソースを省略しなければなりません。さらに、サービスプロバイダーは、削除されたリソースを競合計算で考慮すべきではありません（SHOULD NOT）。たとえば、ユーザーリソースが削除された場合、以前に削除されたリソースと同じuserNameを持つユーザーリソースに対するCREATEリクエストは、userNameの競合が原因で409エラーで失敗する必要があります（SHOULD NOT）。
DELETE /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8
If-Match: W/"c310cd84f0281b7"
In response to a successful DELETE, the server SHALL return a successful HTTP status code 204 (No Content). A non-normative example response:
DELETEの成功に応答して、サーバーは成功したHTTPステータスコード204（コンテンツなし）を返す必要があります（SHALL）。非規範的な応答例：
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
Example: Client's attempt to retrieve the previously deleted User
例：クライアントが以前に削除されたユーザーを取得しようとする
GET /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Authorization: Bearer h480djs93hd8
GET / Users / 2819c223-7f76-453a-919d-413861904646ホスト：example.com承認：ベアラーh480djs93hd8
Server response:
サーバーの応答：
HTTP/1.1 404 Not Found
HTTP / 1.1 404が見つかりません
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"status": "404"
}
The SCIM bulk operation is an optional server feature that enables clients to send a potentially large collection of resource operations in a single request. Support for bulk requests can be discovered by querying the service provider configuration (see Section 4). The body of a bulk operation contains a set of HTTP resource operations using one of the HTTP methods supported by the API, i.e., POST, PUT, PATCH, or DELETE.
SCIMバルク操作は、クライアントが単一の要求でリソース操作の潜在的に大きなコレクションを送信できるようにするオプションのサーバー機能です。バルクリクエストのサポートは、サービスプロバイダーの設定を照会することで検出できます（セクション4を参照）。一括操作の本体には、APIでサポートされているHTTPメソッドの1つを使用する一連のHTTPリソース操作、つまりPOST、PUT、PATCH、またはDELETEが含まれています。
Bulk requests are identified using the following schema URI: "urn:ietf:params:scim:api:messages:2.0:BulkRequest". Bulk responses are identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:BulkResponse". Bulk requests and bulk responses share many attributes. Unless otherwise specified, each attribute below is present in both bulk requests and bulk responses.
一括リクエストは、次のスキーマURIを使用して識別されます：「urn：ietf：params：scim：api：messages：2.0：BulkRequest」。バルク応答は、次のURIを使用して識別されます：「urn：ietf：params：scim：api：messages：2.0：BulkResponse」。バルクリクエストとバルクレスポンスは、多くの属性を共有しています。特に明記されていない限り、以下の各属性は、バルクリクエストとバルクレスポンスの両方に存在します。
The following singular attribute is defined, in addition to the common attributes defined in [RFC7643].
[RFC7643]で定義されている共通の属性に加えて、次の特異な属性が定義されています。
failOnErrors An integer specifying the number of errors that the service provider will accept before the operation is terminated and an error response is returned. OPTIONAL in a request. Not valid in a response.
failOnErrors操作が終了してエラー応答が返されるまでにサービスプロバイダーが受け入れるエラーの数を指定する整数。リクエストではオプションです。応答では無効です。
The following complex multi-valued attribute is defined, in addition to the common attributes defined in [RFC7643].
[RFC7643]で定義されている共通の属性に加えて、次の複雑な多値属性が定義されています。
Operations Defines operations within a bulk job. Each operation corresponds to a single HTTP request against a resource endpoint. REQUIRED. The Operations attribute has the following sub-attributes:
操作一括ジョブ内の操作を定義します。各操作は、リソースエンドポイントに対する単一のHTTPリクエストに対応しています。必須。 Operations属性には、次のサブ属性があります。
method The HTTP method of the current operation. Possible values are "POST", "PUT", "PATCH", or "DELETE". REQUIRED.
method現在の操作のHTTPメソッド。可能な値は、「POST」、「PUT」、「PATCH」、または「DELETE」です。必須。
bulkId The transient identifier of a newly created resource, unique within a bulk request and created by the client. The bulkId serves as a surrogate resource id enabling clients to uniquely identify newly created resources in the response and cross-reference new resources in and across operations within a bulk request. REQUIRED when "method" is "POST".
bulkId新しく作成されたリソースの一時的な識別子。一括リクエスト内で一意であり、クライアントによって作成されます。 bulkIdは代理リソースIDとして機能し、クライアントが応答で新しく作成されたリソースを一意に識別し、バルクリクエスト内のオペレーション内およびオペレーション間で新しいリソースを相互参照できるようにします。 「メソッド」が「POST」の場合は必須です。
version The current resource version. Version MAY be used if the service provider supports entity-tags (ETags) (Section 2.3 of [RFC7232]) and "method" is "PUT", "PATCH", or "DELETE".
version現在のリソースバージョン。サービスプロバイダーがエンティティタグ（ETag）（[RFC7232]のセクション2.3）をサポートし、「メソッド」が「PUT」、「PATCH」、または「DELETE」である場合、バージョンを使用できます。
path The resource's relative path to the SCIM service provider's root. If "method" is "POST", the value must specify a resource type endpoint, e.g., /Users or /Groups, whereas all other "method" values must specify the path to a specific resource, e.g., /Users/2819c223-7f76-453a-919d-413861904646. REQUIRED in a request.
path SCIMサービスプロバイダーのルートへのリソースの相対パス。 「メソッド」が「POST」の場合、値は/ Usersまたは/ Groupsなどのリソースタイプエンドポイントを指定する必要がありますが、他のすべての「メソッド」値は/ Users / 2819c223-7f76などの特定のリソースへのパスを指定する必要があります-453a-919d-413861904646。リクエストで必須。
data The resource data as it would appear for a single SCIM POST, PUT, or PATCH operation. REQUIRED in a request when "method" is "POST", "PUT", or "PATCH".
data単一のSCIM POST、PUT、またはPATCH操作で表示されるリソースデータ。 「メソッド」が「POST」、「PUT」、または「PATCH」の場合、リクエストで必須です。
location The resource endpoint URL. REQUIRED in a response, except in the event of a POST failure.
locationリソースのエンドポイントURL。 POST障害が発生した場合を除き、応答で必須。
response The HTTP response body for the specified request operation. When indicating a response with an HTTP status other than a 200-series response, the response body MUST be included. For normal completion, the server MAY elect to omit the response body.
response指定された要求操作のHTTP応答本文。 200シリーズの応答以外のHTTPステータスの応答を示す場合、応答本文を含める必要があります。通常の完了の場合、サーバーは応答本文を省略することを選択できます。
status The HTTP response status code for the requested operation. When indicating an error, the "response" attribute MUST contain the detail error response as per Section 3.12.
status要求された操作のHTTP応答ステータスコード。エラーを示す場合、「response」属性にはセクション3.12の詳細なエラー応答を含める必要があります。
If a bulk job is processed successfully, HTTP response code 200 OK MUST be returned; otherwise, an appropriate HTTP error code MUST be returned.
一括ジョブが正常に処理された場合、HTTP応答コード200 OKを返す必要があります。それ以外の場合は、適切なHTTPエラーコードを返す必要があります。
The service provider MUST continue performing as many changes as possible and disregard partial failures. The client MAY override this behavior by specifying a value for the "failOnErrors" attribute. The "failOnErrors" attribute defines the number of errors that the service provider should accept before failing the remaining operations returning the response.
サービスプロバイダーは、可能な限り多くの変更を実行し続け、部分的な失敗を無視する必要があります。クライアントは、 "failOnErrors"属性の値を指定することにより、この動作をオーバーライドできます（MAY）。 「failOnErrors」属性は、応答を返す残りの操作が失敗するまでにサービスプロバイダーが受け入れる必要のあるエラーの数を定義します。
To be able to reference a newly created resource, the bulkId attribute MAY be specified when creating new resources. The "bulkId" is defined by the client as a surrogate identifier in a POST operation (see Section 3.7.2). The service provider MUST return the same "bulkId" together with the newly created resource. The "bulkId" can then be used by the client to map the service provider id with the "bulkId" of the created resource.
新しく作成されたリソースを参照できるようにするには、新しいリソースを作成するときにbulkId属性を指定する必要があります。 「bulkId」は、POST操作の代理識別子としてクライアントによって定義されます（セクション3.7.2を参照）。サービスプロバイダーは、新しく作成されたリソースと同じ「bulkId」を返す必要があります。その後、クライアントは「bulkId」を使用して、サービスプロバイダーIDを、作成されたリソースの「bulkId」にマップできます。
A SCIM service provider MAY elect to optimize the sequence of operations received (e.g., to improve processing performance). When doing so, the service provider MUST ensure that the client's intent is preserved and the same stateful result is achieved as for non-optimized processing. For example, before a "User" can be added to a "Group", they must first be created. Processing these requests out of order might result in a failure to add the new "User" to the "Group".
SCIMサービスプロバイダーは、受信した操作のシーケンスを最適化することを選択できます（たとえば、処理パフォーマンスを改善するため）。その場合、サービスプロバイダーは、クライアントの意図が保持され、最適化されていない処理と同じステートフルな結果が確実に得られるようにする必要があります。たとえば、「ユーザー」を「グループ」に追加する前に、まずそれらを作成する必要があります。これらのリクエストを順不同で処理すると、新しい「ユーザー」を「グループ」に追加できない可能性があります。
The service provider MUST try to resolve circular cross-references between resources in a single bulk job but MAY stop after a failed attempt and instead return HTTP status code 409 (Conflict). The following example exhibits the potential conflict.
サービスプロバイダーは、単一の一括ジョブでリソース間の循環相互参照を解決する必要がありますが、失敗した試行の後で停止して、代わりにHTTPステータスコード409（競合）を返す場合があります。次の例は、潜在的な競合を示しています。
POST /v2/Bulk Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / v2 / Bulk Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
"Operations": [
{
"method": "POST",
"path": "/Groups",
"bulkId": "qwerty",
"data": {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Group A",
"members": [
{
"type": "Group",
"value": "bulkId:ytrewq"
}
]
}
},
{
"method": "POST",
"path": "/Groups",
"bulkId": "ytrewq",
"data": {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Group B",
"members": [
{
"type": "Group",
"value": "bulkId:qwerty"
}
]
}
}
]
}
If the service provider resolved the above circular references, the following is returned from a subsequent GET request.
サービスプロバイダーが上記の循環参照を解決した場合、後続のGET要求から次が返されます。
GET /v2/Groups?filter=displayName sw 'Group'
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults": 2,
"Resources": [
{
"id": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Group A",
"meta": {
"resourceType": "Group",
"created": "2011-08-01T18:29:49.793Z",
"lastModified": "2011-08-01T18:29:51.135Z",
"location":
"https://example.com/v2/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"version": "W\/\"mvwNGaxB5SDq074p\""
},
"members": [
{
"value": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
"$ref":
"https://example.com/v2/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3",
"type": "Group"
}
]
},
{
"id": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Group B",
"meta": {
"resourceType": "Group",
"created": "2011-08-01T18:29:50.873Z",
"lastModified": "2011-08-01T18:29:50.873Z",
"location":
"https://example.com/v2/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3",
"version": "W\/\"wGB85s2QJMjiNnuI\""
},
"members": [
{
"value": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"$ref":
"https://example.com/v2/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"type": "Group"
}
]
}
]
}
A SCIM client can, within one bulk operation, create a new "User", create a new "Group", and add the newly created "User" to the newly created "Group". In order to add the new "User" to the "Group", the client must use the surrogate id attribute, "bulkId", to reference the User. The "bulkId" attribute value must be prepended with the literal "bulkId:"; e.g., if the bulkId is 'qwerty', the value is "bulkId:qwerty". The service provider MUST replace the string "bulkId:qwerty" with the permanent resource id once created.
SCIMクライアントは、1回の一括操作で、新しい「ユーザー」を作成し、新しい「グループ」を作成し、新しく作成した「ユーザー」を新しく作成した「グループ」に追加できます。新しい「ユーザー」を「グループ」に追加するには、クライアントが代理ID属性「bulkId」を使用してユーザーを参照する必要があります。 「bulkId」属性値の前には、リテラル「bulkId：」を付ける必要があります。たとえば、bulkIdが「qwerty」の場合、値は「bulkId：qwerty」です。サービスプロバイダーは、文字列「bulkId：qwerty」を、一度作成された永続的なリソースIDに置き換える必要があります。
To create multiple distinct requests, each with their own "bulkId", the SCIM client specifies different "bulkId" values for each separate request.
それぞれが独自の「bulkId」を持つ複数の異なるリクエストを作成するために、SCIMクライアントは、個別のリクエストごとに異なる「bulkId」値を指定します。
The following example creates a User with the "userName" 'Alice' and a "Group" with "displayName", with a value of "Tour Guides" with Alice as a member. Notice that each operation has its own "bulkId" value. However, the second operation (whose "bulkId" is "ytrewq") refers to the "bulkId" of "qwerty" in order to add Alice to the new 'Tour Guides' group.
次の例では、「userName」が「Alice」で、「group」が「displayName」で、Userが「Tour Guides」で、Aliceがメンバーです。各操作には独自の「bulkId」値があることに注意してください。ただし、2番目の操作（「bulkId」が「ytrewq」）は、アリスを新しい「ツアーガイド」グループに追加するために、「qwerty」の「bulkId」を参照します。
POST /v2/Bulk Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / v2 / Bulk Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
"Operations": [
{
"method": "POST",
"path": "/Users",
"bulkId": "qwerty",
"data": {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "Alice"
}
},
{
"method": "POST",
"path": "/Groups",
"bulkId": "ytrewq",
"data": {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Tour Guides",
"members": [
{
"type": "User",
"value": "bulkId:qwerty"
}
]
}
}
]
}
The service provider returns the following response:
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"location":
"https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
"method": "POST",
"bulkId": "qwerty",
"version": "W\/\"4weymrEsh5O6cAEK\"",
"status": {
"code": "201"
}
},
{
"location":
"https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
"method": "POST",
"bulkId": "ytrewq",
"version": "W\/\"lha5bbazU3fNvfe5\"",
"status": {
"code": "201"
}
}
]
}
In the above example, the "Alice" User resource has an "id" of "92b725cd-9465-4e7d-8c16-01f8e146b87a" and the 'Tour Guides' Group has an "id" of "e9e30dba-f08f-4109-8486-d5c6a331660a".
上記の例では、「Alice」ユーザーリソースの「id」は「92b725cd-9465-4e7d-8c16-01f8e146b87a」で、「ツアーガイド」グループの「id」は「e9e30dba-f08f-4109-8486-」です。 d5c6a331660a」。
A subsequent GET request for the 'Tour Guides' Group (with an "id" of "e9e30dba-f08f-4109-8486-d5c6a331660a") returns the following, with Alice's "id" as the value for the member in the Group 'Tour Guides':
「Tour Guides」グループ（「id」が「e9e30dba-f08f-4109-8486-d5c6a331660a」）に対する後続のGETリクエストは、アリスの「id」をグループ「ツアー」のメンバーの値として、以下を返します。ガイド '：
HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a
ETag: W/"lha5bbazU3fNvfe5"
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "e9e30dba-f08f-4109-8486-d5c6a331660a",
"displayName": "Tour Guides",
"meta": {
"resourceType": "Group",
"created": "2011-08-01T18:29:49.793Z",
"lastModified": "2011-08-01T20:31:02.315Z",
"location":
"https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
"version": "W\/\"lha5bbazU3fNvfe5\""
},
"members": [
{
"value": "92b725cd-9465-4e7d-8c16-01f8e146b87a",
"$ref":
"https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
"type": "User"
}
]
}
Extensions that include references to other resources MUST be handled
in the same way by the service provider. The following example uses
the bulkId attribute within the enterprise extension managerId
attribute.
POST /v2/Bulk Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / v2 / Bulk Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
"Operations": [
{
"method": "POST",
"path": "/Users",
"bulkId": "qwerty",
"data": {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "Alice"
}
},
{
"method": "POST",
"path": "/Users",
"bulkId": "ytrewq",
"data": {
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"userName": "Bob",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "11250",
"manager": {
"value": "bulkId:qwerty"
}
}
}
}
]
}
The service provider response MUST include the result of all processed operations. A "location" attribute that includes the resource's endpoint MUST be returned for all operations except for failed POST operations (which have no location). The status attribute includes information about the success or failure of one operation within the bulk job. The status attribute MUST include the code attribute that holds the HTTP response code that would have been returned if a single HTTP request would have been used. If an error occurred, the status MUST also include the description attribute containing a human-readable explanation of the error.
サービスプロバイダーの応答には、処理されたすべての操作の結果を含める必要があります。リソースのエンドポイントを含む「場所」属性は、失敗したPOST操作（場所がない）を除くすべての操作で返される必要があります。ステータス属性には、一括ジョブ内の1つの操作の成功または失敗に関する情報が含まれます。ステータス属性には、単一のHTTPリクエストが使用された場合に返されるHTTP応答コードを保持するコード属性を含める必要があります。エラーが発生した場合、ステータスには、人間が読み取れるエラーの説明を含むdescription属性も含める必要があります。
"status": "201"
The following is an example of a status in a failed operation.
失敗した操作の状態の例を次に示します。
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
The following example shows how to add, update, and remove a user.
The "failOnErrors" attribute is set to '1', indicating that the
service provider will stop processing and return results after one
error. The POST operation's bulkId value is set to 'qwerty',
enabling the client to match the new User with the returned
resource "id" of
"92b725cd-9465-4e7d-8c16-01f8e146b87a".
POST /v2/Bulk Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / v2 / Bulk Host：example.com Accept：application / scim + json Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
"failOnErrors":1,
"Operations":[
{
"method":"POST",
"path":"/Users",
"bulkId":"qwerty",
"data":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
"userName":"Alice"
}
},
{
"method":"PUT",
"path":"/Users/b7c14771-226c-4d05-8860-134711653041",
"version":"W\/\"3694e05e9dff591\"",
"data":{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"b7c14771-226c-4d05-8860-134711653041",
"userName":"Bob"
}
},
{
"method": "PATCH",
"path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"version": "W/\"edac3253e2c0ef2\"",
"data": {[
{
"op": "remove",
"path": "nickName"
},
{
"op": "add",
"path": "userName",
"value": "Dave"
}
]}
},
{
"method":"DELETE",
"path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
"version":"W\/\"0ee8add0a938e1a\""
}
]
}
The service provider returns the following response:
サービスプロバイダーは次の応答を返します。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"location":
"https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
"method": "POST",
"bulkId": "qwerty",
"version": "W\/\"oY4m4wn58tkVjJxK\"",
"status": "201"
},
{
"location":
"https://example.com/v2/Users/b7c14771-226c-4d05-8860-134711653041",
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
},
{
"location":
"https://example.com/v2/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"method": "PATCH",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
},
{
"location":
"https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
"method": "DELETE",
"status": "204"
}
]
}
The following response is returned if an error occurred when attempting to create the User 'Alice'. The service provider stops processing the bulk operation and immediately returns a response to the client. The response contains the error and any successful results prior to the error.
ユーザー「Alice」を作成しようとしたときにエラーが発生した場合、次の応答が返されます。サービスプロバイダーは一括操作の処理を停止し、すぐにクライアントに応答を返します。応答には、エラーと、エラーの前に成功した結果が含まれます。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"method": "POST",
"bulkId": "qwerty",
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
}
]
}
If the "failOnErrors" attribute is not specified or the service provider has not reached the error limit defined by the client, the service provider will continue to process all operations. The following is an example in which all operations failed.
「failOnErrors」属性が指定されていない場合、またはサービスプロバイダーがクライアントによって定義されたエラー制限に達していない場合、サービスプロバイダーは引き続きすべての操作を処理します。以下は、すべての操作が失敗した例です。
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"method": "POST",
"bulkId": "qwerty",
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
},
{
"location":
"https://example.com/v2/Users/b7c14771-226c-4d05-8860-134711653041",
"method": "PUT",
"status": "412",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Failed to update. Resource changed on the server.",
"status":"412"
}
},
{
"location":
"https://example.com/v2/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"method": "PATCH",
"status": "412",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Failed to update. Resource changed on the server.",
"status":"412"
}
},
{
"location":
"https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
"method": "DELETE",
"status": "404",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource does not exist.",
"status":"404"
}
}
]
}
The service provider MUST define the maximum number of operations and maximum payload size a client may send in a single request. These limits MAY be retrieved from the service provider configuration (see 'bulk' in Sections 5 and 8.5 of [RFC7643]). If either limit is exceeded, the service provider MUST return HTTP response code 413 (Payload Too Large). The returned response MUST specify the limit exceeded in the body of the error response.
サービスプロバイダーは、クライアントが単一のリクエストで送信できる操作の最大数と最大ペイロードサイズを定義する必要があります。これらの制限は、サービスプロバイダーの構成から取得できます（[RFC7643]のセクション5および8.5の「バルク」を参照）。いずれかの制限を超えた場合、サービスプロバイダーはHTTP応答コード413（ペイロードが大きすぎる）を返す必要があります。返された応答は、エラー応答の本文で超過した制限を指定する必要があります。
In the following example, the client sent a request exceeding the service provider's maximum payload size of 1 megabyte:
次の例では、クライアントがサービスプロバイダーの最大ペイロードサイズである1 MBを超えるリクエストを送信しました。
POST /v2/Bulk
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: 4294967296
...
。。。
The server sends the following error in response to the oversized request:
サーバーは、特大の要求に応答して次のエラーを送信します。
HTTP/1.1 413 Payload Too Large
Content-Type: application/scim+json
{
"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],
"status": "413",
"detail":
"The size of the bulk operation exceeds the maxPayloadSize (1048576)."
}
Servers MUST accept requests and be able to return JSON-structured responses using UTF-8 encoding [RFC3629]. UTF-8 SHALL be the default encoding format. Other media types MAY be supported by service providers but are beyond the scope of this specification.
サーバーはリクエストを受け入れ、UTF-8エンコーディング[RFC3629]を使用してJSON構造化された応答を返すことができる必要があります。 UTF-8がデフォルトのエンコーディング形式である必要があります。他のメディアタイプはサービスプロバイダーによってサポートされるかもしれませんが、この仕様の範囲を超えています。
Clients using other encodings MUST specify the format in which the data is submitted via an HTTP "Content-Type" header as specified in Section 3.1.1.5 of [RFC7231] and MAY specify the desired response data format via an HTTP "Accept" header (Section 5.3.2 of [RFC7231]), e.g., "Accept: application/scim+json", or via URI suffix:
他のエンコーディングを使用するクライアントは、[RFC7231]のセクション3.1.1.5で指定されているように、HTTP "Content-Type"ヘッダーを介してデータが送信される形式を指定する必要があり、HTTP "Accept"ヘッダーを介して目的の応答データ形式を指定する必要があります（MAY）。 [RFC7231]のセクション5.3.2）、たとえば、「Accept：application / scim + json」、またはURIサフィックスを介して：
GET /Users/2819c223-7f76-453a-919d-413861904646.scim Host: example.com
GET /Users/2819c223-7f76-453a-919d-413861904646.scimホスト：example.com
Service providers MUST support the "Accept" header "Accept: application/scim+json" and SHOULD support the header "Accept: application/json", both of which specify JSON documents conforming to [RFC7159]. The format defaults to "application/scim+json" if no format is specified.
サービスプロバイダーは「Accept」ヘッダー「Accept：application / scim + json」をサポートする必要があり、SHOULDはヘッダー「Accept：application / json」をサポートする必要があります。どちらも[RFC7159]に準拠するJSONドキュメントを指定します。フォーマットが指定されていない場合、フォーマットはデフォルトで「application / scim + json」になります。
Singular attributes are encoded as string name-value pairs in JSON, e.g.,
単数属性は、JSONで文字列の名前と値のペアとしてエンコードされます。たとえば、
"attribute": "value"
Multi-valued attributes in JSON are encoded as arrays, e.g.,
JSONの多値属性は配列としてエンコードされます。たとえば、
"attributes": [ "value1", "value2" ]
Elements with nested elements are represented as objects in JSON, e.g.,
ネストされた要素を持つ要素は、JSONではオブジェクトとして表されます。たとえば、
"attribute": { "subattribute1": "value1", "subattribute2": "value2" }
For any SCIM operation where a resource representation is returned (e.g., HTTP GET), the attributes returned are defined as the minimum attribute set plus default attribute set. The minimum set is composed of those attributes that have their "returned" characteristic set to "always" (see Section 2.2 of [RFC7643]). The default attribute set is composed of those attributes that have the "returned" characteristic set to "default".
リソース表現が返されるSCIM操作（HTTP GETなど）の場合、返される属性は、最小属性セットとデフォルト属性セットとして定義されます。最小セットは、「返される」特性が「常に」に設定されている属性で構成されます（[RFC7643]のセクション2.2を参照）。デフォルトの属性セットは、「返される」特性が「デフォルト」に設定されている属性で構成されています。
Clients MAY request a partial resource representation on any operation that returns a resource within the response by specifying either of the mutually exclusive URL query parameters "attributes" or "excludedAttributes", as follows:
クライアントは、次のように相互に排他的なURLクエリパラメータ「attributes」または「excludedAttributes」のいずれかを指定することにより、応答内のリソースを返す操作の部分的なリソース表現を要求できます。
attributes When specified, the default list of attributes SHALL be overridden, and each resource returned MUST contain the minimum set of resource attributes and any attributes or sub-attributes explicitly requested by the "attributes" parameter. The query parameter attributes value is a comma-separated list of resource attribute names in standard attribute notation (Section 3.10) form (e.g., userName, name, emails).
attributes指定すると、デフォルトの属性リストがオーバーライドされ、返される各リソースには、最小セットのリソース属性と、「attributes」パラメーターによって明示的に要求された属性またはサブ属性が含まれている必要があります。クエリパラメータの属性値は、標準の属性表記（セクション3.10）形式（例：userName、name、emails）のリソース属性名のコンマ区切りリストです。
excludedAttributes When specified, each resource returned MUST contain the minimum set of resource attributes. Additionally, the default set of attributes minus those attributes listed in "excludedAttributes" is returned. The query parameter attributes value is a comma-separated list of resource attribute names in standard attribute notation (Section 3.10) form (e.g., userName, name, emails).
excludeAttributes指定した場合、返される各リソースには、最小限のリソース属性のセットが含まれている必要があります。さらに、デフォルトの属性セットから「excludedAttributes」にリストされている属性を引いたものが返されます。クエリパラメータの属性値は、標準の属性表記（セクション3.10）形式（例：userName、name、emails）のリソース属性名のコンマ区切りリストです。
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
The following response is returned:
次の応答が返されます。
HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"a330bc54f0671c9"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"userName":"bjensen"
}
All operations share a common scheme for referencing simple and complex attributes. In general, attributes are uniquely identified by prefixing the attribute name with its schema URN separated by a colon (":") character; e.g., the core User resource attribute 'userName' is identified as "urn:ietf:params:scim:schemas:core:2.0:User:userName". Clients MAY omit core schema attribute URN prefixes but SHOULD fully qualify extended attributes with the associated schema extension URN to avoid naming conflicts. For example, the attribute 'age' defined in "urn:ietf:params:scim:schemas:exampleCo:2.0:hr" is uniquely identified as "urn:ietf:params:scim:schemas:exampleCo:2.0:hr:age". Complex attributes' sub-attributes are referenced via nested dot ('.') notation, i.e., {urn}:{Attribute name}.{Sub-Attribute name}. For example, the fully qualified path for a User's givenName is "urn:ietf:params:scim:schemas:core:2.0:User:name.givenName". All facets (URN, attribute, and sub-attribute name) of the fully encoded attribute name are case insensitive.
すべての操作は、単純な属性と複雑な属性を参照するための共通のスキームを共有します。一般に、属性は、属性名の前にコロン（ "："）文字で区切られたスキーマURNを付けることで一意に識別されます。たとえば、コアユーザーリソース属性「userName」は「urn：ietf：params：scim：schemas：core：2.0：User：userName」として識別されます。クライアントはコアスキーマ属性のURNプレフィックスを省略してもかまいませんが、名前の競合を避けるために、関連するスキーマ拡張URNで拡張属性を完全に修飾する必要があります（SHOULD）。たとえば、「urn：ietf：params：scim：schemas：exampleCo：2.0：hr」で定義されている属性「age」は、「urn：ietf：params：scim：schemas：exampleCo：2.0：hr：age」として一意に識別されます。 。複合属性のサブ属性は、ネストされたドット（ '。'）表記を介して参照されます。つまり、{urn}：{属性名}。{サブ属性名}です。たとえば、ユーザーのgivenNameの完全修飾パスは、「urn：ietf：params：scim：schemas：core：2.0：User：name.givenName」です。完全にエンコードされた属性名のすべてのファセット（URN、属性、およびサブ属性名）では、大文字と小文字が区別されません。
A client MAY use a URL of the form "<base-URI>/Me" as a URI alias for the User or other resource associated with the currently authenticated subject for any SCIM operation. A service provider MAY respond in one of three ways:
クライアントは、「<base-URI> / Me」の形式のURLを、SCIM操作の現在認証されているサブジェクトに関連付けられているユーザーまたは他のリソースのURIエイリアスとして使用できます。サービスプロバイダーは、次の3つの方法のいずれかで応答できます。
o A service provider that does NOT support this feature SHOULD respond with HTTP status code 501 (Not Implemented).
o この機能をサポートしないサービスプロバイダーは、HTTPステータスコード501（未実装）で応答する必要があります（SHOULD）。
o A service provider MAY choose to redirect the client using HTTP status code 308 (Permanent Redirect) to the resource associated with the authenticated subject. The client MAY then repeat the request at the indicated location.
o サービスプロバイダーは、HTTPステータスコード308（Permanent Redirect）を使用して、認証されたサブジェクトに関連付けられているリソースにクライアントをリダイレクトすることを選択できます（MAY）。次に、クライアントは指定された場所でリクエストを繰り返すことができます。
o A service provider MAY process the SCIM request directly. In any response, the HTTP "Location" header MUST be the permanent location of the aliased resource associated with the authenticated subject.
o サービスプロバイダーは、SCIM要求を直接処理する場合があります。いかなる応答においても、HTTP "Location"ヘッダーは、認証されたサブジェクトに関連付けられたエイリアスリソースの永続的な場所である必要があります。
When using the SCIM Create Resource command (HTTP POST) with the "/Me" alias, the desired resourceType being created is at the discretion of the service provider, based on the authenticated subject (if not anonymous) making the request and any request body attributes (e.g., "schemas"). See Section 7.6 for information on security considerations related to this operation.
「/ Me」エイリアスでSCIM Create Resourceコマンド（HTTP POST）を使用する場合、作成される必要なresourceTypeは、要求を行う認証されたサブジェクト（匿名でない場合）と要求本文に基づいて、サービスプロバイダーの裁量にあります。属性（「スキーマ」など）。この操作に関連するセキュリティの考慮事項については、セクション7.6を参照してください。
The SCIM protocol uses the HTTP response status codes defined in Section 6 of [RFC7231] to indicate operation success or failure. In addition to returning an HTTP response code, implementers MUST return the errors in the body of the response in a JSON format, using the attributes described below. Error responses are identified using the following "schema" URI: "urn:ietf:params:scim:api:messages:2.0:Error". The following attributes are defined for a SCIM error response using a JSON body:
SCIMプロトコルは、[RFC7231]のセクション6で定義されたHTTP応答ステータスコードを使用して、操作の成功または失敗を示します。 HTTP応答コードを返すことに加えて、実装者は、以下で説明する属性を使用して、JSON形式で応答の本文にエラーを返す必要があります。エラー応答は、次の「スキーマ」URIを使用して識別されます：「urn：ietf：params：scim：api：messages：2.0：Error」。以下の属性は、JSON本文を使用したSCIMエラー応答に対して定義されています。
status The HTTP status code (see Section 6 of [RFC7231]) expressed as a JSON string. REQUIRED.
status JSON文字列として表現されるHTTPステータスコード（[RFC7231]のセクション6を参照）。必須。
scimType A SCIM detail error keyword. See Table 9. OPTIONAL.
scimType SCIM詳細エラーキーワード。表9を参照してください。
detail A detailed human-readable message. OPTIONAL.
人間が読める詳細なメッセージ。オプション。
Implementers SHOULD handle the identified HTTP status codes as described below.
実装者は、以下で説明するように、識別されたHTTPステータスコードを処理する必要があります（SHOULD）。
+----------------+---------------+----------------------------------+
| Status | Applicability | Suggested Explanation |
+----------------+---------------+----------------------------------+
| 307 (Temporary | GET, POST, | The client is directed to repeat |
| Redirect) | PUT, PATCH, | the same HTTP request at the |
| | DELETE | location identified. The client |
| | | SHOULD NOT use the location |
| | | provided in the response as a |
| | | permanent reference to the |
| | | resource and SHOULD continue to |
| | | use the original request URI |
| | | [RFC7231]. |
| | | |
| 308 (Permanent | GET, POST, | The client is directed to repeat |
| Redirect) | PUT, PATCH, | the same HTTP request at the |
| | DELETE | location identified. The client |
| | | SHOULD use the location provided |
| | | in the response as the permanent |
| | | reference to the resource |
| | | [RFC7538]. |
| | | |
| 400 (Bad | GET, POST, | Request is unparsable, |
| Request) | PUT, PATCH, | syntactically incorrect, or |
| | DELETE | violates schema. |
| | | |
| 401 | GET, POST, | Authorization failure. The |
| (Unauthorized) | PUT, PATCH, | authorization header is invalid |
| | DELETE | or missing. |
| | | |
| 403 | GET, POST, | Operation is not permitted based |
| (Forbidden) | PUT, PATCH, | on the supplied authorization. |
| | DELETE | |
| | | |
| 404 (Not | GET, POST, | Specified resource (e.g., User) |
| Found) | PUT, PATCH, | or endpoint does not exist. |
| | DELETE | |
| | | |
| 409 (Conflict) | POST, PUT, | The specified version number |
| | PATCH, DELETE | does not match the resource's |
| | | latest version number, or a |
| | | service provider refused to |
| | | create a new, duplicate |
| | | resource. |
| | | |
| 412 | PUT, PATCH, | Failed to update. Resource has |
| (Precondition | DELETE | changed on the server. |
| Failed) | | |
| | | |
| 413 (Payload | POST | {"maxOperations": |
| Too Large) | | 1000,"maxPayloadSize": 1048576} |
| | | |
| 500 (Internal | GET, POST, | An internal error. Implementers |
| Server Error) | PUT, PATCH, | SHOULD provide descriptive |
| | DELETE | debugging advice. |
| | | |
| 501 (Not | GET, POST, | Service provider does not |
| Implemented) | PUT, PATCH, | support the request operation, |
| | DELETE | e.g., PATCH. |
+----------------+---------------+----------------------------------+
Table 8: SCIM HTTP Status Code Usage
表8：SCIM HTTPステータスコードの使用
For HTTP status code 400 (Bad Request) responses, the following detail error types are defined:
HTTPステータスコード400（Bad Request）応答の場合、次の詳細なエラータイプが定義されています。
+---------------+--------------------------------+------------------+
| scimType | Description | Applicability |
+---------------+--------------------------------+------------------+
| invalidFilter | The specified filter syntax | GET (Section |
| | was invalid (does not comply | 3.4.2), POST |
| | with Figure 1), or the | (Search - |
| | specified attribute and filter | Section 3.4.3), |
| | comparison combination is not | PATCH (Path |
| | supported. | Filter - Section |
| | | 3.5.2) |
| | | |
| tooMany | The specified filter yields | GET (Section |
| | many more results than the | 3.4.2), POST |
| | server is willing to calculate | (Search - |
| | or process. For example, a | Section 3.4.3) |
| | filter such as "(userName pr)" | |
| | by itself would return all | |
| | entries with a "userName" and | |
| | MAY not be acceptable to the | |
| | service provider. | |
| | | |
| uniqueness | One or more of the attribute | POST (Create - |
| | values are already in use or | Section 3.3), |
| | are reserved. | PUT (Section |
| | | 3.5.1), PATCH |
| | | (Section 3.5.2) |
| | | |
| mutability | The attempted modification is | PUT (Section |
| | not compatible with the target | 3.5.1), PATCH |
| | attribute's mutability or | (Section 3.5.2) |
| | current state (e.g., | |
| | modification of an "immutable" | |
| | attribute with an existing | |
| | value). | |
| | | |
| invalidSyntax | The request body message | POST (Search - |
| | structure was invalid or did | Section 3.4.3, |
| | not conform to the request | Create - Section |
| | schema. | 3.3, Bulk - |
| | | Section 3.7), |
| | | PUT (Section |
| | | 3.5.1) |
| | | |
| invalidPath | The "path" attribute was | PATCH (Section |
| | invalid or malformed (see | 3.5.2) |
| | Figure 7). | |
| | | |
| noTarget | The specified "path" did not | PATCH (Section |
| | yield an attribute or | 3.5.2) |
| | attribute value that could be | |
| | operated on. This occurs when | |
| | the specified "path" value | |
| | contains a filter that yields | |
| | no match. | |
| | | |
| invalidValue | A required value was missing, | GET (Section |
| | or the value specified was not | 3.4.2), POST |
| | compatible with the operation | (Create - |
| | or attribute type (see Section | Section 3.3, |
| | 2.2 of [RFC7643]), or resource | Query - Section |
| | schema (see Section 4 of | 3.4.3), PUT |
| | [RFC7643]). | (Section 3.5.1), |
| | | PATCH (Section |
| | | 3.5.2) |
| | | |
| invalidVers | The specified SCIM protocol | GET (Section |
| | version is not supported (see | 3.4.2), POST |
| | Section 3.13). | (ALL), PUT |
| | | (Section 3.5.1), |
| | | PATCH (Section |
| | | 3.5.2), DELETE |
| | | (Section 3.6) |
| | | |
| sensitive | The specified request cannot | GET (Section |
| | be completed, due to the | 3.4.2) |
| | passing of sensitive (e.g., | |
| | personal) information in a | |
| | request URI. For example, | |
| | personal information SHALL NOT | |
| | be transmitted over request | |
| | URIs. See Section 7.5.2. | |
+---------------+--------------------------------+------------------+
Table 9: SCIM Detail Error Keyword Values
表9：SCIM詳細エラーキーワード値
Note that in Table 9 above, the information in the Applicability column applies to the normal HTTP method but MAY apply within a SCIM bulk operation (via HTTP POST).
上記の表9の「適用可能性」列の情報は通常のHTTPメソッドに適用されますが、SCIMバルク操作（HTTP POST経由）内に適用される場合があります。
Example of an error in response to a non-existent GET request:
存在しないGETリクエストへの応答のエラーの例：
HTTP/1.1 404 Not Found
HTTP / 1.1 404が見つかりません
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"status": "404"
}
Example of an error in response to a PUT request:
PUTリクエストへの応答のエラーの例：
HTTP/1.1 400 Bad Request
HTTP / 1.1 400不正リクエスト
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability"
"detail":"Attribute 'id' is readOnly",
"status": "400"
}
The Base URL MAY be appended with a version identifier as a separate segment in the URL path. At the time of this writing, the identifier is 'v2'. If specified, the version identifier MUST appear in the URL path immediately preceding the resource endpoint and conform to the following scheme: the character 'v' followed by the desired SCIM version number, e.g., a version 'v2' User request is specified as /v2/Users. When specified, service providers MUST perform the operation using the desired version or reject the request. When omitted, service providers SHOULD perform the operation using the most recent SCIM protocol version supported by the service provider.
ベースURLには、URLパスの個別のセグメントとしてバージョンIDが付加される場合があります。これを書いている時点では、識別子は「v2」です。指定する場合、バージョン識別子は、リソースエンドポイントの直前のURLパスに表示され、次のスキームに準拠する必要があります。文字「v」の後に目的のSCIMバージョン番号が続きます。たとえば、バージョン「v2」ユーザー要求は/ v2 / Users。指定した場合、サービスプロバイダーは目的のバージョンを使用して操作を実行するか、要求を拒否する必要があります。省略した場合、サービスプロバイダーは、サービスプロバイダーがサポートする最新のSCIMプロトコルバージョンを使用して操作を実行する必要があります（SHOULD）。
The SCIM protocol supports resource versioning via standard HTTP ETags (Section 2.3 of [RFC7232]). Service providers MAY support weak ETags as the preferred mechanism for performing conditional retrievals and ensuring that clients do not inadvertently overwrite each other's changes, respectively. When supported, SCIM ETags MUST be specified as an HTTP header and SHOULD be specified within the 'version' attribute contained in the resource's 'meta' attribute.
SCIMプロトコルは、標準のHTTP ETagを介したリソースのバージョン管理をサポートしています（[RFC7232]のセクション2.3）。サービスプロバイダーは、条件付き取得を実行し、クライアントがお互いの変更を誤って上書きしないようにするための推奨メカニズムとして、弱いETagをサポートする場合があります。サポートされている場合、SCIM ETagはHTTPヘッダーとして指定する必要があり、リソースの「メタ」属性に含まれる「バージョン」属性内で指定する必要があります（SHOULD）。
Example create request:
作成リクエストの例：
POST /Users HTTP/1.1 Host: example.com Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ...
POST / Users HTTP / 1.1 Host：example.com Content-Type：application / scim + json Authorization：Bearer h480djs93hd8 Content-Length：...
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"bjensen",
"externalId":"bjensen",
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
}
}
The server responds with an ETag in the response header and meta structure:
サーバーは、応答ヘッダーとメタ構造のETagで応答します。
HTTP/1.1 201 Created
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"meta":{
"resourceType":"User",
"created":"2011-08-01T21:32:44.882Z",
"lastModified":"2011-08-01T21:32:44.882Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"e180ee84f0671b1\""
},
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
},
"userName":"bjensen"
}
With the returned ETag, clients MAY choose to retrieve the resource
only if the resource has been modified.
An example of conditional retrieval, using the If-None-Match header (Section 3.2 of [RFC7232]):
If-None-Matchヘッダーを使用した条件付き取得の例（[RFC7232]のセクション3.2）：
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
If-None-Match: W/"e180ee84f0671b1"
If the resource has not changed, the service provider simply returns an empty body with a 304 (Not Modified) response code.
リソースが変更されていない場合、サービスプロバイダーは304（Not Modified）応答コードで空の本文を返すだけです。
If the service provider supports versioning of resources, the client MAY supply an If-Match header (Section 3.1 of [RFC7232]) for PUT and PATCH operations to ensure that the requested operation succeeds only if the supplied ETag matches the latest service provider resource, e.g., If-Match: W/"e180ee84f0671b1".
サービスプロバイダーがリソースのバージョニングをサポートしている場合、クライアントはPUTおよびPATCH操作のIf-Matchヘッダー（[RFC7232]のセクション3.1）を提供して、提供されたETagが最新のサービスプロバイダーリソースと一致する場合にのみリクエストされた操作が成功するようにします。例：If-Match：W / "e180ee84f0671b1"。
SCIM defines three endpoints to facilitate discovery of SCIM service provider features and schema that MAY be retrieved using HTTP GET:
SCIMは3つのエンドポイントを定義して、HTTP GETを使用して取得できるSCIMサービスプロバイダーの機能とスキーマの検出を容易にします。
/ServiceProviderConfig An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider. This endpoint SHALL return responses with a JSON object using a "schemas" attribute of "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". The attributes returned in the JSON object are defined in Section 5 of [RFC7643]. An example representation of SCIM service provider configuration may be found in Section 8.5 of [RFC7643].
/ ServiceProviderConfigこのエンドポイントへのHTTP GETは、サービスプロバイダーで利用可能なSCIM仕様機能を記述するJSON構造を返します。このエンドポイントは、「urn：ietf：params：scim：schemas：core：2.0：ServiceProviderConfig」の「schemas」属性を使用して、JSONオブジェクトで応答を返す必要があります。 JSONオブジェクトで返される属性は、[RFC7643]のセクション5で定義されています。 SCIMサービスプロバイダー構成の表現例は、[RFC7643]のセクション8.5にあります。
/Schemas An HTTP GET to this endpoint is used to retrieve information about resource schemas supported by a SCIM service provider. An HTTP GET to the endpoint "/Schemas" SHALL return all supported schemas in ListResponse format (see Figure 3). Individual schema definitions can be returned by appending the schema URI to the /Schemas endpoint. For example:
/ SchemasこのエンドポイントへのHTTP GETは、SCIMサービスプロバイダーがサポートするリソーススキーマに関する情報を取得するために使用されます。エンドポイント "/ Schemas"へのHTTP GETは、サポートされているすべてのスキーマをListResponse形式で返す必要があります（図3を参照）。 / SchemasエンドポイントにスキーマURIを追加すると、個々のスキーマ定義を返すことができます。例えば：
/Schemas/urn:ietf:params:scim:schemas:core:2.0:User
The contents of each schema returned are described in Section 7 of [RFC7643]. An example representation of SCIM schemas may be found in Section 8.7 of [RFC7643].
返される各スキーマの内容は、[RFC7643]のセクション7で説明されています。 SCIMスキーマの表現例は、[RFC7643]のセクション8.7にあります。
/ResourceTypes An HTTP GET to this endpoint is used to discover the types of resources available on a SCIM service provider (e.g., Users and Groups). Each resource type defines the endpoints, the core schema URI that defines the resource, and any supported schema extensions. The attributes defining a resource type can be found in Section 6 of [RFC7643], and an example representation can be found in Section 8.6 of [RFC7643].
/ ResourceTypesこのエンドポイントへのHTTP GETは、SCIMサービスプロバイダーで利用可能なリソースのタイプ（ユーザーやグループなど）を検出するために使用されます。各リソースタイプは、エンドポイント、リソースを定義するコアスキーマURI、およびサポートされているスキーマ拡張を定義します。リソースタイプを定義する属性は[RFC7643]のセクション6にあり、表現例は[RFC7643]のセクション8.6にあります。
In cases where a request is for a specific "ResourceType" or "Schema", the single JSON object is returned in the same way that a single User or Group is retrieved, as per Section 3.4.1. When returning multiple ResourceTypes or Schemas, the message form described by the "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse) form SHALL be used as shown in Figure 3 and in Figure 9 below. Query parameters described in Section 3.4.2, such as filtering, sorting, and pagination, SHALL be ignored. If a "filter" is provided, the service provider SHOULD respond with HTTP status code 403 (Forbidden) to ensure that clients cannot incorrectly assume that any matching conditions specified in a filter are true.
リクエストが特定の "ResourceType"または "Schema"に対するものである場合、単一のJSONオブジェクトは、セクション3.4.1に従って単一のユーザーまたはグループが取得されるのと同じ方法で返されます。複数のResourceTypeまたはスキーマを返す場合、「urn：ietf：params：scim：api：messages：2.0：ListResponse」（ListResponse）フォームで記述されたメッセージフォームは、図3および以下の図9に示すように使用する必要があります。セクション3.4.2で説明されている、フィルタリング、並べ替え、ページ分割などのクエリパラメータは無視する必要があります。 「フィルター」が提供されている場合、サービスプロバイダーは、HTTPステータスコード403（禁止）で応答して、クライアントがフィルターで指定された一致条件が真であると誤って想定できないようにする必要があります（SHOULD）。
The following is a non-normative example of an HTTP GET to the /ResourceTypes endpoint:
以下は、/ ResourceTypesエンドポイントへのHTTP GETの非規範的な例です。
{
"totalResults":2,
"itemsPerPage":10,
"startIndex":1,
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id":"User",
"name":"User",
"endpoint": "/Users",
"description": "User Account",
"schema": "urn:ietf:params:scim:schemas:core:2.0:User",
"schemaExtensions": [{
"schema":
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
"required": true
}],
"meta": {
"location":"https://example.com/v2/ResourceTypes/User",
"resourceType": "ResourceType"
}
},
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id":"Group",
"name":"Group",
"endpoint": "/Groups",
"description": "Group",
"schema": "urn:ietf:params:scim:schemas:core:2.0:Group",
"meta": {
"location":"https://example.com/v2/ResourceTypes/Group",
"resourceType": "ResourceType"
}
}]
}
Figure 9: Example Resource Type JSON Representation
図9：リソースタイプのJSON表現の例
To increase the likelihood that the input and comparison of usernames and passwords will work in ways that make sense for typical users throughout the world, there are rules for preparing, enforcing, and comparing internationalized strings that represent usernames and passwords. Before comparing or evaluating the uniqueness of a "userName" or "password" attribute, service providers MUST use the preparation, enforcement, and comparison of internationalized strings (PRECIS) preparation and comparison rules described in Sections 3 and 4, respectively, of [RFC7613], which is based on the PRECIS framework specification [RFC7564]. See Section 3.4 of [RFC7613] for discussion on "Case Mapping vs. Case Preparation" regarding "userName" attributes.
ユーザー名とパスワードの入力と比較が世界中の一般的なユーザーにとって意味のある方法で機能する可能性を高めるために、ユーザー名とパスワードを表す国際化された文字列を準備、適用、比較するためのルールがあります。 「userName」または「password」属性の一意性を比較または評価する前に、サービスプロバイダーは、国際化文字列（PRECIS）の準備、適用、比較を使用する必要があります。 ]、これはPRECISフレームワーク仕様[RFC7564]に基づいています。 「userName」属性に関する「ケースマッピングとケースの準備」については、[RFC7613]のセクション3.4をご覧ください。
A single service provider may expose the SCIM protocol to multiple clients. Depending on the nature of the service, the clients may have authority to access and alter resources initially created by other clients. Alternatively, clients may expect to access disjoint sets of resources and may expect that their resources are inaccessible to other clients. These scenarios are called "multi-tenancy", where each client is understood to be or represent a "tenant" of the service provider. Clients may also be multi-tenanted.
単一のサービスプロバイダーが、SCIMプロトコルを複数のクライアントに公開する場合があります。サービスの性質によっては、クライアントは他のクライアントによって最初に作成されたリソースにアクセスして変更する権限を持っている場合があります。または、クライアントは、リソースのまとまりのないセットにアクセスすることを期待し、それらのリソースが他のクライアントにアクセスできないことを期待する場合があります。これらのシナリオは「マルチテナンシー」と呼ばれ、各クライアントはサービスプロバイダーの「テナント」であるか、それを表すと理解されています。クライアントはマルチテナントにすることもできます。
The following common cases may occur:
次の一般的なケースが発生する可能性があります。
1. All clients share all resources (no tenancy).
1. すべてのクライアントがすべてのリソースを共有します（テナンシーはありません）。
2. Each single client creates and accesses a private subset of resources (1 client:1 Tenant).
2. 各クライアントは、リソースのプライベートサブセットを作成してアクセスします（1クライアント：1テナント）。
3. Sets of clients share sets of resources (M clients:1 Tenant).
3. クライアントのセットはリソースのセットを共有します（Mクライアント：1テナント）。
4. One client can create and access several private subsets of resources (1 client:M Tenants).
4. 1つのクライアントは、リソースのプライベートサブセットをいくつか作成してアクセスできます（1クライアント：Mテナント）。
Service providers may implement any subset of the above cases.
サービスプロバイダーは、上記のケースのサブセットを実装できます。
Multi-tenancy is OPTIONAL. The SCIM protocol does not define a scheme for multi-tenancy.
マルチテナンシーはオプションです。 SCIMプロトコルは、マルチテナンシーのスキームを定義していません。
The SCIM protocol does not prescribe the mechanisms whereby clients and service providers interact for the following:
SCIMプロトコルは、クライアントとサービスプロバイダーが以下のために相互作用するメカニズムを規定していません。
o Registering or provisioning Tenants
o テナントの登録またはプロビジョニング
o Associating a subset of clients with a subset of the Tenants
o クライアントのサブセットをテナントのサブセットに関連付ける
o Indicating which tenant is associated with the data in a request or response, or indicating which Tenant is the subject of a query
o リクエストまたはレスポンスのデータに関連付けられているテナントを示す、またはどのテナントがクエリの対象であるかを示す
The service provider MAY use one of the authentication mechanisms discussed in Section 2 to determine the identity of the client and thus infer the associated Tenant.
サービスプロバイダーは、セクション2で説明した認証メカニズムの1つを使用してクライアントのIDを決定し、関連するテナントを推測できます。
For implementations where a client is associated with more than one Tenant, the service provider MAY use one of the three methods below for explicit specification of the Tenant.
クライアントが複数のテナントに関連付けられている実装の場合、サービスプロバイダーは、テナントを明示的に指定するために、以下の3つの方法のいずれかを使用できます（MAY）。
If any of these methods of allowing the client to explicitly specify the Tenant are employed, the service provider should ensure that access controls are in place to prevent or allow cross-tenant use cases.
クライアントが明示的にテナントを指定できるようにするこれらの方法のいずれかが採用されている場合、サービスプロバイダーは、クロステナントのユースケースを防止または許可するためにアクセス制御が整っていることを確認する必要があります。
The service provider should consider precedence in cases where a client may explicitly specify a Tenant while being implicitly associated with a different Tenant.
サービスプロバイダーは、クライアントが明示的にテナントを指定し、暗黙的に別のテナントに関連付けられている場合に、優先順位を考慮する必要があります。
In all of these methods, the {tenant_id} is a unique identifier for the Tenant as defined by the service provider.
これらすべてのメソッドで、{tenant_id}は、サービスプロバイダーによって定義されたテナントの一意の識別子です。
o A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/ Users".
o URLプレフィックス：「https://www.example.com/Tenants/{tenant_id}/v2/ Users」。
o A sub-domain: "https://{tenant_id}.example.com/v2/Groups".
o サブドメイン：「https：// {tenant_id} .example.com / v2 / Groups」。
o An HTTP header: The service provider may recognize a {tenant_id} provided by the client in an HTTP header as the indicator of the desired target Tenant.
o HTTPヘッダー：サービスプロバイダーは、HTTPヘッダーでクライアントから提供された{tenant_id}を、目的のターゲットテナントのインジケーターとして認識できます。
Considerations for a multi-tenant implementation:
マルチテナント実装に関する考慮事項：
o The service provider may choose to implement SCIM ids that are unique across all resources for all Tenants, but this is not required.
o サービスプロバイダーは、すべてのテナントのすべてのリソースにわたって一意のSCIM IDを実装することを選択できますが、これは必須ではありません。
o The externalId, defined by the client, is required to be unique ONLY within the resources associated with the associated Tenant.
o クライアントによって定義された外部IDは、関連するテナントに関連付けられたリソース内でのみ一意である必要があります。
The SCIM protocol layers on top of HTTP and is thus subject to the security considerations of HTTP (Section 9 of [RFC7230]) and its related specifications.
SCIMプロトコルレイヤーはHTTPの上にあり、HTTPのセキュリティに関する考慮事項（[RFC7230]のセクション9）とその関連仕様の影響を受けます。
As stated in Section 2.7.1 of [RFC7230], a SCIM client MUST NOT generate the "userinfo" (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message, as userinfo and its "@" delimiter are now disallowed in HTTP.
[RFC7230]のセクション2.7.1で述べられているように、SCIMクライアントは、「http」URI参照がメッセージとともに生成される場合、「userinfo」（つまり、ユーザー名とパスワード）コンポーネント（およびその「@」区切り文字）を生成してはなりません（MUST NOT）。 、userinfoとその "@"区切り文字がHTTPで許可されなくなったため。
SCIM resources (e.g., Users and Groups) contain sensitive information, including passwords. Therefore, SCIM clients and service providers MUST require the use of a transport-layer security mechanism when communicating with SCIM service providers. The SCIM service provider MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server identity check, per [RFC6125]. Implementation security considerations for TLS can be found in [RFC7525].
SCIMリソース（ユーザーやグループなど）には、パスワードなどの機密情報が含まれています。したがって、SCIMクライアントとサービスプロバイダーは、SCIMサービスプロバイダーと通信するときにトランスポート層セキュリティメカニズムの使用を要求する必要があります。 SCIMサービスプロバイダーはTLS 1.2 [RFC5246]をサポートする必要があり、セキュリティ要件を満たす追加のトランスポート層メカニズムをサポートする場合があります（MAY）。 TLSを使用する場合、クライアントは[RFC6125]に従ってTLS / SSLサーバーのアイデンティティチェックを実行する必要があります。 TLSの実装セキュリティに関する考慮事項は、[RFC7525]にあります。
When using authorization tokens such as those issued by OAuth 2.0 [RFC6749], implementers MUST take into account threats and countermeasures as documented in Section 8 of [RFC7521].
OAuth 2.0 [RFC6749]によって発行されたものなどの認証トークンを使用する場合、実装者は[RFC7521]のセクション8に記載されている脅威と対策を考慮する必要があります。
Since the possession of a bearer token or cookie MAY authorize the holder to potentially read, modify, or delete resources, bearer tokens and cookies MUST contain sufficient entropy to prevent a random guessing attack; for example, see Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819].
ベアラートークンまたはCookieを所有することで、所有者がリソースの読み取り、変更、または削除を行う可能性があるため、ベアラートークンとCookieには、ランダムな推測攻撃を防ぐための十分なエントロピーを含める必要があります。たとえば、[RFC6750]のセクション5.2と[RFC6819]のセクション5.1.4.2.2を参照してください。
As with all SCIM communications, bearer tokens and HTTP cookies MUST be exchanged using TLS.
すべてのSCIM通信と同様に、ベアラートークンとHTTP CookieはTLSを使用して交換する必要があります。
Bearer tokens MUST have a limited lifetime that can be determined directly or indirectly (e.g., by checking with a validation service) by the service provider. By expiring tokens, clients are forced to obtain a new token (which usually involves re-authentication) for continued authorized access. For example, in OAuth 2.0, a client MAY use OAuth token refresh to obtain a new bearer token after authenticating to an authorization server. See Section 6 of [RFC6749].
ベアラートークンは、サービスプロバイダーが直接または間接的に（たとえば、検証サービスで確認することによって）決定できる限られた有効期間を持つ必要があります。トークンを期限切れにすることにより、クライアントは、承認されたアクセスを継続するために新しいトークン（通常は再認証を伴う）を取得する必要があります。たとえば、OAuth 2.0では、クライアントはOAuthトークンの更新を使用して、承認サーバーへの認証後に新しいベアラートークンを取得できます。 [RFC6749]のセクション6をご覧ください。
As with bearer tokens, an HTTP cookie SHOULD last no longer than the lifetime of a browser session. An expiry time should be set that limits session cookie lifetime as per Section 5.2.1 of [RFC6265].
ベアラートークンと同様に、HTTP Cookieはブラウザーセッションの存続期間より長く存続する必要があります（SHOULD）。 [RFC6265]のセクション5.2.1に従って、セッションCookieの有効期間を制限する有効期限を設定する必要があります。
Implementations supporting OAuth bearer tokens need to factor in security considerations of this authorization method [RFC7521]. Since security is only as good as the weakest link, implementers also need to consider authentication choices coupled with OAuth bearer tokens. The security considerations of the default authentication method for OAuth bearer tokens, HTTP Basic, are well documented in [HTTP-BASIC-AUTH]; therefore, implementers are encouraged to use stronger authentication methods. Designating the specific methods of authentication and authorization is out of scope for SCIM; however, this information is provided as a resource to implementers.
OAuthベアラートークンをサポートする実装では、この認証方法のセキュリティに関する考慮事項を考慮する必要があります[RFC7521]。セキュリティは最も弱いリンクと同じくらい良いので、実装者はOAuthベアラートークンと組み合わせた認証の選択肢も考慮する必要があります。 OAuthベアラートークンのデフォルト認証方法であるHTTP Basicのセキュリティに関する考慮事項は、[HTTP-BASIC-AUTH]に詳しく記載されています。したがって、実装者はより強力な認証方法を使用することをお勧めします。認証と承認の特定の方法を指定することは、SCIMの範囲外です。ただし、この情報はリソースとして実装者に提供されます。
The SCIM Core Schema specification [RFC7643] defines attributes that may contain personally identifying information as well as other sensitive personal data. The privacy considerations in the Security Considerations section of [RFC7643] MUST be considered.
SCIMコアスキーマ仕様[RFC7643]は、個人を特定する情報やその他の機密個人データを含む可能性のある属性を定義しています。 [RFC7643]のセキュリティに関する考慮事項セクションのプライバシーに関する考慮事項を考慮する必要があります。
As mentioned in Section 9.4 of [RFC7231], SCIM clients requesting information using query filters that use HTTP GET SHOULD give consideration to the information content of the filters and whether or not their exposure in a URI would represent a breach of security or confidentiality through leakage in web browsers or server logs. This is particularly true for information that is legally considered "personally identifiable information" or is otherwise restricted by privacy laws. In these situations, to ensure maximum security and confidentiality, clients SHOULD query using HTTP POST (see Section 3.4.3).
[RFC7231]のセクション9.4で述べられているように、HTTP GETを使用するクエリフィルターを使用して情報を要求するSCIMクライアントは、フィルターの情報内容と、URIでの公開が漏洩によるセキュリティまたは機密性の侵害を表すかどうかを考慮する必要があります（SHOULD）。 Webブラウザーまたはサーバーログ。これは、法的に「個人を特定できる情報」と見なされる情報、またはプライバシー法により制限される情報に特に当てはまります。これらの状況では、最大限のセキュリティと機密性を確保するために、クライアントはHTTP POSTを使用してクエリを実行する必要があります（セクション3.4.3を参照）。
Servers that receive HTTP GET requests using filters that contain sensitive or confidential personal information SHOULD respond with HTTP status code 403 to indicate that the operation is forbidden. A "scimType" error code of "sensitive" may be returned to indicate that the request must be submitted using POST. The following is a non-normative example:
機密または機密の個人情報を含むフィルターを使用してHTTP GET要求を受信するサーバーは、HTTPステータスコード403で応答して、操作が禁止されていることを示す必要があります。 "sensitive"の "scimType"エラーコードが返され、要求がPOSTを使用して送信される必要があることを示します。以下は非規範的な例です：
HTTP/1.1 403 Forbidden
HTTP / 1.1 403 Forbidden
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Query filter involving 'name' is restricted or confidential",
"scimType": "sensitive",
"status": "404"
}
If a SCIM service provider accepts anonymous requests such as SCIM resource creation requests (via HTTP POST), appropriate security measures should be put in place to prevent or limit exposure to attacks. The following countermeasures MAY be used:
SCIMサービスプロバイダーがSCIMリソース作成要求（HTTP POST経由）などの匿名要求を受け入れる場合は、適切なセキュリティ対策を講じて、攻撃への露出を防止または制限する必要があります。次の対策を使用できます：
o Try to authenticate web user interface components that formulate the SCIM creation request. While the end-user may be anonymous, the web user interface component often has its own way to authenticate to the SCIM service provider (e.g., has an OAuth client credential [RFC6749]), and the web user interface component may implement its own measures (e.g., the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)) to ensure that a legitimate request is being made.
o SCIM作成要求を作成するWebユーザーインターフェイスコンポーネントの認証を試みます。エンドユーザーは匿名の場合がありますが、多くの場合、WebユーザーインターフェイスコンポーネントはSCIMサービスプロバイダーを認証する独自の方法を備えており（たとえば、OAuthクライアント資格情報[RFC6749]を持っています）、Webユーザーインターフェイスコンポーネントは独自の方法を実装できます（たとえば、Computers and Humans Apart（CAPTCHA）に完全に自動化されたパブリックチューリングテストを実行して、合法的な要求が行われていることを確認します）。
o Limit the number of requests that any particular client MAY make in a period of time.
o 特定のクライアントが一定期間に行う可能性のあるリクエストの数を制限します。
o For User resources, default newly created resources with an "active" setting of "false", and use a secondary confirmation process (e.g., email confirmation) to ensure that the resource created is real.
o ユーザーリソースの場合は、「アクティブ」設定が「false」の新しく作成されたリソースをデフォルト設定し、2次確認プロセス（Eメール確認など）を使用して、作成されたリソースが本物であることを確認します。
An attacker may obtain valid username/password combinations from the SCIM service provider's underlying database by gaining access to the database and/or launching injection attacks. This could lead to unintended disclosure of username/password combinations. The impact may extend beyond the domain of the SCIM service provider if the data was provisioned from other domains.
攻撃者は、データベースにアクセスしたり、インジェクション攻撃を開始したりすることにより、SCIMサービスプロバイダーの基盤となるデータベースから有効なユーザー名/パスワードの組み合わせを取得する可能性があります。これにより、ユーザー名とパスワードの組み合わせが意図せず開示される可能性があります。データが他のドメインからプロビジョニングされた場合、影響はSCIMサービスプロバイダーのドメインを超えて広がる可能性があります。
Administrators should undertake industry best practices to protect the storage of credentials and, in particular, SHOULD follow recommendations outlined in Section 5.1.4.1 of [RFC6819]. These recommendations include, but are not limited to, the following:
管理者は、資格情報のストレージを保護するための業界のベストプラクティスを実施する必要があります。特に、[RFC6819]のセクション5.1.4.1で概説されている推奨事項に従う必要があります。これらの推奨事項には、以下が含まれますが、これらに限定されません。
o Provide injection attack countermeasures (e.g., by validating all inputs and parameters);
o インジェクション攻撃対策を提供します（たとえば、すべての入力とパラメーターを検証することによって）;
o Credentials should not be stored in cleartext form;
o 資格情報はクリアテキスト形式で保存しないでください。
o Store credentials using an encrypted protection mechanism (e.g., hashing); and
o 暗号化された保護メカニズム（ハッシュなど）を使用して資格情報を保存します。そして
o Where possible, avoid passwords as the sole form of authentication, and consider using credentials that are based on asymmetric cryptography.
o 可能な場合は、唯一の認証形式としてパスワードを使用せず、非対称暗号化に基づく資格情報の使用を検討してください。
As outlined in Section 5.1.4.2 of [RFC6819], administrators SHOULD take countermeasures such as the following, to prevent online attacks on secrets:
[RFC6819]のセクション5.1.4.2で概説されているように、管理者は、シークレットへのオンライン攻撃を防ぐために、次のような対策を講じるべきです（SHOULD）。
o Utilize a secure password policy in order to increase user password entropy, which will in turn hinder online attacks and password guessing;
o 安全なパスワードポリシーを使用して、ユーザーのパスワードエントロピーを増加させます。これにより、オンライン攻撃とパスワード推測が妨げられます。
o Mitigate attacks on passwords by locking respective accounts that have a number of failed attempts;
o 多数の試行が失敗した各アカウントをロックすることにより、パスワードへの攻撃を緩和します。
o Use "tar pit" techniques by temporarily locking a respective account and delaying responses for a certain duration. The duration may increase with the number of failed attempts; and
o それぞれのアカウントを一時的にロックし、特定の期間応答を遅らせることにより、「タールピット」技術を使用します。試行の失敗回数に応じて、期間は長くなる可能性があります。そして
o Use authentication systems that use CAPTCHAs and other factors for authenticating users, to further reduce the possibility of automated attacks.
o CAPTCHAおよびその他の要素を使用してユーザーを認証する認証システムを使用して、自動攻撃の可能性をさらに減らします。
Service providers SHOULD define an access control model that differentiates between individual client applications and their specific need to access information, and any User self-service rights to review and update personal profile information. This may include OAuth 2.0 delegation profiles that allow client systems to act on behalf of users with their permission.
サービスプロバイダーは、個々のクライアントアプリケーションと情報にアクセスするための特定のニーズを区別するアクセス制御モデルと、個人プロファイル情報を確認および更新するユーザーセルフサービス権限を定義する必要があります（SHOULD）。これには、クライアントシステムがユーザーの許可を得てユーザーに代わって動作できるようにするOAuth 2.0委任プロファイルが含まれる場合があります。
When comparing Unicode strings such as those in query filters or testing for uniqueness of usernames and passwords, strings MUST be appropriately prepared before comparison. See Section 5.
クエリフィルターの文字列などのUnicode文字列を比較する場合や、ユーザー名とパスワードの一意性をテストする場合は、比較前に文字列を適切に準備する必要があります。セクション5を参照してください。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type application/scim+json
Type name: application
タイプ名：アプリケーション
Subtype name: scim+json
サブタイプ名：scim + json
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: 8bit
エンコードに関する考慮事項：8ビット
Security considerations: See Section 7 of this document (RFC 7644)
セキュリティに関する考慮事項：このドキュメントのセクション7（RFC 7644）を参照してください
Interoperability considerations: The "application/scim+json" media type is intended to identify JSON structure data that conforms to the SCIM protocol and schema specifications. Older versions of SCIM are known to informally use "application/json".
相互運用性に関する考慮事項：「application / scim + json」メディアタイプは、SCIMプロトコルおよびスキーマ仕様に準拠するJSON構造データを識別することを目的としています。古いバージョンのSCIMは、非公式に「application / json」を使用することが知られています。
Published specification: this document (RFC 7644) Applications that use this media type: It is expected that applications that use this type may be special-purpose applications intended for inter-domain provisioning. Clients may also be applications (e.g., mobile applications) that need to use SCIM for self-registration of user accounts. SCIM services may be offered by web applications that offer support for standards-based provisioning or may be a dedicated SCIM service provider such as a "cloud directory". Content may be treated as equivalent to the "application/json" type for the purpose of displaying in web browsers.
公開された仕様：このドキュメント（RFC 7644）このメディアタイプを使用するアプリケーション：このタイプを使用するアプリケーションは、ドメイン間プロビジョニングを目的とした特殊用途のアプリケーションである可能性があります。クライアントは、ユーザーアカウントの自己登録にSCIMを使用する必要があるアプリケーション（モバイルアプリケーションなど）の場合もあります。 SCIMサービスは、標準ベースのプロビジョニングをサポートするWebアプリケーションによって提供される場合と、「クラウドディレクトリ」などの専用SCIMサービスプロバイダーである場合があります。コンテンツは、Webブラウザーでの表示を目的として、「application / json」タイプと同等として扱われる場合があります。
Additional information:
追加情報：
Magic number(s):
マジックナンバー：
File extension(s): .scim .scm
ファイル拡張子：.scim .scm
Macintosh file type code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information: SCIM
mailing list "<scim@ietf.org>"
Intended usage: COMMON* (see restrictions)
使用目的：COMMON *（制限を参照）
Restrictions on usage: For most client types, it is sufficient to recognize the content as equivalent to "application/json". Applications intending to use the SCIM protocol SHOULD use the "application/scim+json" media type.
使用上の制限：ほとんどのクライアントタイプでは、「application / json」と同等のものとしてコンテンツを認識するだけで十分です。 SCIMプロトコルを使用する予定のアプリケーションは、「application / scim + json」メディアタイプを使用する必要があります（SHOULD）。
Author: Phil Hunt
著者：フィルハント
Change controller: IETF
コントローラの変更：IETF
As per the "SCIM Schema URIs for Data Resources" registry established by [RFC7643], the following defines and registers the SCIM protocol request/response JSON schema URN identifier prefix of "urn:ietf:params:scim:api:messages:2.0", which is part of the URN sub-namespace for SCIM. There is no specific associated resource type.
[RFC7643]によって確立された「データリソースのSCIMスキーマURI」レジストリに従って、以下はSCIMプロトコルリクエスト/レスポンスJSONスキーマURN識別子プレフィックス「urn：ietf：params：scim：api：messages：2.0」を定義および登録します。これは、SCIMのURNサブ名前空間の一部です。特定の関連リソースタイプはありません。
+---------------------------------+-----------------+---------------+
| Schema URI | Name | Reference |
+---------------------------------+-----------------+---------------+
| urn:ietf:params:scim:api: | List/Query | See Section |
| messages:2.0:ListResponse | Response | 3.4.2 |
| | | |
| urn:ietf:params:scim:api: | POST Query | See Section |
| messages:2.0:SearchRequest | Request | 3.4.3 |
| | | |
| urn:ietf:params:scim:api: | PATCH Operation | See Section |
| messages:2.0:PatchOp | | 3.5.2 |
| | | |
| urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkRequest | Request | 3.7 |
| | | |
| urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkResponse | Response | 3.7 |
| | | |
| urn:ietf:params:scim:api: | Error Response | See Section |
| messages:2.0:Error | | 3.12 |
+---------------------------------+-----------------+---------------+
Table 10: SCIM Schema URIs for Data Resources
表10：データリソースのSCIMスキーマURI
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[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, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <http://www.rfc-editor.org/info/rfc5789>.
[RFC5789] Dusseault、L.およびJ. Snell、「PATCH Method for HTTP」、RFC 5789、DOI 10.17487 / RFC5789、2010年3月、<http://www.rfc-editor.org/info/rfc5789>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<http://www.rfc-editor.org/info/ rfc6750>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<http：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content"、RFC 7231、DOI 10.17487 / RFC7231、June 2014、<http：// www.rfc-editor.org/info/rfc7231>。
[RFC7232] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests"、RFC 7232、DOI 10.17487 / RFC7232、June 2014、<http：// www .rfc-editor.org / info / rfc7232>。
[RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Authentication"、RFC 7235、DOI 10.17487 / RFC7235、June 2014、<http：// www。 rfc-editor.org/info/rfc7235>。
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015, <http://www.rfc-editor.org/info/rfc7538>.
[RFC7538] Reschke、J。、「Hypertext Transfer Protocol Status Code 308（Permanent Redirect）」、RFC 7538、DOI 10.17487 / RFC7538、2015年4月、<http://www.rfc-editor.org/info/rfc7538> 。
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 7613、DOI 10.17487 / RFC7613、2015年8月、<http：//www.rfc- editor.org/info/rfc7613>。
[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, <http://www.rfc-editor.org/info/rfc7643>.
[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、 <http://www.rfc-editor.org/info/rfc7643>。
[HTTP-BASIC-AUTH] Reschke, J., "The 'Basic' HTTP Authentication Scheme", Work in Progress, draft-ietf-httpauth-basicauth-update-07, February 2015.
[HTTP-BASIC-AUTH] Reschke、J。、「The 'Basic' HTTP Authentication Scheme」、Work in Progress、draft-ietf-httpauth-basicauth-update-07、2015年2月。
[OAuth-PoP-Arch] Hunt, P., Ed., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Work in Progress, draft-ietf-oauth-pop-architecture-02, July 2015.
[OAuth-PoP-Arch] Hunt、P.、Ed。、Richer、J.、Mills、W.、Mishra、P.、and H. Tschofenig、 "OAuth 2.0 Proof-of Possession（PoP）Security Architecture"、 Work in Progress、draft-ietf-oauth-pop-architecture-02、2015年7月。
[OpenSearch] Clinton, D., "OpenSearch Protocol 1.1, Draft 5", December 2005, <http://www.opensearch.org/Specifications/ OpenSearch/1.1>.
[OpenSearch]クリントン、D。、「OpenSearch Protocol 1.1、Draft 5」、2005年12月、<http://www.opensearch.org/Specifications/ OpenSearch / 1.1>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <http://www.rfc-editor.org/info/rfc6819>.
[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<http：//www.rfc -editor.org/info/rfc6819>。
[RFC6902] Bryan, P., Ed., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, <http://www.rfc-editor.org/info/rfc6902>.
[RFC6902] Bryan、P。、編、およびM. Nottingham、編、「JavaScript Object Notation（JSON）Patch」、RFC 6902、DOI 10.17487 / RFC6902、2013年4月、<http：//www.rfc-editor .org / info / rfc6902>。
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <http://www.rfc-editor.org/info/rfc7486>.
[RFC7486] Farrell、S.、Hoffman、P。、およびM. Thomas、「HTTP Origin-Bound Authentication（HOBA）」、RFC 7486、DOI 10.17487 / RFC7486、2015年3月、<http：//www.rfc-editor .org / info / rfc7486>。
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <http://www.rfc-editor.org/info/rfc7521>.
[RFC7521] Campbell、B.、Mortimore、C.、Jones、M。、およびY. Goland、「OAuth 2.0クライアント認証および許可付与のためのアサーションフレームワーク」、RFC 7521、DOI 10.17487 / RFC7521、2015年5月、<http： //www.rfc-editor.org/info/rfc7521>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 7564、DOI 10.17487 / RFC7564、2015年5月、<http：// www。 rfc-editor.org/info/rfc7564>。
[XML-Schema] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[XMLスキーマ] Biron、P。およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C勧告、2004年10月、<http://www.w3.org/TR/xmlschema-2/>。
Acknowledgements
謝辞
The editor would like to acknowledge the contribution and work of the editors of draft versions of this document:
編集者は、この文書のドラフト版の編集者の貢献と業績を認めたいと思います。
Trey Drake, UnboundID
UnboundID、Trey Drake
Chuck Mortimore, Salesforce
Chuck Mortimore、Salesforce
The editor would like to thank the participants in the SCIM working group for their support of this specification.
編集者は、この仕様をサポートしてくれたSCIMワーキンググループの参加者に感謝します。
Contributors
貢献者
Samuel Erdtman (samuel@erdtman.se)
サミュエル・アートマン（samuel@erdtman.se）
Patrick Harding (pharding@pingidentity.com)
パトリックハーディング（pharding@pingidentity.com）
Authors' Addresses
著者のアドレス
Phil Hunt (editor) Oracle Corporation
Phil Hunt（編集者）Oracle Corporation
Email: phil.hunt@yahoo.com
Kelly Grizzle SailPoint
ケリーグリズルSailPoint
Email: kelly.grizzle@sailpoint.com
Morteza Ansari Cisco
モルテザアンサリシスコ
Email: morteza.ansari@cisco.com
Erik Wahlstroem Nexus Technology
エリックウォールストロームネクサステクノロジー
Email: erik.wahlstrom@nexusgroup.com
Chuck Mortimore Salesforce.com
チャック・モーティモアSalesforce.com
Email: cmortimore@salesforce.com