idnits 2.17.1 draft-ietf-scim-use-cases-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 29, 2013) is 3886 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-01 == Outdated reference: A later version (-22) exists of draft-ietf-scim-core-schema-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SCIM WG P. Hunt 3 Internet-Draft Oracle 4 Intended status: Informational B. Khasnabish 5 Expires: March 02, 2014 ZTE USA,Inc. 6 A. Nadalin 7 Microsoft 8 K. Li 9 Huawei 10 Z. Zeltsan 11 Individual 12 August 29, 2013 14 SCIM Use Cases 15 draft-ietf-scim-use-cases-00 17 Abstract 19 This document lists the user scenarios and use cases of System for 20 Cross-domain Identity Management (SCIM). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 02, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. SCIM User Scenarios . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Background & Context . . . . . . . . . . . . . . . . . . 4 60 2.2. Model Concepts . . . . . . . . . . . . . . . . . . . . . 4 61 2.2.1. Triggers . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3. Modes & Flows . . . . . . . . . . . . . . . . . . . . 6 64 2.2.4. Bulk & Batch Operational Semantics . . . . . . . . . 7 65 2.3. Cloud Service Provider to Cloud Service Provider Flows 66 (CSP->CSP) . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3.1. CSP->CSP - Create Identity (Push) . . . . . . . . . . 7 68 2.3.2. CSP->CSP - Update Identity (Push) . . . . . . . . . . 7 69 2.3.3. CSP->CSP - Delete Identity (Push) . . . . . . . . . . 7 70 2.3.4. CSP->CSP - SSO Trigger (Push) . . . . . . . . . . . . 8 71 2.3.5. CSP->CSP - SSO Trigger (Pull) . . . . . . . . . . . . 8 72 2.3.6. CSP->CSP - Password Reset (Push) . . . . . . . . . . 8 73 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 74 Flows(ECS->CSP) . . . . . . . . . . . . . . . . . . . . . 9 75 2.4.1. ECS->CSP - Create Identity (Push) . . . . . . . . . . 9 76 2.4.2. ECS ->CSP - Update Identity (Push) . . . . . . . . . 9 77 2.4.3. ECS ->CSP - Delete Identity (Push) . . . . . . . . . 9 78 2.4.4. ECS ->CSP - SSO Pull . . . . . . . . . . . . . . . . 9 79 3. SCIM use cases . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. Change of the ownership of a file . . . . . . . . . . . . 10 81 3.2. Migration of the identities . . . . . . . . . . . . . . . 11 82 3.3. Single Sign-On (SSO) Service . . . . . . . . . . . . . . 12 83 3.4. Provisioning of the user accounts for a Community of 84 Interest (CoI) . . . . . . . . . . . . . . . . . . . . . 13 85 3.5. Transfer of attributes to a relying party web site . . . 14 86 3.6. Change notification . . . . . . . . . . . . . . . . . . . 15 87 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 88 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 7.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 96 This document describes the SCIM scenarios and use cases. It also 97 provides a list of the requirements derived from the use cases. The 98 document's objective is to help with understanding of the design and 99 applicability of SCIM schema [I-D.ietf-scim-core-schema] and SCIM 100 protocol [I-D.ietf-scim-api]. 102 The following section provides the abbreviated descriptions of the 103 scenarios and use cases. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119] when they 110 appear in ALL CAPS. These words may also appear in this document in 111 lower case as plain English words, absent their normative meanings. 113 Here is a list of acronyms and abbreviations used in this document: 115 o COI: Community Of Interest 117 o CRM: Customer Relationship Management 119 o CRUD: Create Read Update Delete 121 o CSP: Cloud Service Provider 123 o CSU: Cloud Service User 125 o ECS: Enterprise Cloud Subscriber 127 o IaaS: Infrastructure as a Service 129 o JIT: Just In Time 131 o PaaS: Platform as a Service 133 o SaaS: Software as a Service 135 o SAML: Security Assertion Markup Language 137 o SCIM: System for Cross-domain Identity Management 139 o SSO: Single-Sign On 141 2. SCIM User Scenarios 142 2.1. Background & Context 144 The System for Cross-domain Identity Management (SCIM) specification 145 is designed to make managing user identity in cloud based 146 applications and services easier. The specification suite seeks to 147 build upon experience with existing schemas and deployments, placing 148 specific emphasis on simplicity of development and integration, while 149 applying existing authentication, authorization, and privacy models. 150 It's intent is to reduce the cost and complexity of user management 151 operations by providing a common user schema and extension model, as 152 well as binding documents to provide patterns for exchanging this 153 schema using standard protocols. In essence, make it fast, cheap, 154 and easy to move users in to, out of, and around the cloud. 156 The SCIM scenarios are overview user stories designed to help clarify 157 the intended scope of the SCIM effort. 159 2.2. Model Concepts 161 2.2.1. Triggers 163 Quite simply, triggers are actions or activities that start SCIM 164 flows. Triggers may not be relevant at the protocol or the schema, 165 they really serve to help identity the type or activity that resulted 166 in a SCIM protocol exchange. Triggers make use of the traditional 167 provisioning C.R.U.D (Create Read Update & Delete) operations but add 168 additional use case contexts like "SSO" as it is designed to capture 169 a class of use case that makes sense to the actor requesting it 170 rather than to describe a protocol operation. 172 o Create SCIM Identity Resource - Service On-boarding Trigger: A 173 create SCIM resource trigger is a service on-boarding activity in 174 which a business action such as a new hire or new service 175 subscription is initiated by one of the SCIM Actors. In the 176 protocol itself, service on-boarding may well be implemented via 177 the same resource PUT method as a service change. This is 178 particular to the implementation not to the use cases that drive 179 that implementation. 181 o Update SCIM Identity Resource - Service Change Trigger: An Update 182 SCIM resource trigger is a service change activity as a result of 183 an identity moving or changing its service level. An Update 184 Identity trigger might be the result of a change in a service 185 subscription level or a change to key identity data used to denote 186 a service subscription level. Password changes are specifically 187 called out from other more general identity attribute changes as 188 they are considered to have specific use case differences. 190 o Delete SCIM Identity Resource - Service Termination Trigger: A 191 delete SCIM resource trigger represents a specific and deliberate 192 action to remove an identity from a given SCIM service point. At 193 this stage it is unclear if the SCIM protocol needs to identify 194 separate protocol exchange for a service suspension actions. This 195 may be relevant as target services usually differentiate between 196 these result and may require separate resource representations as 197 a result. 199 o Single-Sign On (SSO) Trigger - Real-time Service Access Request: A 200 SSO trigger is a special class of activity in which a Create or 201 Update trigger is initiated during an SSO operational flow. The 202 implication here is that as the result of a real-time service 203 access request by the end user (SSO), defined SCIM protocol 204 exchanges can be used to initiate SCIM resource CRUD somewhere in 205 the service cloud. 207 2.2.2. Actors 209 Actors are the operating parties that take part in both sides of a 210 SCIM protocol exchange, and help identify the source of a given 211 Trigger. So far, we have identified the following SCIM Actors: 213 o Cloud Service Provider (CSP): A CSP is the entity operating a 214 given cloud service. In a SaaS scenario this is simply the 215 application provider. In an IaaS or PaaS scenario, the CSP may be 216 the underlying IaaS/PaaS infrastructure provider or the owner of 217 the application running on that platform. In all cases, the CSP 218 is the thing that holds the identity information being operated 219 upon. Put another way, the CSP really is the service that the 220 end-end user interacts with. 222 o Enterprise Cloud Subscriber (ECS): An ECS represents a middle-tier 223 of aggregation for related identity records. In one of our sample 224 enterprise SaaS scenarios, the ECS is "FooBar.Inc" that subscribes 225 to a cloud based CRM service service "SaaS-CRM.Inc" (the CSP) for 226 all of its sales staff. The actual Cloud Service Users (CSUs) are 227 the FooBar.Inc. sales staff. The ECS actor is identified to help 228 capture use cases in which a single entitle is given 229 administrative responsibility for other identity accounts. SCIM 230 may not address the configuration and setup of an ECS within the 231 CSP, but it does address use cases in which SCIM identity 232 resources are grouped together and administers as part of some 233 broader agreement or operational exchange. 235 o Cloud Service User (CSU): A CSU represents the real cloud service 236 end-end user - the "person logging into and using the cloud 237 service". As described above, and ECS will typically own or 238 manage multiple CSU identities where as the CSU represents the 239 FooBar.Inc. employee using the cloud service to manage their CRM 240 process. 242 +---------------------+ 243 | Cloud Service | 244 | Provider (CSP) | 245 +---------------------+ 246 | 247 +--------------------------------+ 248 | | 249 v v 250 +----------------+ +----------------+ 251 |Enterprise Cloud| |Enterprise Cloud| 252 |Subscriber (ECS)| |Subscriber (ECS | 253 +----------------+ +----------------+ 254 | | 255 +----------------+ +----------------+ 256 | | | | 257 v v v v 258 +-------------+ +-------------+ +-------------+ +-------------+ 259 |Cloud Service| |Cloud Service| |Cloud Service| |Cloud Service| 260 | User (CSU) | | User (CSU) | | User (CSU) | | User (CSU) | 261 +-------------+ +-------------+ +-------------+ +-------------+ 263 Figure 1: SCIM Actors 265 2.2.3. Modes & Flows 267 Modes identify the functional intent of a data-flow initiated in a 268 SCIM scenario. The modes identified so far are 'push' and 'pull' 269 referring to the fact of pushing data to, or pulling data from an 270 authoritative identity data store. 272 In the SCIM scenarios, Modes are often used in the context of a flow 273 between two Actors. For example, one might refer to a Cloud-to-Cloud 274 Pull exchange. Here one Cloud Service Provider (CSP) is pulling 275 identity information from another CSP. Commonly referenced flows 276 are: 278 o Cloud Service Provider to Cloud Service Provider (CSP->CSP) 280 o Enterprise Cloud Subscriber to Cloud Service Provider (ECS-CSP) 282 Modes & flows simply help us understand what is taking place; they 283 are likely to be technically meaningless at the protocol level, but 284 again they help the reader follow the SCIM scenarios and apply them 285 to real work use cases. 287 2.2.4. Bulk & Batch Operational Semantics 289 It is assumed that each of the triggers action outlined in this 290 document may be part of the larger bulk or batch operation. 291 Individual SCIM actions should be able to be collected together to 292 create single protocol exchanges. 294 The initial focus of SCIM scenarios is on identifying base flows and 295 single operations. The specific complexity of full bulk and batch 296 operations is left to a later version of the scenarios or to the main 297 specification. 299 2.3. Cloud Service Provider to Cloud Service Provider Flows (CSP->CSP) 301 These scenarios represent flows between two Cloud Service Providers 302 (CSPs). It is assumed that each CSP maintains an Identity Data Store 303 for its Cloud Service Users (CSUs). These scenarios address various 304 joiner, mover, leaver and JIT triggers, resulting in push and pull 305 data exchanges between the CSPs. 307 2.3.1. CSP->CSP - Create Identity (Push) 309 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 310 agreement in place that requires the exchange of Cloud Service User 311 (CSU) accounts. CSP-1 receives a Create Identity trigger action from 312 its Enterprise Cloud Subscriber (ECS-1). CSP-1 creates a local user 313 account for the new CSU. CSP-1 then pushes the new CSU joiner push 314 request down-stream to CSU-2 and gets confirmation that the account 315 was successfully created. After receiving the confirmation from 316 CSP-2, CSP-1 sends an acknowledgement to the requesting ECS. 318 2.3.2. CSP->CSP - Update Identity (Push) 320 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 321 agreement in place that requires the exchange of Cloud Service User 322 (CSU) accounts. The Enterprise Cloud Subscriber (ECS-1) has already 323 created an account with CSP-1 and supplied a critical attribute 324 "department" that is used by CSP-1 to drive service options. CSP-1 325 then receives an Update Identity trigger action from its Enterprise 326 Cloud Subscriber (ECS). CSP-1 updates its local directory account 327 with the new department value. CSP-1 then initiates a separate SCIM 328 protocol exchange to push the mover change request down-stream to 329 CSP-2. After receiving the confirmation from CSP-2, CSP-1 sends an 330 acknowledgment to ECS-1. 332 2.3.3. CSP->CSP - Delete Identity (Push) 333 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 334 agreement in place that requires the exchange of Cloud Service User 335 (CSU) accounts. CSP-1 receives a Delete Identity trigger action from 336 its Enterprise Cloud Subscriber (ECS-1). CSP-1 suspends the local 337 directory account for the specified CSU account. CSP-1 then pushes a 338 termination request for the specified CSU account down-stream to 339 CSP-2 and gets confirmation that the account was successfully 340 removed. After receiving the confirmation from CSP-2, CSP-1 sends an 341 acknowledgment to the requesting ECS. 343 This use case highlights how different CSPs may implement different 344 operational semantics behind the same SCIM operation. Note CSP-1 345 suspends the account representation for its service where as CPS-2 346 implements a true delete operation. 348 2.3.4. CSP->CSP - SSO Trigger (Push) 350 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 351 agreement in place that requires the exchange of Cloud Service User 352 (CSU) accounts. However, rather than pre-provisioning accounts from 353 CSP-1 to CSP-2, CSP-1 waits for a service access request from the end 354 Cloud Service User (CSU-1) before issuing account creation details to 355 CSP-2. When the CSU completes a SSO transaction from CSP-1 to CSP-2, 356 CSP-2 then creates an account for the CSU based on information pushed 357 to it from CSP-1. 359 At the protocol level, this class of scenarios may result in the use 360 of common protocol exchange patters between CSP-1 & CSP-2. 362 2.3.5. CSP->CSP - SSO Trigger (Pull) 364 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 365 agreement in place that requires the exchange of Cloud Service User 366 (CSU) accounts. However, rather than pre-provisioning accounts from 367 CSP-1 to CSP-2, CSP-2 waits for a service access request from the 368 Cloud Service User (CSU-1) before initiating a Pull request to gather 369 information about the CSU sufficient to create a local account. 371 At the protocol level, this class of scenarios may result in the use 372 of common protocol exchange patterns between CSP-2 & CSP-1. 374 2.3.6. CSP->CSP - Password Reset (Push) 376 In this scenario two CSPs (CSP-1 & CSP-2) have a shared service 377 agreement in place that requires the exchange of Cloud Service User 378 (CSU) accounts. CSP-1 wants to change the password for a specific 379 Cloud Service User (CSU-1). CSP-1 sends a request to CSP-2 to reset 380 the password value for CSU-1. 382 At the protocol level, this scenario may result in the same protocol 383 exchange as any other attribute change request. 385 2.4. Enterprise Cloud Subscriber to Cloud Service Provider 386 Flows(ECS->CSP) 388 These scenarios represent flows between an Enterprise Cloud 389 Subscriber (ECS) and a Cloud Service Providers (CSP). It is assumed 390 that both the ECS and the CSP maintains an LDAP service for the 391 relevant Cloud Service Users (CSUs). These scenarios address various 392 joiner, mover, leaver and JIT triggers, resulting in push and pull 393 data exchanges between the ECS and the CSP. 395 Many of these scenarios are very similar to those defined in the 396 Cloud Service Provider to Cloud Service Provider section above. They 397 are identified separately here so that we may explore any differences 398 and might emerge. 400 2.4.1. ECS->CSP - Create Identity (Push) 402 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 403 service with a Cloud Service Provider (CSP-1) that requires the 404 sharing of various Cloud Service User (CSU) accounts. A new user 405 joins ECS-1 and so ECS-1 pushes an account creation request to CSP-1, 406 supplying all required base SCIM schema attribute values and 407 additional extended SCIM schema values as required. 409 2.4.2. ECS ->CSP - Update Identity (Push) 411 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 412 service with Cloud Service Provider (CSP-1) that drives service 413 definition from a key account schema attribute called Department. 414 ECS-1 wishes to move a given CSU from Department A to Department B 415 and so it pushes an attribute update request to the CSP. 417 2.4.3. ECS ->CSP - Delete Identity (Push) 419 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 420 service with a Cloud Service Provider (CSP-1). Upon termination of 421 one of its employees' employment agreement, ECS-1 sends a suspend 422 account request to CSP-1 (Figure 1.4.3-1). One week later the ECS 423 wishes to complete the process by fully removing the Cloud Service 424 User (CSU) account and so it sends a terminate account request to 425 CSP-1. 427 2.4.4. ECS ->CSP - SSO Pull 428 In this scenario an Enterprise Cloud Subscriber (ECS-1) maintains a 429 service with a Cloud Service Provider (CSP-1). No accounts are 430 created or exchanged in advance. However, rather than pre- 431 provisioning accounts from ECS-1 to CSP-1, CSP-1 waits for a service 432 access request from the Cloud Service User (CSU-1) under the control 433 domain of ECS-1, before issuing an account Pull request to CSP-1. 435 3. SCIM use cases 437 This section lists the SCIM use cases. 439 3.1. Change of the ownership of a file 441 Description: 443 Bob - an employee of the company SomeEnterprise - creates a file, 444 which is located at the cloud provided by SomeCSP. After Bob leaves 445 SomeEnterprise, SomeCSP on a request from SomeEnterprise terminates 446 Bob's rights to the file and transfers his former rights to Bill - 447 another employee of SomeEnterprise. 449 Pre-conditions: 451 o SomeCSP is a cloud service provider for SomeEnterprise 453 o With permission of SomeEnterprise, Bob had created a file at the 454 cloud provided by SomeCSP 456 o Bob has left SomeEnterprise 458 o SomeEnterprise terminates Bob's rights to the file and, possibly, 459 decommissions Bob's identity 461 o SomeEnterprise communicates the changes to Bob's rights to SomeCSP 463 o SomeCSP enforces the changes made by SomeEnterprise 465 o SomeEnterprise requests SomeCSP to transfer Bob's former rights to 466 Bill 468 Post-conditions: 470 o Bob does not have the rights to the file at the cloud provided by 471 SomeCSP 473 o Bill has the rights to the file that Bob had had 475 Requirements: 477 o SomeEnterprise can securely communicate to SomeCSP all changes 478 regarding its employee's identity 480 o SomeCSP can enforce the requested changes 482 o SomeCSP shall be able to log all changes regarding a 483 SomeEnterprise employee's identity 485 o The logs should be secure and available for auditing 487 3.2. Migration of the identities 489 Description: 491 A company SomeEnterprise runs an application ManageThem that relies 492 on the identity information about its employees (e.g., identifiers, 493 attributes). The identity information is stored at the cloud 494 provided by SomeCSP. SomeEnterprise has decided to move identity 495 information to the cloud of a different provider - AnotherCSP. In 496 addition, SomeEnterprise has purchased a second application 497 ManageThemMore, which also relies on the identity information. 498 SomeEnterprise is able to move identity information to AnotherCSP 499 without changing the format of identity information. The application 500 ManageThemMore is able to use the identity information. 502 Pre-conditions: 504 o SomeCSP is a cloud service provider for SomeEnterprise 506 o SomeCSP has a known attribute name and value for the Enterprise 507 used for managing and transferring data 509 o AnotherCSP is a new cloud service provider for SomeEnterprise 511 o All involved cloud service providers and applications support the 512 same standard specifying the format for and actions on the user 513 (e.g., employee) identity information 515 Post-conditions: 517 o SomeEnterprise has moved its employees' identity information from 518 SomeCSP to AnotherCSP without making any changes to representation 519 of identity information 521 o Application ManageThemMore is able to use the identity information 523 Requirements: 525 o SomeEnterprise, the applications ManageThem and ManageThemMore, 526 the providers SomeCSP and AnotherCSP support a common standard for 527 identity information, which specifies the following: 529 * Format (or schema) for representing user identity information 531 * Interfaces and protocol for managing user identity information 533 o Cloud providers shall be able to log all actions related to 534 SomeEnterprise employees' identities 536 o The logs should be secure and available for auditing 538 3.3. Single Sign-On (SSO) Service 540 Description: 542 Bob has an account with application hosted by a cloud service 543 provider SomeCSP. SomeCSP has federated its user identities with a 544 cloud service provider AnotherCSP. Bob requests a service from an 545 application running on AnotherCSP. The application running on 546 AnotherCSP, relying on Bob's authentication by SomeCSP and using 547 identity information provided by SomeCSP, serves Bob's request. 549 Pre-conditions: 551 o Bob's identity information is stored on SomeCSP 553 o SomeCSP and AnotherCSP have established trust and federated their 554 user identities 556 o SomeCSP is able to authenticate Bob 558 o SomeCSP is able to securely provide the authentication results to 559 AnotherCSP 561 o SomeCSP is able to securely provide Bob's identity information 562 (e.g., attributes) to AnotherCSP 564 o AnotherCSP is able to verify information provided by SomeCSP 566 o SomeCSP is able to process the identity information received from 567 AnotherCSP 569 Post-conditions: 571 Bob has received the requested service from an application running on 572 AnotherCSP without having to authenticate to that application 573 explicitly. 575 Requirements: 577 o Bob must have an account with SomeCSP 579 o SomeCSP and AnotherCSP must establish trust and federate their 580 user identities 582 o SomeCSP must be able to authenticate Bob 584 o SomeCSP must be able to securely provide the authentication 585 results to AnotherCSP 587 o SomeCSP must be able to securely provide Bob's identity 588 information (e.g., attributes) to AnotherCSP 590 o AnotherCSP must be able to verify the identity information 591 provided by SomeCSP 593 o SomeCSP must be able to process the identity information received 594 from AnotherCSP 596 o SomeCSP and AnotherCSP must log information generated by Bob's 597 actions according to their policies and the trust agreement 598 between them 600 3.4. Provisioning of the user accounts for a Community of Interest 601 (CoI) 603 Description: 605 Organization YourHR provides Human Resources (HR) services to a 606 Community of Interest (CoI) YourCoI. The HR services are offered as 607 Software-as-a-Service (SaaS) on public and private clouds. YourCoI's 608 offices are located all over the world. Their Information Technology 609 (IT) systems may be composed of the combinations of the applications 610 running on Private and Public clouds along with the traditional IT 611 systems. The local YourCoI offices are responsible for establishing 612 personal information and (i.e., setting the user identities and 613 attributes). YourHR services provide means for provisioning and 614 distributing the employee identity information across all YourCoI 615 offices. YourHR also enables the individual users (e.g., employees) 616 to manage their personal information that they are responsible for 617 (e.g., update of an address or a telephone number). 619 Pre-conditions: 621 o YourCoI has a complex infrastructure composed of the large number 622 of local offices that rely on the diverse IT systems 624 o YourCoI has contracted YourHR to provide the HR services 626 o Each local office has a right to establish a personal account for 627 an employee 629 Post-conditions: 631 o All personal accounts are globally available to any authorized 632 user or application across the YourCoI system through the services 633 provided by YourHR 635 o The employees have ability to manage the part of personal 636 information that is in their responsibility 638 Requirements: 640 o YourHR must ensure that the personal information generated by the 641 local offices is timely available in a globally-accessible 642 database 644 o Identity management of the personal data must be secure 646 o All operation with identity data must be securely logged 648 o The logs should be available for auditing 650 3.5. Transfer of attributes to a relying party web site 652 Description: 654 An end user has an account in a directory service A with one or more 655 attributes. That user then visits relying party web site B, and the 656 user authorizes the transfer of data via authorization protocols 657 (e.g. OAuth, SAML), so selected attributes of the user are 658 transferred from the user's account in directory service A to the web 659 site B at the time of the user's first visit to that site. 661 Pre-conditions: 663 o User has an account in a directory service A 665 o User has one or more attributes 666 o User visits web site of a relying party B 668 Post-conditions: 670 Selected attributes of the user are transferred from the user's 671 account in directory service A to the web site B at the time of the 672 user's first visit to that site. 674 Requirements: 676 Relying parties have to be aware of changes to their cached copy, as 677 these would potentially cause a state change in other relying 678 parties. 680 3.6. Change notification 682 Description: 684 An end user has an account in a directory service A with one or more 685 attributes. That user then visits relying party web site B. Relying 686 party web site B queries directory service A for attributes 687 associated with that user, and related resources. 689 The attributes of the user change later in directory service A. For 690 example, the attributes might change if the user changes their name, 691 has their account disabled, or terminates their relationship with 692 directory service A. Furthermore, other resources and their 693 attributes might also change. The directory service A then wishes to 694 notify relying party web site B of these changes, as relying party B 695 might (or might not) have a cache of those attributes, and if the 696 relying party B were aware of these changes to their cached copy, 697 would potentially cause a state change in relying party B. 699 The volume of changes, however, might be substantial, and only some 700 of the changes may be of interest to relying party B, so directory 701 service A does not wish to "push" all the changes to B. Instead, 702 directory service A wishes to notify B that there are changes 703 potentially of interest, such that B can at an appropriate time 704 subsequently contact directory service A and retrieve just the subset 705 of changes of interest to B. 707 Note that the user must authorize the directory A service to transfer 708 data to the web site, and the user must authorize the directory A 709 service to notify the web site. 711 Pre-conditions: 713 o User has an account in a directory service A 714 o User has one or more attributes 716 o User visits relying party web site B 718 o The resource being updated is at the web site 720 Post-conditions: 722 Service A is able to notify B that there are changes potentially of 723 interest. 725 Requirements: 727 B must be able at an appropriate time to subsequently contact 728 directory service A and retrieve just the subset of changes of 729 interest to B. 731 4. Security considerations 733 Authorization and authentication must be guaranteed for the SCIM 734 operations. 736 5. IANA considerations 738 This Internet Draft includes no request to IANA. 740 6. Acknowledgements 742 Authors would like to thank Ray Counterman, Richard Fiekowsky and 743 Bert Greevenbosch for their reviews and comments. 745 Also thanks to Darran Rolls and Patrick Harding, the SCIM user 746 scenarios section is taken from them. 748 7. References 750 7.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 7.2. Informative References 757 [I-D.ietf-scim-api] 758 Drake, T., Mortimore, C., Ansari, M., Grizzle, K., and E. 759 Wahlstroem, "System for Cross-Domain Identity 760 Management:Protocol", draft-ietf-scim-api-01 (work in 761 progress), April 2013. 763 [I-D.ietf-scim-core-schema] 764 Mortimore, C., Harding, P., Madsen, P., and T. Drake, 765 "System for Cross-Domain Identity Management: Core 766 Schema", draft-ietf-scim-core-schema-01 (work in 767 progress), April 2013. 769 Authors' Addresses 771 Phil Hunt 772 Oracle 774 Email: phil.hunt@oracle.com 776 Bhumip Khasnabish 777 ZTE USA,Inc. 779 Phone: +001-781-752-8003 780 Email: vumip1@gmail.com, bhumip.khasnabish@zteusa.com 782 Anthony Nadalin 783 Microsoft 785 Email: tonynad@microsoft.com 787 Kepeng LI 788 Huawei 789 Bantian 790 Shenzhen, Guangdong 518129 791 China 793 Email: likepeng@huawei.com 795 Zachary Zeltsan 796 Individual 798 Email: Zachary.Zeltsan@gmail.com