Internet Engineering Task Force (IETF) K. LI, Ed.
Request for Comments: 7642 Alibaba Group
Category: Informational P. Hunt
ISSN: 2070-1721 Oracle
B. Khasnabish
ZTE (TX) Inc.
A. Nadalin
Microsoft
Z. Zeltsan
Individual
September 2015
Internet Engineering Task Force (IETF) K. LI, Ed.
Request for Comments: 7642 Alibaba Group
Category: Informational P. Hunt
ISSN: 2070-1721 Oracle
B. Khasnabish
ZTE (TX) Inc.
A. Nadalin
Microsoft
Z. Zeltsan
Individual
September 2015
System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
跨域身份管理系统：定义、概述、概念和要求
Abstract
摘要
This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.
本文档提供了跨域身份管理（SCIM）系统的定义和概述。它展示了系统的概念、模型和流程，包括用户场景、用例和需求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7642.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7642.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 5
2.1. Background and Context . . . . . . . . . . . . . . . . . 5
2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Modes and Flows . . . . . . . . . . . . . . . . . . . 7
2.2.4. Bulk and Batch Operational Semantics . . . . . . . . 8
2.3. Flows from Cloud Service Provider to Cloud Service
Provider (CSP->CSP) . . . . . . . . . . . . . . . . . . . 8
2.3.1. CSP->CSP: Create Identity (Push) . . . . . . . . . . 8
2.3.2. CSP->CSP: Update Identity (Push) . . . . . . . . . . 9
2.3.3. CSP->CSP: Delete Identity (Push) . . . . . . . . . . 9
2.3.4. CSP->CSP: SSO Trigger (Push) . . . . . . . . . . . . 9
2.3.5. CSP->CSP: SSO Trigger (Pull) . . . . . . . . . . . . 10
2.3.6. CSP->CSP: Password Reset (Push) . . . . . . . . . . . 10
2.4. Flows from Enterprise Cloud Subscriber to Cloud Service
Provider (ECS->CSP) . . . . . . . . . . . . . . . . . 10
2.4.1. ECS->CSP: Create Identity (Push) . . . . . . . . . . 10
2.4.2. ECS->CSP: Update Identity (Push) . . . . . . . . . . 11
2.4.3. ECS->CSP: Delete Identity (Push) . . . . . . . . . . 11
2.4.4. ECS->CSP: SSO Trigger (Pull) . . . . . . . . . . . . 11
3. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Migration of the Identities . . . . . . . . . . . . . . . 11
3.2. Single Sign-On (SSO) Service . . . . . . . . . . . . . . 12
3.3. Provisioning of the User Accounts for a Community of
Interest (COI) . . . . . . . . . . . . . . . . . . . . . 14
3.4. Transfer of Attributes to a Relying Party's Website . . . 15
3.5. Change Notification . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 5
2.1. Background and Context . . . . . . . . . . . . . . . . . 5
2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Modes and Flows . . . . . . . . . . . . . . . . . . . 7
2.2.4. Bulk and Batch Operational Semantics . . . . . . . . 8
2.3. Flows from Cloud Service Provider to Cloud Service
Provider (CSP->CSP) . . . . . . . . . . . . . . . . . . . 8
2.3.1. CSP->CSP: Create Identity (Push) . . . . . . . . . . 8
2.3.2. CSP->CSP: Update Identity (Push) . . . . . . . . . . 9
2.3.3. CSP->CSP: Delete Identity (Push) . . . . . . . . . . 9
2.3.4. CSP->CSP: SSO Trigger (Push) . . . . . . . . . . . . 9
2.3.5. CSP->CSP: SSO Trigger (Pull) . . . . . . . . . . . . 10
2.3.6. CSP->CSP: Password Reset (Push) . . . . . . . . . . . 10
2.4. Flows from Enterprise Cloud Subscriber to Cloud Service
Provider (ECS->CSP) . . . . . . . . . . . . . . . . . 10
2.4.1. ECS->CSP: Create Identity (Push) . . . . . . . . . . 10
2.4.2. ECS->CSP: Update Identity (Push) . . . . . . . . . . 11
2.4.3. ECS->CSP: Delete Identity (Push) . . . . . . . . . . 11
2.4.4. ECS->CSP: SSO Trigger (Pull) . . . . . . . . . . . . 11
3. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Migration of the Identities . . . . . . . . . . . . . . . 11
3.2. Single Sign-On (SSO) Service . . . . . . . . . . . . . . 12
3.3. Provisioning of the User Accounts for a Community of
Interest (COI) . . . . . . . . . . . . . . . . . . . . . 14
3.4. Transfer of Attributes to a Relying Party's Website . . . 15
3.5. Change Notification . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document provides the SCIM definitions, overview, concepts, flows, scenarios, and use cases. It also provides a list of the requirements derived from the use cases.
本文档提供了SCIM定义、概述、概念、流程、场景和用例。它还提供了从用例派生的需求列表。
The document's objective is to help with understanding of the design and applicability of the SCIM schema [RFC7643] and SCIM protocol [RFC7644].
本文件的目的是帮助理解SCIM模式[RFC7643]和SCIM协议[RFC7644]的设计和适用性。
Unlike the practice of some protocols like Application Bridging for Federated Access Beyond web (ABFAB) and SAML2 WebSSO, SCIM provides provisioning and de-provisioning of resources in a separate context from authentication (aka just-in-time provisioning).
与某些协议（如web之外的联邦访问的应用程序桥接（ABFAB）和SAML2 WebSO）的实践不同，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] when they appear in ALL CAPS. These words may also appear in this document in lowercase as plain English words, absent their normative meanings.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。本文件中的这些词语也可能以小写形式出现，作为普通英语词语，但不具有规范意义。
Here is a list of acronyms and abbreviations used in this document:
以下是本文件中使用的首字母缩略词和缩写词列表：
o COI: Community of Interest
o COI：利益共同体
o CRM: Customer Relationship Management
o 客户关系管理
o CRUD: Create, Read, Update, Delete
o CRUD：创建、读取、更新、删除
o CSP: Cloud Service Provider
o 云服务提供商
o CSU: Cloud Service User
o 云服务用户
o ECS: Enterprise Cloud Subscriber
o ECS：企业云订户
o IaaS: Infrastructure as a Service
o IaaS：基础设施即服务
o JIT: Just In Time
o 准时制：刚好及时
o PaaS: Platform as a Service
o PaaS：平台即服务
o SaaS: Software as a Service
o SaaS：软件即服务
o SAML: Security Assertion Markup Language
o SAML：安全断言标记语言
o SCIM: System for Cross-domain Identity Management
o SCIM：跨域身份管理系统
o SSO: Single Sign-On
o 单点登录
The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability. 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. The intent of the SCIM specification is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.
跨域身份管理系统（SCIM）规范旨在以标准化的方式管理基于云的应用程序和服务中的用户身份，以实现互操作性、安全性和可扩展性。规范套件寻求在现有模式和部署经验的基础上构建，特别强调开发和集成的简单性，同时应用现有的身份验证、授权和隐私模型。SCIM规范的目的是通过提供公共用户模式和扩展模型以及绑定文档来提供使用标准协议交换该模式的模式，从而降低用户管理操作的成本和复杂性。从本质上说，让它快速、廉价、方便地将用户移入、移出云端以及在云端周围移动。
The SCIM scenarios are overviews of user stories designed to help clarify the intended scope of the SCIM effort.
SCIM场景是用户故事的概述，旨在帮助澄清SCIM工作的预期范围。
Quite simply, triggers are actions or activities that start SCIM flows. Triggers may not be relevant at the protocol level or the schema level; they really serve to help identify the type or activity that resulted in a SCIM protocol exchange. Triggers make use of the traditional provisioning CRUD (Create, Read, Update, Delete) operations but add additional use-case contexts like SSO (Single-Sign On) as it is designed to capture a class of use case that makes sense to the actor requesting it rather than to describe a protocol operation.
很简单，触发器是启动SCIM流的操作或活动。触发器可能与协议级别或模式级别无关；它们确实有助于识别导致SCIM协议交换的类型或活动。触发器使用传统的配置CRUD（创建、读取、更新、删除）操作，但添加了额外的用例上下文，如SSO（单点登录），因为它旨在捕获一类对请求它的参与者有意义的用例，而不是描述协议操作。
o Create SCIM Identity Resource - Service On-boarding Trigger: A "create SCIM identity resource" trigger is a service on-boarding activity in which a business action such as a new hire or new service subscription is initiated by one of the SCIM Actors. In the protocol itself, service on-boarding may well be implemented via the same resource PUT method as a service change. This is particular to the implementation, and not to the use cases that drive that implementation.
o 创建SCIM标识资源-随车服务触发器：“创建SCIM标识资源”触发器是一种随车服务活动，其中业务操作（如新员工或新服务订阅）由SCIM参与者之一发起。在协议本身中，登机服务很可能通过与服务更改相同的资源放置方法来实现。这是特定于实现的，而不是驱动该实现的用例。
o Update SCIM Identity Resource - Service Change Trigger: An "update SCIM identity resource" trigger is a service change activity as a result of an identity moving or changing its service level. An "update SCIM identity" trigger might be the result of a change in a service subscription level or a change to key identity data used to denote a service subscription level. Password changes are specifically called out from other more general identity attribute changes as they are considered to have specific use-case differences.
o 更新SCIM标识资源-服务更改触发器：“更新SCIM标识资源”触发器是由于标识移动或更改其服务级别而导致的服务更改活动。“更新SCIM标识”触发器可能是服务订阅级别更改或用于表示服务订阅级别的密钥标识数据更改的结果。密码更改是从其他更一般的标识属性更改中特别调用的，因为它们被认为具有特定的用例差异。
o Delete SCIM Identity Resource - Service Termination Trigger: A "delete SCIM identity resource" trigger represents a specific and deliberate action to remove an identity from a given SCIM service point. At this stage, it is unclear if the SCIM protocol needs to identify a separate protocol exchange for service suspension actions. This may be relevant as target services usually differentiate between these results and thus may require separate resource representations.
o Delete SCIM Identity Resource-服务终止触发器：“Delete SCIM Identity Resource”触发器表示从给定SCIM服务点删除标识的特定故意操作。在这个阶段，尚不清楚SCIM协议是否需要为服务暂停行动确定单独的协议交换。这可能是相关的，因为目标服务通常区分这些结果，因此可能需要单独的资源表示。
o Single Sign-On (SSO) Trigger - Service Access Request: A "Single Sign-On" trigger is a special class of activity in which a Create or Update trigger is initiated during an SSO operational flow. The implication here is that, as the result of a service access request by the end user (SSO), defined SCIM protocol exchanges can be used to initiate SCIM resource CRUD operations somewhere in the service cloud.
o 单点登录（SSO）触发器-服务访问请求：“单点登录”触发器是一种特殊类型的活动，其中在SSO操作流期间启动创建或更新触发器。这里的含义是，作为最终用户（SSO）的服务访问请求的结果，定义的SCIM协议交换可用于在服务云中的某处启动SCIM资源CRUD操作。
Actors are the operating parties that take part in both sides of a SCIM protocol exchange and help identify the source of a given Trigger. So far, we have identified the following SCIM Actors:
参与者是参与SCIM协议交换双方并帮助确定给定触发器来源的操作方。到目前为止，我们已经确定了以下SCIM参与者：
o Cloud Service Provider (CSP): A CSP is the entity operating a given cloud service. In a SaaS scenario, this is simply the application provider. In an IaaS or PaaS scenario, the CSP may be the underlying IaaS/PaaS infrastructure provider or the owner of the application running on that platform. In all cases, the CSP is the thing that holds the identity information being operated upon. Put another way, the CSP really is the service that the end user interacts with.
o 云服务提供商（CSP）：CSP是运行给定云服务的实体。在SaaS场景中，这只是应用程序提供者。在IaaS或PaaS场景中，CSP可能是基础IaaS/PaaS基础设施提供商或在该平台上运行的应用程序的所有者。在所有情况下，CSP都是保存正在操作的身份信息的东西。换句话说，CSP实际上是最终用户与之交互的服务。
o Enterprise Cloud Subscriber (ECS): An ECS represents a middle tier of aggregation for related identity records. In one of our sample enterprise SaaS scenarios, the ECS is "Example.com" that subscribes to a cloud-based CRM service "SaaS-CRM Inc." (the CSP) for all of its sales staff. The actual Cloud Service Users (CSUs) are the FooBar Inc. sales staff. The ECS Actor is identified to
o 企业云订户（ECS）：ECS代表相关身份记录的中间聚合层。在我们的一个示例企业SaaS场景中，ECS是“Example.com”，为其所有销售人员订阅基于云的CRM服务“SaaS CRM Inc.”（CSP）。实际的云服务用户（CSU）是FooBar Inc.的销售人员。ECS参与者被标识为
help capture use cases in which a single entity is given administrative responsibility for other identity accounts. SCIM may not address the configuration and setup of an ECS within the CSP, but it does address use cases in which SCIM identity resources are grouped together and administered as part of some broader agreement or operational exchange.
帮助捕获单个实体对其他身份帐户承担管理责任的用例。SCIM可能不会解决CSP内ECS的配置和设置问题，但它确实解决了将SCIM身份资源分组在一起并作为更广泛的协议或操作交换的一部分进行管理的用例。
o Cloud Service User (CSU): A CSU represents the real cloud service end user -- i.e., the person logging into and using the cloud service. As described above, and ECS will typically own or manage multiple CSU identities, whereas the CSU represents the FooBar Inc. employee using the cloud service to manage their CRM process.
o 云服务用户（CSU）：CSU代表真正的云服务最终用户——即登录并使用云服务的人。如上所述，ECS通常拥有或管理多个CSU身份，而CSU代表FooBar Inc.员工使用云服务管理其CRM流程。
+---------------------+
| Cloud Service |
| Provider (CSP) |
+---------------------+
|
+--------------------------------+
| |
v v
+----------------+ +----------------+
|Enterprise Cloud| |Enterprise Cloud|
|Subscriber (ECS)| |Subscriber (ECS)|
+----------------+ +----------------+
| |
+----------------+ +----------------+
| | | |
v v v v
+-------------+ +-------------+ +-------------+ +-------------+
|Cloud Service| |Cloud Service| |Cloud Service| |Cloud Service|
| User (CSU) | | User (CSU) | | User (CSU) | | User (CSU) |
+-------------+ +-------------+ +-------------+ +-------------+
+---------------------+
| Cloud Service |
| Provider (CSP) |
+---------------------+
|
+--------------------------------+
| |
v v
+----------------+ +----------------+
|Enterprise Cloud| |Enterprise Cloud|
|Subscriber (ECS)| |Subscriber (ECS)|
+----------------+ +----------------+
| |
+----------------+ +----------------+
| | | |
v v v v
+-------------+ +-------------+ +-------------+ +-------------+
|Cloud Service| |Cloud Service| |Cloud Service| |Cloud Service|
| User (CSU) | | User (CSU) | | User (CSU) | | User (CSU) |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: SCIM Actors
图1:SCIM参与者
Modes identify the functional intent of a data flow initiated in a SCIM scenario. The modes identified so far are 'Push' and 'Pull' referring to pushing data to and pulling data from an authoritative identity data store.
模式识别在SCIM场景中启动的数据流的功能意图。迄今为止确定的模式是“推送”和“拉送”，指的是将数据推送到权威身份数据存储并从中提取数据。
In the SCIM scenarios, modes are often used in the context of a flow between two Actors. For example, one might refer to a Cloud-to-Cloud Pull exchange. Here one Cloud Service Provider (CSP) is pulling identity information from another CSP. Commonly referenced flows are:
在SCIM场景中，模式通常用于两个参与者之间的流程。例如，可以引用云到云拉式交换。这里，一个云服务提供商（CSP）正在从另一个CSP获取身份信息。通常参考的流程包括：
o Cloud Service Provider to Cloud Service Provider (CSP->CSP)
o 云服务提供商到云服务提供商（CSP->CSP）
o Enterprise Cloud Subscriber to Cloud Service Provider (ECS->CSP)
o 云服务提供商的企业云订户（ECS->CSP）
Modes and flows simply help us understand what is taking place; they are likely to be technically meaningless at the protocol level, but they help the reader follow the SCIM scenarios and apply them to real-world use cases.
模式和流程只是帮助我们理解正在发生的事情；它们在协议级别上可能在技术上毫无意义，但它们帮助读者遵循SCIM场景，并将其应用于实际用例。
It is assumed that each of the trigger actions outlined in this document may be part of the larger bulk or batch operation. Individual SCIM actions should be able to be collected together to create single protocol exchanges.
假设本文件中概述的每个触发动作可能是较大批量或批量操作的一部分。应能够将单个SCIM操作收集在一起，以创建单个协议交换。
The initial focus of SCIM scenarios is on identifying base flows and single operations. The specific complexity of full bulk and batch operations is left to a later version of the scenarios or to the main specification.
SCIM场景的最初重点是确定基本流和单个操作。完整批量和批处理操作的具体复杂性将留待场景的更高版本或主规范决定。
2.3. Flows from Cloud Service Provider to Cloud Service Provider (CSP->CSP)
2.3. 从云服务提供商到云服务提供商的流程（CSP->CSP）
These scenarios represent flows between two Cloud Service Providers (CSPs). It is assumed that each CSP maintains an Identity Data Store for its Cloud Service Users (CSUs). These scenarios address various joiner, mover, leaver, and JIT triggers, resulting in push and pull data exchanges between the CSPs.
这些场景表示两个云服务提供商（CSP）之间的流。假设每个CSP为其云服务用户（CSU）维护一个身份数据存储。这些场景处理各种joiner、mover、leaver和JIT触发器，从而在CSP之间进行推送和拉送数据交换。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. CSP-1 receives a Create Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 creates a local user account for the new CSU. CSP-1 then pushes the new CSU joiner push request downstream to CSU-2 and gets confirmation that the account was successfully created. After receiving the confirmation from CSP-2, CSP-1 sends an acknowledgment to the requesting ECS.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。CSP-1从其企业云订户（ECS-1）接收创建标识触发操作。CSP-1为新CSU创建本地用户帐户。然后，CSP-1将新的CSU joiner推送请求向下推送到CSU-2，并获得成功创建帐户的确认。在接收到来自CSP-2的确认后，CSP-1向请求ECS发送确认。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. The Enterprise Cloud Subscriber (ECS-1) has already created an account with CSP-1 and supplied a critical attribute "department" that is used by CSP-1 to drive service options. CSP-1 then receives an Update Identity trigger action from its Enterprise Cloud Subscriber (ECS). CSP-1 updates its local directory account with the new department value. CSP-1 then initiates a separate SCIM protocol exchange to push the mover change request downstream to CSP-2. After receiving the confirmation from CSP-2, CSP-1 sends an acknowledgment to ECS-1.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。企业云订户（ECS-1）已经使用CSP-1创建了一个帐户，并提供了一个关键属性“department”，CSP-1使用该属性来驱动服务选项。然后，CSP-1从其企业云订户（ECS）接收更新标识触发操作。CSP-1使用新的部门值更新其本地目录帐户。然后，CSP-1启动单独的SCIM协议交换，将移动器更改请求推送到下游CSP-2。在接收到来自CSP-2的确认后，CSP-1向ECS-1发送确认。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. CSP-1 receives a Delete Identity trigger action from its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local directory account for the specified CSU account. CSP-1 then pushes a termination request for the specified CSU account downstream to CSP-2 and gets confirmation that the account was successfully removed. After receiving the confirmation from CSP-2, CSP-1 finalizes the deletion operation and sends an acknowledgment to the requesting ECS.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。CSP-1从其企业云订户（ECS-1）接收删除标识触发操作。CSP-1挂起指定CSU帐户的本地目录帐户。然后，CSP-1将指定CSU帐户的终止请求推送到下游CSP-2，并确认该帐户已成功删除。在收到CSP-2的确认后，CSP-1完成删除操作并向请求的ECS发送确认。
This use case highlights how different CSPs may implement different operational semantics behind the same SCIM operation. Note CSP-1 suspends the account representation for its service, whereas CPS-2 implements a true delete operation.
这个用例强调了不同的CSP如何在同一个SCIM操作背后实现不同的操作语义。注意：CSP-1挂起其服务的帐户表示，而CPS-2实现真正的删除操作。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. However, rather than pre-provisioning accounts from CSP-1 to CSP-2, CSP-1 waits for a service access request from the end Cloud Service User (CSU-1) before issuing account creation details to CSP-2. When the CSU completes a SSO transaction from CSP-1 to CSP-2, CSP-2 then creates an account for the CSU based on information pushed to it from CSP-1.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。但是，在向CSP-2发布帐户创建详细信息之前，CSP-1会等待来自最终云服务用户（CSU-1）的服务访问请求，而不是从CSP-1到CSP-2预配置帐户。当CSU完成从CSP-1到CSP-2的SSO事务时，CSP-2会根据从CSP-1推送到CSU的信息为CSU创建一个帐户。
At the protocol level, this class of scenarios may result in the use of common protocol exchange patterns between CSP-1 and CSP-2.
在协议级别，这类场景可能导致在CSP-1和CSP-2之间使用公共协议交换模式。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. However, rather than pre-provisioning accounts from CSP-1 to CSP-2, CSP-2 waits for a service access request from the Cloud Service User (CSU-1) before initiating a Pull request to gather information about the CSU sufficient to create a local account.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。但是，CSP-2在启动拉取请求以收集足以创建本地帐户的有关CSU的信息之前，会等待来自云服务用户（CSU-1）的服务访问请求，而不是从CSP-1到CSP-2预配置帐户。
At the protocol level, this class of scenarios may result in the use of common protocol exchange patterns between CSP-2 and CSP-1.
在协议级别，这类场景可能导致在CSP-2和CSP-1之间使用公共协议交换模式。
In this scenario, two CSPs (CSP-1 and CSP-2) have a shared service agreement in place that requires the exchange of Cloud Service User (CSU) accounts. CSP-1 wants to change the password for a specific Cloud Service User (CSU-1). CSP-1 sends a request to CSP-2 to reset the password value for CSU-1.
在此场景中，两个CSP（CSP-1和CSP-2）有一个共享服务协议，该协议要求交换云服务用户（CSU）帐户。CSP-1希望更改特定云服务用户（CSU-1）的密码。CSP-1向CSP-2发送重置CSU-1密码值的请求。
At the protocol level, this scenario may result in the same protocol exchange as any other attribute change request.
在协议级别，此场景可能导致与任何其他属性更改请求相同的协议交换。
2.4. Flows from Enterprise Cloud Subscriber to Cloud Service Provider (ECS->CSP)
2.4. 从企业云订户到云服务提供商的流量（ECS->CSP）
These scenarios represent flows between an Enterprise Cloud Subscriber (ECS) and a Cloud Service Providers (CSP). It is assumed that the ECS and the CSP each maintain an information access service for the relevant Cloud Service Users (CSUs). These scenarios address various joiner, mover, leaver, and JIT triggers, resulting in push and pull data exchanges between the ECS and the CSP.
这些场景表示企业云订户（ECS）和云服务提供商（CSP）之间的流。假设ECS和CSP各自为相关云服务用户（CSU）维护信息访问服务。这些场景解决了各种joiner、mover、leaver和JIT触发器，导致ECS和CSP之间的推拉数据交换。
Many of these scenarios are very similar to those defined in Section 2.3. They are identified separately here so that we may explore any differences that might emerge.
其中许多场景与第2.3节中定义的场景非常相似。它们在这里被单独识别，以便我们可以探索可能出现的任何差异。
In this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1) that requires the sharing of various Cloud Service User (CSU) accounts. A new user joins ECS-1 and so ECS-1 pushes an account creation request to CSP-1, supplying all required attribute values for the base SCIM schema and additional values for the extended SCIM schema as required.
在此场景中，企业云订户（ECS-1）与云服务提供商（CSP-1）维护一项服务，该服务需要共享各种云服务用户（CSU）帐户。新用户加入ECS-1，因此ECS-1将帐户创建请求推送到CSP-1，为基本SCIM模式提供所有必需的属性值，并根据需要为扩展SCIM模式提供附加值。
In this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with Cloud Service Provider (CSP-1) that drives service definition from a key account schema attribute called Department. ECS-1 wishes to move a given CSU from Department A to Department B and so it pushes an attribute update request to the CSP.
在此场景中，企业云订户（ECS-1）与云服务提供商（CSP-1）一起维护服务，该服务从名为Department的关键帐户模式属性驱动服务定义。ECS-1希望将给定的CSU从部门a移动到部门B，因此它将属性更新请求推送到CSP。
In this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1). Upon termination of one of its employee's employment agreement, ECS-1 sends a suspend account request to CSP-1. One week later, the ECS wishes to complete the process by fully removing the Cloud Service User (CSU) account, so it sends a terminate account request to CSP-1.
在此场景中，企业云订户（ECS-1）与云服务提供商（CSP-1）维护服务。在其员工的雇佣协议终止后，ECS-1向CSP-1发送暂停帐户请求。一周后，ECS希望通过完全删除云服务用户（CSU）帐户来完成此过程，因此向CSP-1发送终止帐户请求。
In this scenario, an Enterprise Cloud Subscriber (ECS-1) maintains a service with a Cloud Service Provider (CSP-1). No accounts are created or exchanged in advance. However, rather than pre-provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service access request from the Cloud Service User (CSU-1) under the control domain of ECS-1, before issuing an account Pull request to ECS-1.
在此场景中，企业云订户（ECS-1）与云服务提供商（CSP-1）维护服务。未预先创建或交换任何帐户。但是，在向ECS-1发出帐户拉取请求之前，CSP-1等待ECS-1控制域下的云服务用户（CSU-1）的服务访问请求，而不是从ECS-1向CSP-1预配置帐户。
This section lists the SCIM use cases.
本节列出了SCIM用例。
Description:
说明：
A company SomeEnterprise runs an application ManageThem that relies on the identity information about its employees (e.g., identifiers, attributes). The identity information is stored at the cloud provided by SomeCSP. SomeEnterprise has decided to move identity information to the cloud of a different provider -- AnotherCSP. In addition, SomeEnterprise has purchased a second application ManageThemMore, which also relies on the identity information. SomeEnterprise is able to move identity information to AnotherCSP without changing the format of identity information. The application ManageThemMore is able to use the identity information.
公司或企业运行的应用程序ManageThem依赖于其员工的身份信息（例如，标识符、属性）。身份信息存储在SomeCSP提供的云上。一些企业决定将身份信息移动到另一个提供商的云上——另一个CSP。此外，一些企业还购买了第二个应用程序ManageThemMore，它也依赖于身份信息。有些企业能够在不改变身份信息格式的情况下将身份信息移动到另一个CSP。应用程序管理员可以使用身份信息。
Pre-conditions:
先决条件：
o SomeCSP is a cloud service provider for SomeEnterprise.
o SomeCSP是SomeEnterprise的云服务提供商。
o SomeCSP has a known attribute name and value for the Enterprise used for managing and transferring data.
o SomeCSP具有用于管理和传输数据的企业的已知属性名称和值。
o AnotherCSP is a new cloud service provider for SomeEnterprise.
o 另一个CSP是一些企业的新云服务提供商。
o All involved cloud service providers and applications support the same standard specifying the format for and actions on the user (e.g., employee) identity information.
o 所有涉及的云服务提供商和应用程序都支持相同的标准，指定用户（如员工）身份信息的格式和操作。
Post-conditions:
岗位条件：
o SomeEnterprise has moved its employees' identity information from SomeCSP to AnotherCSP without making any changes to representation of identity information.
o 一些企业将其员工的身份信息从一个CSP移动到另一个CSP，而没有对身份信息的表示进行任何更改。
o Application ManageThemMore is able to use the identity information.
o Application Manager摩尔能够使用身份信息。
Requirements:
要求：
o SomeEnterprise, the applications ManageThem and ManageThemMore, and the providers SomeCSP and AnotherCSP support a common standard for identity information, which specifies the following:
o 一些企业、应用程序ManageThem和ManageThemMore以及提供者SomeCSP和其他CSP支持身份信息的通用标准，该标准规定了以下内容：
* Format (or schema) for representing user identity information
* 表示用户身份信息的格式（或模式）
* Interfaces and protocol for managing user identity information
* 用于管理用户身份信息的接口和协议
o Cloud providers shall be able to meet regulatory requirements when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
o 当在管辖区域之间迁移身份信息时（例如，国家和州可能对隐私有不同的规定），云提供商应能够满足监管要求。
o Cloud providers shall be able to log all actions related to SomeEnterprise employees' identities.
o 云提供商应能够记录与某些企业员工身份相关的所有操作。
o The logs should be secure and available for auditing.
o 日志应该是安全的，并可用于审核。
Description:
说明：
Bob has an account in an application hosted by a cloud service provider SomeCSP. SomeCSP has federated its user identities with a cloud service provider AnotherCSP. Bob requests a service from an application running on AnotherCSP. The application running on AnotherCSP, relying on Bob's authentication by SomeCSP and using identity information provided by SomeCSP, serves Bob's request.
Bob在云服务提供商SomeCSP托管的应用程序中拥有一个帐户。SomeCSP已将其用户身份与另一个CSP的云服务提供商联合。Bob从另一个CSP上运行的应用程序请求服务。在另一个CSP上运行的应用程序依赖于SomeCSP提供的Bob身份验证，并使用SomeCSP提供的身份信息，为Bob的请求提供服务。
Pre-conditions:
先决条件：
o Bob's identity information is stored on SomeCSP.
o Bob的身份信息存储在SomeCSP上。
o SomeCSP and AnotherCSP have established trust and federated their user identities.
o 一些CSP和另一个CSP建立了信任并联合了他们的用户身份。
o SomeCSP is able to authenticate Bob.
o SomeCSP能够对Bob进行身份验证。
o SomeCSP is able to securely provide the authentication results to AnotherCSP.
o 某些CSP能够安全地向另一个CSP提供身份验证结果。
o SomeCSP is able to securely provide Bob's identity information (e.g., attributes) to AnotherCSP.
o 某些CSP能够安全地向另一个CSP提供Bob的身份信息（例如属性）。
o AnotherCSP is able to verify information provided by SomeCSP.
o 另一个CSP能够验证某个CSP提供的信息。
o SomeCSP is able to process the identity information received from AnotherCSP.
o 某些CSP能够处理从另一个CSP接收的身份信息。
Post-conditions:
岗位条件：
Bob has received the requested service from an application running on AnotherCSP without having to authenticate to that application explicitly.
Bob已从另一个CSP上运行的应用程序接收到请求的服务，而无需显式验证该应用程序。
Requirements:
要求：
o Bob must have an account with SomeCSP.
o Bob必须在SomeCSP有一个帐户。
o SomeCSP and AnotherCSP must establish trust and federate their user identities.
o 一些CSP和另一个CSP必须建立信任并联合其用户身份。
o SomeCSP must be able to authenticate Bob.
o SomeCSP必须能够对Bob进行身份验证。
o SomeCSP must be able to securely provide the authentication results to AnotherCSP.
o 某些CSP必须能够安全地向另一个CSP提供身份验证结果。
o SomeCSP must be able to securely provide Bob's identity information (e.g., attributes) to AnotherCSP.
o 某些CSP必须能够安全地向另一个CSP提供Bob的身份信息（例如属性）。
o AnotherCSP must be able to verify the identity information provided by SomeCSP.
o 另一个CSP必须能够验证某个CSP提供的身份信息。
o SomeCSP must be able to process the identity information received from AnotherCSP.
o 某些CSP必须能够处理从另一个CSP接收的身份信息。
o SomeCSP and AnotherCSP must log information generated by Bob's actions according to their policies and the trust agreement between them.
o 一些CSP和另一个CSP必须根据他们的策略和他们之间的信任协议记录由Bob的操作生成的信息。
3.3. Provisioning of the User Accounts for a Community of Interest (COI)
3.3. 为利益共同体（COI）提供用户帐户
Description:
说明：
Organization YourHR provides Human Resources (HR) services to a Community of Interest (COI) YourCOI. The HR services are offered as Software as a Service (SaaS) on public and private clouds. YourCOI's offices are located all over the world. Their Information Technology (IT) systems may be composed of combinations of the applications running on private and public clouds along with traditional IT systems. The local YourCOI offices are responsible for collecting personal information (i.e., user identities and attributes). YourHR services provide means for provisioning and distributing the employee identity information across all YourCOI offices. YourHR also enables individual users (e.g., employees) to manage personal information that they are responsible for (e.g., update of an address or a telephone number).
组织YourHR向利益共同体（COI）YourCOI提供人力资源（HR）服务。人力资源服务在公共云和私有云上以软件即服务（SaaS）的形式提供。YourCOI的办事处遍布世界各地。他们的信息技术（IT）系统可能由运行在私有云和公共云上的应用程序以及传统IT系统的组合组成。当地YourCOI办事处负责收集个人信息（即用户身份和属性）。YourHR服务提供了在所有COI办公室提供和分发员工身份信息的方法。YourHR还允许个人用户（如员工）管理他们负责的个人信息（如地址或电话号码的更新）。
Pre-conditions:
先决条件：
o YourCOI has a complex infrastructure composed of a large number of local offices that rely on diverse IT systems.
o YourCOI拥有一个复杂的基础设施，由大量依赖不同IT系统的本地办事处组成。
o YourCOI has contracted YourHR to provide the HR services.
o YourCOI已与YourHR签订合同，提供人力资源服务。
o Each local office has a right to establish a personal account for an employee.
o 每个当地办事处都有权为员工建立个人账户。
Post-conditions:
岗位条件：
o All personal accounts are globally available to any authorized user or application across the YourCOI system through the services provided by YourHR.
o 通过YourHR提供的服务，YourCOI系统中的任何授权用户或应用程序均可在全球范围内使用所有个人帐户。
o The employees have the ability to manage the part of personal information that is their responsibility.
o 员工有能力管理属于其职责的部分个人信息。
Requirements:
要求：
o YourHR must ensure that the local offices generate information that is provisioned securely and consider privacy requirements in a timely fashion across systems that may span technical (e.g., protocols and applications), administrative (e.g., corporate), regulatory (e.g., location), and jurisdictional domains.
o YHR必须确保本地办公室安全地提供信息，并在跨越技术（例如，协议和应用）、管理（例如，企业）、监管（例如，位置）和管辖域的系统中及时考虑隐私要求。
o Management of personal information must be protected against unauthorized access and eavesdropping, and it should be distributed only to authorized parties and services.
o 个人信息的管理必须受到保护，防止未经授权的访问和窃听，并且只能分发给授权方和服务机构。
o Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
o 在管辖区域之间迁移身份信息时，应满足监管要求（例如，国家和州可能有不同的隐私法规）。
o All operations with identity data must be securely logged.
o 必须安全地记录具有标识数据的所有操作。
o The logs should be available for auditing.
o 日志应可用于审核。
Description:
说明：
An end user has an account in a directory service A with one or more attributes. That user then visits the website of relying party B, and the website requires attributes of the user. The user selects some attributes and authorizes the transfer of data via authorization protocols (e.g., OAuth, SAML), so selected attributes of the user are transferred from the user's account in directory service A to the website of replying party B at the time of the user's first visit to that site.
最终用户在目录服务中有一个帐户，该帐户具有一个或多个属性。然后该用户访问依赖方乙方的网站，该网站需要该用户的属性。用户选择一些属性并通过授权协议（例如OAuth、SAML）授权数据传输，因此用户的选定属性在用户首次访问该站点时从目录服务A中的用户帐户传输到回复方B的网站。
Pre-conditions:
先决条件：
o User has an account in directory service A.
o 用户在目录服务A中有一个帐户。
o User has one or more attributes.
o 用户具有一个或多个属性。
o User visits website of relying party B.
o 用户访问依赖方乙方的网站。
Post-conditions:
岗位条件：
Selected attributes of the user are transferred from the user's account in directory service A to the website of relying party B at the time of the user's first visit to that site.
用户的选定属性在用户首次访问该网站时从用户在目录服务A中的帐户传输到依赖方B的网站。
Requirements:
要求：
o Relying party B must be able to authenticate the end user.
o 依赖方B必须能够认证最终用户。
o Relying party B must be able to securely provide the authentication results to directory service A.
o 依赖方B必须能够安全地向目录服务A提供认证结果。
o Directory service A must be able to securely provide end user's identity information (e.g., attributes) to relying party B.
o 目录服务A必须能够安全地向依赖方B提供最终用户的身份信息（例如属性）。
o Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
o 在管辖区域之间迁移身份信息时，应满足监管要求（例如，国家和州可能有不同的隐私法规）。
o Relying parties have to be aware of changes to their cached copy, as these would potentially cause a state change in other relying parties.
o 依赖方必须知道对其缓存副本的更改，因为这些更改可能会导致其他依赖方的状态更改。
o A maximum period should be set for the relying party to cache the information.
o 应为依赖方缓存信息设置最长时间。
Description:
说明：
An end user has an account in a directory service A with one or more attributes. That user then visits the web site of relying party B. The website of relying party B queries directory service A for attributes associated with that user, and related resources.
最终用户在目录服务中有一个帐户，该帐户具有一个或多个属性。然后该用户访问依赖方B的网站。依赖方B的网站查询目录服务A，以获取与该用户相关的属性和相关资源。
The attributes of the user change later in directory service A. For example, the attributes might change if the user changes their name, has their account disabled, or terminates their relationship with directory service A. Furthermore, other resources and their attributes might also change. The directory service A then wishes to notify the website of relying party B of these changes, as relying party B might (or might not) have a cache of those attributes, and if relying party B were aware of these changes to their cached copy, it would potentially cause a state change in relying party B.
用户的属性稍后会在目录服务A中更改。例如，如果用户更改其名称、禁用其帐户或终止与目录服务A的关系，则属性可能会更改。此外，其他资源及其属性也可能会更改。然后，目录服务A希望将这些更改通知依赖方B的网站，因为依赖方B可能（或可能不）拥有这些属性的缓存，如果依赖方B知道对其缓存副本的这些更改，则可能会导致依赖方B的状态更改。
The volume of changes, however, might be substantial, and only some of the changes may be of interest to relying party B, so directory service A does not wish to "push" all the changes to B. Instead, directory service A wishes to notify B that there are changes potentially of interest, such that B can at an appropriate time subsequently contact directory service A and retrieve just the subset of changes of interest to B.
然而，变更量可能很大，并且依赖方B可能只对部分变更感兴趣，因此目录服务A不希望将所有变更“推送”给B。相反，目录服务A希望通知B存在可能感兴趣的变更，这样，B可以在适当的时间随后联系目录服务A并检索对B感兴趣的更改的子集。
Note that the user must authorize directory service A to transfer data to the website, and the user must authorize directory service A to notify the website.
请注意，用户必须授权目录服务A将数据传输到网站，并且用户必须授权目录服务A通知网站。
Pre-conditions:
先决条件：
o User has an account in directory service A.
o 用户在目录服务A中有一个帐户。
o User has one or more attributes.
o 用户具有一个或多个属性。
o User visits the website of relying party B.
o 用户访问依赖方乙方的网站。
o The resource being updated is at the website.
o 正在更新的资源位于网站上。
Post-conditions:
岗位条件：
Directory service A is able to notify relying party B that there are changes potentially of interest.
目录服务A能够通知依赖方B有可能感兴趣的变更。
Requirements:
要求：
o Relying party B must be able to authenticate the end user.
o 依赖方B必须能够认证最终用户。
o Relying party B must be able to securely provide the authentication results to directory service A.
o 依赖方B必须能够安全地向目录服务A提供认证结果。
o Directory service A must be able to securely provide end user's changed identity information (e.g., attributes) to relying party B.
o 目录服务A必须能够安全地向依赖方B提供最终用户更改的身份信息（例如属性）。
o Relying party B must be able at an appropriate time to subsequently contact directory service A and retrieve just the subset of changes of interest to relying party B.
o 依赖方乙方必须能够在适当的时间联系目录服务A，并检索依赖方乙方感兴趣的变更子集。
Authentication and authorization must be guaranteed for the SCIM operations to ensure that only authenticated entities can perform the SCIM requests and the requested SCIM operations are authorized.
必须保证SCIM操作的身份验证和授权，以确保只有经过身份验证的实体才能执行SCIM请求，并且所请求的SCIM操作得到授权。
SCIM resources (e.g., Users and Groups) can contain sensitive information. Thus, data confidentiality MUST be guaranteed at the transport layer.
SCIM资源（例如，用户和组）可能包含敏感信息。因此，必须在传输层保证数据的机密性。
There can be privacy issues that go beyond transport security, e.g., moving personally identifying information (PII) offshore between CSPs. Regulatory requirements shall be met when migrating identity information between jurisdictional regions (e.g., countries and states may have differing regulations on privacy).
可能存在超越运输安全的隐私问题，例如，在CSP之间将个人识别信息（PII）转移到海上。在管辖区域之间迁移身份信息时，应满足监管要求（例如，国家和州可能有不同的隐私法规）。
Additionally, privacy-sensitive data elements may be omitted or obscured in SCIM transactions or stored records to protect these data elements for a user. For instance, a role-based identifier might be used in place of an individual's name.
此外，在SCIM事务或存储记录中，可能会省略或隐藏隐私敏感数据元素，以保护用户的这些数据元素。例如，可以使用基于角色的标识符来代替个人姓名。
Detailed security considerations are specified in Section 7 of the SCIM protocol [RFC7644] and Section 9 of the SCIM schema [RFC7643].
SCIM协议[RFC7644]第7节和SCIM模式[RFC7643]第9节规定了详细的安全注意事项。
[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>.
[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.，和C.Mortimore，“跨域身份管理系统：核心模式”，RFC 7643，DOI 10.17487/RFC7643，2015年9月<http://www.rfc-editor.org/info/rfc7643>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, <http://www.rfc-editor.org/info/rfc7644>.
[RFC7644]Hunt，P.，Ed.，Grizzle，K.，Ansari，M.，Wahlstroem，E.，和C.Mortimore，“跨域身份管理系统：协议”，RFC 7644，DOI 10.17487/RFC76442015年9月<http://www.rfc-editor.org/info/rfc7644>.
Acknowledgments
致谢
The authors would like to thank Ray Counterman, Richard Fiekowsky, Bert Greevenbosch, Barry Leiba, Kelly Grizzle, Magnus Nystrom, Stephen Farrell, Kathleen Moriarty, Benoit Claise, Dapeng Liu, and Jun Li for their reviews and comments.
作者要感谢Ray Counterman、Richard Fiekowsky、Bert Greevenbosch、Barry Leiba、Kelly Grizzle、Magnus Nystrom、Stephen Farrell、Kathleen Moriarty、Benoit Claise、刘大鹏和李军的评论和评论。
Also, thanks to Darran Rolls and Patrick Harding; Section 2 ("SCIM User Scenarios") is taken from them.
此外，多亏了达兰·罗尔斯和帕特里克·哈丁；第2节（“SCIM用户场景”）取自这些场景。
Authors' Addresses
作者地址
Kepeng LI (editor) Alibaba Group 969 Wenyixi Road, Yuhang District Hangzhou, Zhejiang 311121 China
李克鹏（编辑）阿里巴巴集团中国浙江省杭州市余杭区文一西路969号311121
Email: kepeng.lkp@alibaba-inc.com
Email: kepeng.lkp@alibaba-inc.com
Phil Hunt Oracle
菲尔·亨特神谕
Email: phil.hunt@oracle.com
Email: phil.hunt@oracle.com
Bhumip Khasnabish ZTE (TX) Inc. 55 Madison Ave, Suite 302 Morristown, New Jersey 07960 United States
普密普哈斯纳比什中兴通讯（德克萨斯）有限公司，美国新泽西州莫里斯镇麦迪逊大道55号302室，邮编：07960
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Anthony Nadalin Microsoft
安东尼·纳达林微软
Email: tonynad@microsoft.com
Email: tonynad@microsoft.com
Zachary Zeltsan Individual
扎卡里·泽尔赞个人
Email: Zachary.Zeltsan@gmail.com
Email: Zachary.Zeltsan@gmail.com