doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7642.txt b/doc/rfc/rfc7642.txt
new file mode 100644
index 0000000..c19243c
--- /dev/null
+++ b/doc/rfc/rfc7642.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                     [Page 1]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                     [Page 2]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                     [Page 3]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+1.  Introduction
+
+   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.
+
+   The document's objective is to help with understanding of the design
+   and applicability of the SCIM schema [RFC7643] and SCIM protocol
+   [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).
+
+1.1.  Terminology
+
+   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.
+
+   Here is a list of acronyms and abbreviations used in this document:
+
+   o  COI: Community of Interest
+
+   o  CRM: Customer Relationship Management
+
+   o  CRUD: Create, Read, Update, Delete
+
+   o  CSP: Cloud Service Provider
+
+   o  CSU: Cloud Service User
+
+   o  ECS: Enterprise Cloud Subscriber
+
+   o  IaaS: Infrastructure as a Service
+
+   o  JIT: Just In Time
+
+   o  PaaS: Platform as a Service
+
+   o  SaaS: Software as a Service
+
+   o  SAML: Security Assertion Markup Language
+
+
+
+
+
+LI, et al.                    Informational                     [Page 4]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   o  SCIM: System for Cross-domain Identity Management
+
+   o  SSO: Single Sign-On
+
+2.  SCIM User Scenarios
+
+2.1.  Background and Context
+
+   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.
+
+   The SCIM scenarios are overviews of user stories designed to help
+   clarify the intended scope of the SCIM effort.
+
+2.2.  Model Concepts
+
+2.2.1.  Triggers
+
+   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.
+
+   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.
+
+
+
+
+LI, et al.                    Informational                     [Page 5]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   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  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  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.
+
+2.2.2.  Actors
+
+   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:
+
+   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  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
+
+
+
+LI, et al.                    Informational                     [Page 6]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+      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.
+
+   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.
+
+                           +---------------------+
+                           |   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
+
+2.2.3.  Modes and Flows
+
+   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.
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                     [Page 7]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   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:
+
+   o  Cloud Service Provider to Cloud Service Provider (CSP->CSP)
+
+   o  Enterprise Cloud Subscriber to Cloud Service Provider (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.
+
+2.2.4.  Bulk and Batch Operational Semantics
+
+   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.
+
+   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.
+
+2.3.  Flows from Cloud Service Provider to Cloud Service Provider
+      (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.
+
+2.3.1.  CSP->CSP: Create Identity (Push)
+
+   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.
+
+
+
+
+
+LI, et al.                    Informational                     [Page 8]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+2.3.2.  CSP->CSP: Update Identity (Push)
+
+   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.
+
+2.3.3.  CSP->CSP: Delete Identity (Push)
+
+   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.
+
+   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.
+
+2.3.4.  CSP->CSP: SSO Trigger (Push)
+
+   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.
+
+   At the protocol level, this class of scenarios may result in the use
+   of common protocol exchange patterns between CSP-1 and CSP-2.
+
+
+
+
+
+
+
+LI, et al.                    Informational                     [Page 9]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+2.3.5.  CSP->CSP: SSO Trigger (Pull)
+
+   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.
+
+   At the protocol level, this class of scenarios may result in the use
+   of common protocol exchange patterns between CSP-2 and CSP-1.
+
+2.3.6.  CSP->CSP: Password Reset (Push)
+
+   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.
+
+   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)
+
+   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.
+
+   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.4.1.  ECS->CSP: Create Identity (Push)
+
+   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.
+
+
+
+
+
+
+LI, et al.                    Informational                    [Page 10]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+2.4.2.  ECS->CSP: Update Identity (Push)
+
+   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.
+
+2.4.3.  ECS->CSP: Delete Identity (Push)
+
+   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.
+
+2.4.4.  ECS->CSP: SSO Trigger (Pull)
+
+   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.
+
+3.  SCIM Use Cases
+
+   This section lists the SCIM use cases.
+
+3.1.  Migration of the Identities
+
+   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.
+
+   Pre-conditions:
+
+   o  SomeCSP is a cloud service provider for SomeEnterprise.
+
+
+
+LI, et al.                    Informational                    [Page 11]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   o  SomeCSP has a known attribute name and value for the Enterprise
+      used for managing and transferring data.
+
+   o  AnotherCSP is a new cloud service provider for SomeEnterprise.
+
+   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.
+
+   Post-conditions:
+
+   o  SomeEnterprise has moved its employees' identity information from
+      SomeCSP to AnotherCSP without making any changes to representation
+      of identity information.
+
+   o  Application ManageThemMore is able to use the identity
+      information.
+
+   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:
+
+      *  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  Cloud providers shall be able to log all actions related to
+      SomeEnterprise employees' identities.
+
+   o  The logs should be secure and available for auditing.
+
+3.2.  Single Sign-On (SSO) Service
+
+   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.
+
+
+
+LI, et al.                    Informational                    [Page 12]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   Pre-conditions:
+
+   o  Bob's identity information is stored on SomeCSP.
+
+   o  SomeCSP and AnotherCSP have established trust and federated their
+      user identities.
+
+   o  SomeCSP is able to authenticate Bob.
+
+   o  SomeCSP is able to securely provide the authentication results to
+      AnotherCSP.
+
+   o  SomeCSP is able to securely provide Bob's identity information
+      (e.g., attributes) to AnotherCSP.
+
+   o  AnotherCSP is able to verify information provided by SomeCSP.
+
+   o  SomeCSP is able to process the identity information received from
+      AnotherCSP.
+
+   Post-conditions:
+
+   Bob has received the requested service from an application running on
+   AnotherCSP without having to authenticate to that application
+   explicitly.
+
+   Requirements:
+
+   o  Bob must have an account with SomeCSP.
+
+   o  SomeCSP and AnotherCSP must establish trust and federate their
+      user identities.
+
+   o  SomeCSP must be able to authenticate Bob.
+
+   o  SomeCSP must be able to securely provide the authentication
+      results to AnotherCSP.
+
+   o  SomeCSP must be able to securely provide Bob's identity
+      information (e.g., attributes) to AnotherCSP.
+
+   o  AnotherCSP must be able to verify the identity information
+      provided by SomeCSP.
+
+   o  SomeCSP must be able to process the identity information received
+      from AnotherCSP.
+
+
+
+
+
+LI, et al.                    Informational                    [Page 13]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   o  SomeCSP and AnotherCSP must log information generated by Bob's
+      actions according to their policies and the trust agreement
+      between them.
+
+3.3.  Provisioning of the User Accounts for a Community of Interest
+      (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).
+
+   Pre-conditions:
+
+   o  YourCOI has a complex infrastructure composed of a large number of
+      local offices that rely on diverse IT systems.
+
+   o  YourCOI has contracted YourHR to provide the HR services.
+
+   o  Each local office has a right to establish a personal account for
+      an employee.
+
+   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  The employees have the ability to manage the part of personal
+      information that is their responsibility.
+
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                    [Page 14]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   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  Management of personal information must be protected against
+      unauthorized access and eavesdropping, and it should be
+      distributed only to authorized parties and services.
+
+   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  All operations with identity data must be securely logged.
+
+   o  The logs should be available for auditing.
+
+3.4.  Transfer of Attributes to a Relying Party's Website
+
+   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.
+
+   Pre-conditions:
+
+   o  User has an account in directory service A.
+
+   o  User has one or more attributes.
+
+   o  User visits website of relying party B.
+
+   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.
+
+
+
+
+
+LI, et al.                    Informational                    [Page 15]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   Requirements:
+
+   o  Relying party B must be able to authenticate the end user.
+
+   o  Relying party B must be able to securely provide the
+      authentication results to directory service A.
+
+   o  Directory service A must be able to securely provide end user's
+      identity information (e.g., attributes) to relying party 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  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  A maximum period should be set for the relying party to cache the
+      information.
+
+3.5.  Change Notification
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+LI, et al.                    Informational                    [Page 16]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   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.
+
+   Pre-conditions:
+
+   o  User has an account in directory service A.
+
+   o  User has one or more attributes.
+
+   o  User visits the website of relying party B.
+
+   o  The resource being updated is at the website.
+
+   Post-conditions:
+
+   Directory service A is able to notify relying party B that there are
+   changes potentially of interest.
+
+   Requirements:
+
+   o  Relying party B must be able to authenticate the end user.
+
+   o  Relying party B must be able to securely provide the
+      authentication results to directory service 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  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.
+
+4.  Security Considerations
+
+   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 resources (e.g., Users and Groups) can contain sensitive
+   information.  Thus, data confidentiality MUST be guaranteed at the
+   transport layer.
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                    [Page 17]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+   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).
+
+   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.
+
+   Detailed security considerations are specified in Section 7 of the
+   SCIM protocol [RFC7644] and Section 9 of the SCIM schema [RFC7643].
+
+5.  References
+
+5.1.  Normative References
+
+   [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>.
+
+5.2.  Informative References
+
+   [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>.
+
+   [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>.
+
+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.
+
+   Also, thanks to Darran Rolls and Patrick Harding; Section 2 ("SCIM
+   User Scenarios") is taken from them.
+
+
+
+
+
+
+
+LI, et al.                    Informational                    [Page 18]
+
+RFC 7642                    SCIM Requirements             September 2015
+
+
+Authors' Addresses
+
+   Kepeng LI (editor)
+   Alibaba Group
+   969 Wenyixi Road, Yuhang District
+   Hangzhou, Zhejiang  311121
+   China
+
+   Email: kepeng.lkp@alibaba-inc.com
+
+
+   Phil Hunt
+   Oracle
+
+   Email: phil.hunt@oracle.com
+
+
+   Bhumip Khasnabish
+   ZTE (TX) Inc.
+   55 Madison Ave, Suite 302
+   Morristown, New Jersey  07960
+   United States
+
+   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
+
+
+   Zachary Zeltsan
+   Individual
+
+   Email: Zachary.Zeltsan@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+LI, et al.                    Informational                    [Page 19]
+