idnits 2.17.1 draft-ietf-scim-use-cases-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2015) is 3276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-scim-api-17 == Outdated reference: A later version (-22) exists of draft-ietf-scim-core-schema-18 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SCIM WG K. LI, Ed. 3 Internet-Draft Alibaba Group 4 Intended status: Informational P. Hunt 5 Expires: November 8, 2015 Oracle 6 B. Khasnabish 7 ZTE (TX) Inc. 8 A. Nadalin 9 Microsoft 10 Z. Zeltsan 11 Individual 12 May 7, 2015 14 SCIM Definitions, Overview, Concepts and Requirements 15 draft-ietf-scim-use-cases-08 17 Abstract 19 This document provides definitions and an overview of the System for 20 Cross-domain Identity Management (SCIM). It lays out the system's 21 concepts, models and flows, and includes user scenarios, use cases, 22 and requirements. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 8, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Background & Context . . . . . . . . . . . . . . . . . . . 4 62 2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2.3. Modes & Flows . . . . . . . . . . . . . . . . . . . . 6 66 2.2.4. Bulk & Batch Operational Semantics . . . . . . . . . . 7 67 2.3. Cloud Service Provider to Cloud Service Provider Flows 68 (CSP->CSP) . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.3.1. CSP->CSP - Create Identity (Push) . . . . . . . . . . 7 70 2.3.2. CSP->CSP - Update Identity (Push) . . . . . . . . . . 7 71 2.3.3. CSP->CSP - Delete Identity (Push) . . . . . . . . . . 8 72 2.3.4. CSP->CSP - SSO Trigger (Push) . . . . . . . . . . . . 8 73 2.3.5. CSP->CSP - SSO Trigger (Pull) . . . . . . . . . . . . 8 74 2.3.6. CSP->CSP - Password Reset (Push) . . . . . . . . . . . 9 75 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 76 Flows(ECS->CSP) . . . . . . . . . . . . . . . . . . . . . 9 77 2.4.1. ECS->CSP - Create Identity (Push) . . . . . . . . . . 9 78 2.4.2. ECS ->CSP - Update Identity (Push) . . . . . . . . . . 9 79 2.4.3. ECS ->CSP - Delete Identity (Push) . . . . . . . . . . 10 80 2.4.4. ECS ->CSP - SSO Pull . . . . . . . . . . . . . . . . . 10 81 3. SCIM Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.1. Migration of the identities . . . . . . . . . . . . . . . 10 83 3.2. Single Sign-On (SSO) Service . . . . . . . . . . . . . . . 11 84 3.3. Provisioning of the user accounts for a Community of 85 Interest (CoI) . . . . . . . . . . . . . . . . . . . . . . 13 86 3.4. Transfer of attributes to a relying party web site . . . . 14 87 3.5. Change notification . . . . . . . . . . . . . . . . . . . 15 88 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 89 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 This document provides the SCIM definitions, overview, concepts, 99 flows, scenarios and use cases. It also provides a list of the 100 requirements derived from the use cases. 102 The document's objective is to help with understanding of the design 103 and applicability of SCIM schema [I-D.ietf-scim-core-schema] and SCIM 104 protocol [I-D.ietf-scim-api]. 106 Unlike the practice of some protocols like ABFAB and SAML2 WebSSO, 107 SCIM provides provisioning and de-provisioning of resources in a 108 separate context from authentication (aka just-in-time provisioning). 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119] when they 115 appear in ALL CAPS. These words may also appear in this document in 116 lower case as plain English words, absent their normative meanings. 118 Here is a list of acronyms and abbreviations used in this document: 120 o COI: Community Of Interest 122 o CRM: Customer Relationship Management 124 o CRUD: Create Read Update Delete 126 o CSP: Cloud Service Provider 128 o CSU: Cloud Service User 130 o ECS: Enterprise Cloud Subscriber 132 o IaaS: Infrastructure as a Service 134 o JIT: Just In Time 136 o PaaS: Platform as a Service 138 o SaaS: Software as a Service 140 o SAML: Security Assertion Markup Language 142 o SCIM: System for Cross-domain Identity Management 143 o SSO: Single-Sign On 145 2. SCIM User Scenarios 147 2.1. Background & Context 149 The System for Cross-domain Identity Management (SCIM) specification 150 is designed to manage user identity in cloud based applications and 151 services in a standardized way to enable interoperability, security 152 and scalability. The specification suite seeks to build upon 153 experience with existing schemas and deployments, placing specific 154 emphasis on simplicity of development and integration, while applying 155 existing authentication, authorization, and privacy models. The 156 intent of SCIM specification is to reduce the cost and complexity of 157 user management operations by providing a common user schema and 158 extension model, as well as binding documents to provide patterns for 159 exchanging this schema using standard protocols. In essence, make it 160 fast, cheap, and easy to move users in to, out of, and around the 161 cloud. 163 The SCIM scenarios are overview user stories designed to help clarify 164 the intended scope of the SCIM effort. 166 2.2. Model Concepts 168 2.2.1. Triggers 170 Quite simply, triggers are actions or activities that start SCIM 171 flows. Triggers may not be relevant at the protocol or the schema, 172 they really serve to help identify the type or activity that resulted 173 in a SCIM protocol exchange. Triggers make use of the traditional 174 provisioning CRUD (Create Read Update & Delete) operations but add 175 additional use case contexts like "SSO" (Single-Sign On) as it is 176 designed to capture a class of use case that makes sense to the actor 177 requesting it rather than to describe a protocol operation. 179 o Create SCIM Identity Resource - Service On-boarding Trigger: A 180 "create SCIM identity resource" trigger is a service on-boarding 181 activity in which a business action such as a new hire or new 182 service subscription is initiated by one of the SCIM Actors. In 183 the protocol itself, service on-boarding may well be implemented 184 via the same resource PUT method as a service change. This is 185 particular to the implementation, and not to the use cases that 186 drive that implementation. 188 o Update SCIM Identity Resource - Service Change Trigger: An "update 189 SCIM identity resource" trigger is a service change activity as a 190 result of an identity moving or changing its service level. An 191 "update SCIM identity" trigger might be the result of a change in 192 a service subscription level or a change to key identity data used 193 to denote a service subscription level. Password changes are 194 specifically called out from other more general identity attribute 195 changes as they are considered to have specific use case 196 differences. 198 o Delete SCIM Identity Resource - Service Termination Trigger: A 199 "delete SCIM identity resource" trigger represents a specific and 200 deliberate action to remove an identity from a given SCIM service 201 point. At this stage it is unclear if the SCIM protocol needs to 202 identify separate protocol exchange for a service suspension 203 actions. This may be relevant as target services usually 204 differentiate between these result and may require separate 205 resource representations as a result. 207 o Single-Sign On (SSO) Trigger - Service Access Request: A "Single- 208 Sign On" trigger is a special class of activity in which a Create 209 or Update trigger is initiated during an SSO operational flow. 210 The implication here is that as the result of a service access 211 request by the end user (SSO), defined SCIM protocol exchanges can 212 be used to initiate SCIM resource CRUD somewhere in the service 213 cloud. 215 2.2.2. Actors 217 Actors are the operating parties that take part in both sides of a 218 SCIM protocol exchange, and help identify the source of a given 219 Trigger. So far, we have identified the following SCIM Actors: 221 o Cloud Service Provider (CSP): A CSP is the entity operating a 222 given cloud service. In a SaaS scenario this is simply the 223 application provider. In an IaaS or PaaS scenario, the CSP may be 224 the underlying IaaS/PaaS infrastructure provider or the owner of 225 the application running on that platform. In all cases, the CSP 226 is the thing that holds the identity information being operated 227 upon. Put another way, the CSP really is the service that the 228 end-end user interacts with. 230 o Enterprise Cloud Subscriber (ECS): An ECS represents a middle-tier 231 of aggregation for related identity records. In one of our sample 232 enterprise SaaS scenarios, the ECS is "Example.com" that 233 subscribes to a cloud based CRM service service "SaaS-CRM.Inc" 234 (the CSP) for all of its sales staff. The actual Cloud Service 235 Users (CSUs) are the FooBar.Inc. sales staff. The ECS actor is 236 identified to help capture use cases in which a single entity is 237 given administrative responsibility for other identity accounts. 239 SCIM may not address the configuration and setup of an ECS within 240 the CSP, but it does address use cases in which SCIM identity 241 resources are grouped together and administers as part of some 242 broader agreement or operational exchange. 244 o Cloud Service User (CSU): A CSU represents the real cloud service 245 end user - the "person logging into and using the cloud service". 246 As described above, and ECS will typically own or manage multiple 247 CSU identities where as the CSU represents the FooBar.Inc. 248 employee using the cloud service to manage their CRM process. 250 +---------------------+ 251 | Cloud Service | 252 | Provider (CSP) | 253 +---------------------+ 254 | 255 +--------------------------------+ 256 | | 257 v v 258 +----------------+ +----------------+ 259 |Enterprise Cloud| |Enterprise Cloud| 260 |Subscriber (ECS)| |Subscriber (ECS | 261 +----------------+ +----------------+ 262 | | 263 +----------------+ +----------------+ 264 | | | | 265 v v v v 266 +-------------+ +-------------+ +-------------+ +-------------+ 267 |Cloud Service| |Cloud Service| |Cloud Service| |Cloud Service| 268 | User (CSU) | | User (CSU) | | User (CSU) | | User (CSU) | 269 +-------------+ +-------------+ +-------------+ +-------------+ 271 Figure 1: SCIM Actors 273 2.2.3. Modes & Flows 275 Modes identify the functional intent of a data-flow initiated in a 276 SCIM scenario. The modes identified so far are 'push' and 'pull' 277 referring to the fact of pushing data to, or pulling data from an 278 authoritative identity data store. 280 In the SCIM scenarios, Modes are often used in the context of a flow 281 between two Actors. For example, one might refer to a Cloud-to-Cloud 282 Pull exchange. Here one Cloud Service Provider (CSP) is pulling 283 identity information from another CSP. Commonly referenced flows 284 are: 286 o Cloud Service Provider to Cloud Service Provider (CSP->CSP) 288 o Enterprise Cloud Subscriber to Cloud Service Provider (ECS-CSP) 290 Modes & flows simply help us understand what is taking place; they 291 are likely to be technically meaningless at the protocol level, but 292 again they help the reader follow the SCIM scenarios and apply them 293 to real world use cases. 295 2.2.4. Bulk & Batch Operational Semantics 297 It is assumed that each of the triggers action outlined in this 298 document may be part of the larger bulk or batch operation. 299 Individual SCIM actions should be able to be collected together to 300 create single protocol exchanges. 302 The initial focus of SCIM scenarios is on identifying base flows and 303 single operations. The specific complexity of full bulk and batch 304 operations is left to a later version of the scenarios or to the main 305 specification. 307 2.3. Cloud Service Provider to Cloud Service Provider Flows (CSP->CSP) 309 These scenarios represent flows between two Cloud Service Providers 310 (CSPs). It is assumed that each CSP maintains an Identity Data Store 311 for its Cloud Service Users (CSUs). These scenarios address various 312 joiner, mover, leaver and JIT triggers, resulting in push and pull 313 data exchanges between the CSPs. 315 2.3.1. CSP->CSP - Create Identity (Push) 317 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 318 agreement in place that requires the exchange of Cloud Service User 319 (CSU) accounts. CSP-1 receives a Create Identity trigger action from 320 its Enterprise Cloud Subscriber (ECS-1). CSP-1 creates a local user 321 account for the new CSU. CSP-1 then pushes the new CSU joiner push 322 request down-stream to CSU-2 and gets confirmation that the account 323 was successfully created. After receiving the confirmation from 324 CSP-2, CSP-1 sends an acknowledgement to the requesting ECS. 326 2.3.2. CSP->CSP - Update Identity (Push) 328 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 329 agreement in place that requires the exchange of Cloud Service User 330 (CSU) accounts. The Enterprise Cloud Subscriber (ECS-1) has already 331 created an account with CSP-1 and supplied a critical attribute 332 "department" that is used by CSP-1 to drive service options. CSP-1 333 then receives an Update Identity trigger action from its Enterprise 334 Cloud Subscriber (ECS). CSP-1 updates its local directory account 335 with the new department value. CSP-1 then initiates a separate SCIM 336 protocol exchange to push the mover change request down-stream to 337 CSP-2. After receiving the confirmation from CSP-2, CSP-1 sends an 338 acknowledgment to ECS-1. 340 2.3.3. CSP->CSP - Delete Identity (Push) 342 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 343 agreement in place that requires the exchange of Cloud Service User 344 (CSU) accounts. CSP-1 receives a Delete Identity trigger action from 345 its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local 346 directory account for the specified CSU account. CSP-1 then pushes a 347 termination request for the specified CSU account down-stream to 348 CSP-2 and gets confirmation that the account was successfully 349 removed. After receiving the confirmation from CSP-2, CSP-1 350 finalizes the deletion operation and sends an acknowledgment to the 351 requesting ECS. 353 This use case highlights how different CSPs may implement different 354 operational semantics behind the same SCIM operation. Note CSP-1 355 suspends the account representation for its service where as CPS-2 356 implements a true delete operation. 358 2.3.4. CSP->CSP - SSO Trigger (Push) 360 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 361 agreement in place that requires the exchange of Cloud Service User 362 (CSU) accounts. However, rather than pre-provisioning accounts from 363 CSP-1 to CSP-2, CSP-1 waits for a service access request from the end 364 Cloud Service User (CSU-1) before issuing account creation details to 365 CSP-2. When the CSU completes a SSO transaction from CSP-1 to CSP-2, 366 CSP-2 then creates an account for the CSU based on information pushed 367 to it from CSP-1. 369 At the protocol level, this class of scenarios may result in the use 370 of common protocol exchange patterns between CSP-1 & CSP-2. 372 2.3.5. CSP->CSP - SSO Trigger (Pull) 374 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 375 agreement in place that requires the exchange of Cloud Service User 376 (CSU) accounts. However, rather than pre-provisioning accounts from 377 CSP-1 to CSP-2, CSP-2 waits for a service access request from the 378 Cloud Service User (CSU-1) before initiating a Pull request to gather 379 information about the CSU sufficient to create a local account. 381 At the protocol level, this class of scenarios may result in the use 382 of common protocol exchange patterns between CSP-2 & CSP-1. 384 2.3.6. CSP->CSP - Password Reset (Push) 386 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 387 agreement in place that requires the exchange of Cloud Service User 388 (CSU) accounts. CSP-1 wants to change the password for a specific 389 Cloud Service User (CSU-1). CSP-1 sends a request to CSP-2 to reset 390 the password value for CSU-1. 392 At the protocol level, this scenario may result in the same protocol 393 exchange as any other attribute change request. 395 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 396 Flows(ECS->CSP) 398 These scenarios represent flows between an Enterprise Cloud 399 Subscriber (ECS) and a Cloud Service Providers (CSP). It is assumed 400 that both the ECS and the CSP maintains an information access service 401 for the relevant Cloud Service Users (CSUs). These scenarios address 402 various joiner, mover, leaver and JIT triggers, resulting in push and 403 pull data exchanges between the ECS and the CSP. 405 Many of these scenarios are very similar to those defined in the 406 Cloud Service Provider to Cloud Service Provider section above. They 407 are identified separately here so that we may explore any differences 408 and might emerge. 410 2.4.1. ECS->CSP - Create Identity (Push) 412 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 413 service with a Cloud Service Provider (CSP-1) that requires the 414 sharing of various Cloud Service User (CSU) accounts. A new user 415 joins ECS-1 and so ECS-1 pushes an account creation request to CSP-1, 416 supplying all required base SCIM schema attribute values and 417 additional extended SCIM schema values as required. 419 2.4.2. ECS ->CSP - Update Identity (Push) 421 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 422 service with Cloud Service Provider (CSP-1) that drives service 423 definition from a key account schema attribute called Department. 424 ECS-1 wishes to move a given CSU from Department A to Department B 425 and so it pushes an attribute update request to the CSP. 427 2.4.3. ECS ->CSP - Delete Identity (Push) 429 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 430 service with a Cloud Service Provider (CSP-1). Upon termination of 431 one of its employees' employment agreement, ECS-1 sends a suspend 432 account request to CSP-1 (Figure 1.4.3-1). One week later the ECS 433 wishes to complete the process by fully removing the Cloud Service 434 User (CSU) account and so it sends a terminate account request to 435 CSP-1. 437 2.4.4. ECS ->CSP - SSO Pull 439 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 440 service with a Cloud Service Provider (CSP-1). No accounts are 441 created or exchanged in advance. However, rather than pre- 442 provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service 443 access request from the Cloud Service User (CSU-1) under the control 444 domain of ECS-1, before issuing an account Pull request to ECS-1. 446 3. SCIM Use Cases 448 This section lists the SCIM use cases. 450 3.1. Migration of the identities 452 Description: 454 A company SomeEnterprise runs an application ManageThem that relies 455 on the identity information about its employees (e.g., identifiers, 456 attributes). The identity information is stored at the cloud 457 provided by SomeCSP. SomeEnterprise has decided to move identity 458 information to the cloud of a different provider - AnotherCSP. In 459 addition, SomeEnterprise has purchased a second application 460 ManageThemMore, which also relies on the identity information. 461 SomeEnterprise is able to move identity information to AnotherCSP 462 without changing the format of identity information. The application 463 ManageThemMore is able to use the identity information. 465 Pre-conditions: 467 o SomeCSP is a cloud service provider for SomeEnterprise. 469 o SomeCSP has a known attribute name and value for the Enterprise 470 used for managing and transferring data. 472 o AnotherCSP is a new cloud service provider for SomeEnterprise. 474 o All involved cloud service providers and applications support the 475 same standard specifying the format for and actions on the user 476 (e.g., employee) identity information. 478 Post-conditions: 480 o SomeEnterprise has moved its employees' identity information from 481 SomeCSP to AnotherCSP without making any changes to representation 482 of identity information. 484 o Application ManageThemMore is able to use the identity 485 information. 487 Requirements: 489 o SomeEnterprise, the applications ManageThem and ManageThemMore, 490 the providers SomeCSP and AnotherCSP support a common standard for 491 identity information, which specifies the following: 493 * Format (or schema) for representing user identity information 495 * Interfaces and protocol for managing user identity information 497 o Cloud providers shall be able to meet regulatory requirements when 498 migrating identity information between jurisdictional regions 499 (countries, state-by-state for regulations on privacy). 501 o Cloud providers shall be able to log all actions related to 502 SomeEnterprise employees' identities. 504 o The logs should be secure and available for auditing. 506 3.2. Single Sign-On (SSO) Service 508 Description: 510 Bob has an account with application hosted by a cloud service 511 provider SomeCSP. SomeCSP has federated its user identities with a 512 cloud service provider AnotherCSP. Bob requests a service from an 513 application running on AnotherCSP. The application running on 514 AnotherCSP, relying on Bob's authentication by SomeCSP and using 515 identity information provided by SomeCSP, serves Bob's request. 517 Pre-conditions: 519 o Bob's identity information is stored on SomeCSP. 521 o SomeCSP and AnotherCSP have established trust and federated their 522 user identities. 524 o SomeCSP is able to authenticate Bob. 526 o SomeCSP is able to securely provide the authentication results to 527 AnotherCSP. 529 o SomeCSP is able to securely provide Bob's identity information 530 (e.g., attributes) to AnotherCSP. 532 o AnotherCSP is able to verify information provided by SomeCSP. 534 o SomeCSP is able to process the identity information received from 535 AnotherCSP. 537 Post-conditions: 539 Bob has received the requested service from an application running on 540 AnotherCSP without having to authenticate to that application 541 explicitly. 543 Requirements: 545 o Bob must have an account with SomeCSP. 547 o SomeCSP and AnotherCSP must establish trust and federate their 548 user identities. 550 o SomeCSP must be able to authenticate Bob. 552 o SomeCSP must be able to securely provide the authentication 553 results to AnotherCSP. 555 o SomeCSP must be able to securely provide Bob's identity 556 information (e.g., attributes) to AnotherCSP. 558 o AnotherCSP must be able to verify the identity information 559 provided by SomeCSP. 561 o SomeCSP must be able to process the identity information received 562 from AnotherCSP. 564 o SomeCSP and AnotherCSP must log information generated by Bob's 565 actions according to their policies and the trust agreement 566 between them. 568 3.3. Provisioning of the user accounts for a Community of Interest 569 (CoI) 571 Description: 573 Organization YourHR provides Human Resources (HR) services to a 574 Community of Interest (CoI) YourCoI. The HR services are offered as 575 Software-as-a-Service (SaaS) on public and private clouds. YourCoI's 576 offices are located all over the world. Their Information Technology 577 (IT) systems may be composed of the combinations of the applications 578 running on Private and Public clouds along with the traditional IT 579 systems. The local YourCoI offices are responsible for collecting 580 personal information(i.e. user identities and attributes). YourHR 581 services provide means for provisioning and distributing the employee 582 identity information across all YourCoI offices. YourHR also enables 583 the individual users (e.g., employees) to manage their personal 584 information that they are responsible for (e.g., update of an address 585 or a telephone number). 587 Pre-conditions: 589 o YourCoI has a complex infrastructure composed of the large number 590 of local offices that rely on the diverse IT systems. 592 o YourCoI has contracted YourHR to provide the HR services. 594 o Each local office has a right to establish a personal account for 595 an employee. 597 Post-conditions: 599 o All personal accounts are globally available to any authorized 600 user or application across the YourCoI system through the services 601 provided by YourHR. 603 o The employees have ability to manage the part of personal 604 information that is in their responsibility. 606 Requirements: 608 o Your HR must ensure that information generated by the local 609 offices is provisioned securely and considers privacy requirements 610 in a timely fashion across systems that may span technical (e.g., 611 protocols and applications), administrative (e.g., corporate), 612 regulatory (e.g. location) and jurisdictional domains. 614 o Management of personal information must be protected against 615 unauthorized access, eavesdropping, and should be distributed only 616 to authorized parties and services. 618 o Regulatory requirements shall be met when migrating identity 619 information between jurisdictional regions (countries, state-by- 620 state for regulations on privacy). 622 o All operation with identity data must be securely logged. 624 o The logs should be available for auditing. 626 3.4. Transfer of attributes to a relying party web site 628 Description: 630 An end user has an account in a directory service A with one or more 631 attributes. That user then visits relying party web site B, and the 632 web site B requires attributes of the user. The user selectes some 633 attributes and authorizes the transfer of data via authorization 634 protocols (e.g. OAuth, SAML), so selected attributes of the user are 635 transferred from the user's account in directory service A to the web 636 site B at the time of the user's first visit to that site. 638 Pre-conditions: 640 o User has an account in a directory service A. 642 o User has one or more attributes. 644 o User visits web site of a relying party B. 646 Post-conditions: 648 Selected attributes of the user are transferred from the user's 649 account in directory service A to the web site B at the time of the 650 user's first visit to that site. 652 Requirements: 654 o Relying party B must be able to authenticate the end user. 656 o Relying party B must be able to securely provide the 657 authentication results to directory service A. 659 o Directory service A must be able to securely provide end user's 660 identity information (e.g., attributes) to relying party B. 662 o Regulatory requirements shall be met when migrating identity 663 information between jurisdictional regions (countries, state-by- 664 state for regulations on privacy). 666 o Relying parties have to be aware of changes to their cached copy, 667 as these would potentially cause a state change in other relying 668 parties. 670 o A maximum period should be set for the relying party to cache the 671 information. 673 3.5. Change notification 675 Description: 677 An end user has an account in a directory service A with one or more 678 attributes. That user then visits relying party web site B. Relying 679 party web site B queries directory service A for attributes 680 associated with that user, and related resources. 682 The attributes of the user change later in directory service A. For 683 example, the attributes might change if the user changes their name, 684 has their account disabled, or terminates their relationship with 685 directory service A. Furthermore, other resources and their 686 attributes might also change. The directory service A then wishes to 687 notify relying party web site B of these changes, as relying party B 688 might (or might not) have a cache of those attributes, and if the 689 relying party B were aware of these changes to their cached copy, 690 would potentially cause a state change in relying party B. 692 The volume of changes, however, might be substantial, and only some 693 of the changes may be of interest to relying party B, so directory 694 service A does not wish to "push" all the changes to B. Instead, 695 directory service A wishes to notify B that there are changes 696 potentially of interest, such that B can at an appropriate time 697 subsequently contact directory service A and retrieve just the subset 698 of changes of interest to B. 700 Note that the user must authorize the directory service A to transfer 701 data to the web site, and the user must authorize the directory 702 service A to notify the web site. 704 Pre-conditions: 706 o User has an account in a directory service A. 708 o User has one or more attributes. 710 o User visits relying party web site B. 712 o The resource being updated is at the web site. 714 Post-conditions: 716 Directory service A is able to notify relying party B that there are 717 changes potentially of interest. 719 Requirements: 721 o Relying party B must be able to authenticate the end user. 723 o Relying party B must be able to securely provide the 724 authentication results to directory service A. 726 o Directory service A must be able to securely provide end user's 727 changed identity information (e.g., attributes) to relying party 728 B. 730 o Relying party B must be able at an appropriate time to 731 subsequently contact directory service A and retrieve just the 732 subset of changes of interest to relying party B. 734 4. Security considerations 736 Authentication and authorization must be guaranteed for the SCIM 737 operations, to ensure that only authenticated entities can perform 738 the SCIM requests and the requested SCIM operations are authorized. 740 SCIM resources (e.g., Users and Groups) can contain sensitive 741 information. Thus, data confidentiality MUST be guaranteed at the 742 transport layer. 744 There can be privacy issues that go beyond transport security, e.g. 745 moving PII offshore between CSPs. Regulatory requirements shall be 746 met when migrating identity information between jurisdictional 747 regions (countries, state-by-state for regulations on privacy. 749 Additionally, privacy sensitive data elements may be omitted or 750 obscured in SCIM transactions or stored records to protect these data 751 elements for a user. For instance a role based identifier might be 752 used in place of an individual's name. 754 Detailed security considerations are specified in section 7 of SCIM 755 protocol [I-D.ietf-scim-api] and section 9 of SCIM schema 756 [I-D.ietf-scim-core-schema]. 758 5. IANA considerations 760 This Internet Draft includes no request to IANA. 762 6. Acknowledgements 764 Authors would like to thank Ray Counterman, Richard Fiekowsky, Bert 765 Greevenbosch, Barry Leiba, Kelly Grizzle, Magnus Nystrom, Stephen 766 Farrell, Kathleen Moriarty, Benoit Claise, Dapeng Liu and Jun Li for 767 their reviews and comments. 769 Also thanks to Darran Rolls and Patrick Harding, the SCIM user 770 scenarios section is taken from them. 772 7. References 774 7.1. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, March 1997. 779 7.2. Informative References 781 [I-D.ietf-scim-api] 782 Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C. 783 Mortimore, "System for Cross-Domain Identity Management: 784 Protocol", draft-ietf-scim-api-17 (work in progress), 785 April 2015. 787 [I-D.ietf-scim-core-schema] 788 Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore, 789 "System for Cross-Domain Identity Management: Core 790 Schema", draft-ietf-scim-core-schema-18 (work in 791 progress), April 2015. 793 Authors' Addresses 795 Kepeng LI (editor) 796 Alibaba Group 797 Wenyixi Road, Yuhang District 798 Hangzhou, Zhejiang 311121 799 China 801 Email: kepeng.lkp@alibaba-inc.com 802 Phil Hunt 803 Oracle 805 Email: phil.hunt@oracle.com 807 Bhumip Khasnabish 808 ZTE (TX) Inc. 809 55 Madison Ave, Suite 302 810 Morristown, New Jersey 07960 811 USA 813 Phone: +001-781-752-8003 814 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 815 URI: http://tinyurl.com/bhumip/ 817 Anthony Nadalin 818 Microsoft 820 Email: tonynad@microsoft.com 822 Zachary Zeltsan 823 Individual 825 Email: Zachary.Zeltsan@gmail.com