idnits 2.17.1 draft-ansari-scim-soft-delete-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 date (March 9, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-scim-use-cases' is defined on line 301, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-scim-api-16 == Outdated reference: A later version (-22) exists of draft-ietf-scim-core-schema-17 == Outdated reference: A later version (-08) exists of draft-ietf-scim-use-cases-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Ansari, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track P. Hunt 5 Expires: September 10, 2015 Oracle 6 March 9, 2015 8 SCIM Soft Delete 9 draft-ansari-scim-soft-delete-00 11 Abstract 13 The System for Cross-Domain Identity Management (SCIM) specification 14 is an HTTP based protocol that makes managing identities in multi- 15 domain scenarios easier to support through a standardized HTTP 16 service. 18 Among other operations, SCIM defines delete operation where upon 19 successful completion of the call, the SCIM endpoint is supposed to 20 delete the requested object and the object should not be available 21 for future SCIM calls and not used in uniqueness criteria 22 requirements. 24 While this model is sufficient for a number of SCIM implementations, 25 there are cases this simple definition of delete may not meet product 26 or business requirements. For example a service provider may require 27 a user object to continue to exist as other objects/data is linked 28 with it or for billing purposes, etc. For example a cloud file 29 storage mechanism may require to show basic information about who 30 created a given file or modified one even if the user is de- 31 provisioned from the system. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 69 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Soft Delete . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Soft Delete Schema Extension . . . . . . . . . . . . . . 4 72 2.2. ServiceProviderConfig Extension . . . . . . . . . . . . . 5 73 2.3. SCIM Create . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.4. SCIM Retrieve . . . . . . . . . . . . . . . . . . . . . . 5 75 2.5. SCIM Modify . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.6. SCIM Delete . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.7. SCIM Bulk . . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.8. SCIM Undelete . . . . . . . . . . . . . . . . . . . . . . 6 79 2.9. SCIM Hard Delete . . . . . . . . . . . . . . . . . . . . 6 80 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 5.2. Informative References . . . . . . . . . . . . . . . . . 7 85 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 7 86 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 7 87 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 90 1. Introduction and Overview 92 The System for Cross-Domain Identity Management (SCIM) specification 93 is an HTTP based protocol that makes managing identities in multi- 94 domain scenarios easier to support through a standardized HTTP 95 service. 97 For some services, even after a resource has been "deleted" from the 98 identity system, there are many artifacts that remain in the 99 application/services layer that were created/touched by the deleted 100 user. Such objects need to remain connected to the deleted object 101 and provide basic information. For example if a user created a 102 document, post, event, even after the user is removed, other users of 103 the system may still interact with these objects and need to see who 104 created the object even if the user is no longer part of the system. 105 Another use case is to protect against accidental loss of references 106 in case of a mistaken "delete" of a resource. Once a resource is 107 removed from the identity system, all that resource's references to 108 any data type is lost given the id of the resource will not be 109 recycled. Recreating the same resource is not going to revive its id 110 and essentially creates a new instance with a new id. 112 While SCIM delete operation as defined in Section 3.6 of 113 [I-D.ietf-scim-api] allows a service provider to keep a resource 114 after deletion, it does not provide any additional guidance or 115 specification on how the "deleted" resource will be managed beyond 116 the initial delete in cases the service provider does not want to 117 permanently remove a resource. 119 This specification defines a set of extensions to SCIM API 120 [I-D.ietf-scim-api] to allow additional operations on resources that 121 have been soft deleted: 123 o Query for resources that have been soft deleted 125 o Hard delete a soft deleted resource 127 o Undelete a soft deleted resource 129 o Extension to the ServiceProviderConfig [I-D.ietf-scim-core-schema] 130 to allow discovery of softDelete extensions 132 1.1. Notational Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. These 137 keywords are capitalized when used to unambiguously specify 138 requirements of the protocol or application features and behavior 139 that affect the interoperability and security of implementations. 140 When these words are not capitalized, they are meant in their 141 natural-language sense. 143 For purposes of readability examples are not URL encoded. 144 Implementers MUST percent encode URLs as described in Section 2.1 of 145 [RFC3986]. 147 Throughout this documents all figures MAY contain spaces and extra 148 line-wrapping for readability and space limitations. Similarly, some 149 URI's contained within examples, have been shortened for space and 150 readability reasons. 152 1.2. Definitions 154 Soft Deleted Resources A SCIM resource that has been deleted using 155 standard SCIM DELETE operation 157 2. Soft Delete 159 A SCIM endpoint supporting Soft Delete extensions MUST implement SCIM 160 DELETE operation in such a way that the resource being deleted is not 161 permanently deleted and stored in an alternate "soft deleted" state. 162 Other standard SCIM operations will continue to function as if soft 163 deleted resources do not exist in the system. READ, MODIFY, PATCH, 164 BULK requests with the soft deleted resource id MUST result in a HTTP 165 NOT FOUND (404). A create request for a user resource with a 166 userName that has been soft deleted, MUST NOT fail with an HTTP 167 status 409 due to the userName conflict with the soft deleted record. 169 2.1. Soft Delete Schema Extension 171 Any SCIM resource type that supports soft delete extensions MUST 172 extend the schema of the resource type by adding the extension 173 defined in this section. 175 The following Singular Attributes are defined: 177 isSoftDeleted 178 A Boolean attribute set to "true" for any resource that is soft 179 deleted. No value or "false" means the resource is not soft 180 deleted. This attribute has mutability of "readOnly" 182 softDeleted 183 A DateTime attribute set to the time the resource was softDeleted. 184 This attribute has mutability of "readOnly". This attribute 185 should be deleted once a resource is not in soft delete state. 187 2.2. ServiceProviderConfig Extension 189 SCIM endpoints that support Soft Delete extensions MUST advertise 190 this support in the ServiceProviderConfig endpoint as defined: 192 softDelete 193 A complex type that specifies Soft Delete configuration options. 194 REQUIRED. 196 supported Boolean value specifying whether the operation is 197 supported. REQUIRED. 199 2.3. SCIM Create 201 SCIM Create SHOULD NOT ignore namespace conflicts arising from soft 202 deleted objects. For example if there exists a user resource with 203 userName value of "user1" that have been soft deleted, a create 204 request for userName with the same value should not fail because of 205 userName conflict. 207 2.4. SCIM Retrieve 209 SCIM retrieve operations MUST NOT match soft deleted objects unless 210 the request includes a filter with the value of "isSoftDeleted=true". 211 This is the only case where a soft deleted resource can be returned 212 as a result of a retrieve operation. 214 2.5. SCIM Modify 216 SCIM modify operation on resources that have been soft deleted MUST 217 result in a HTTP NOT FOUND 404. 219 2.6. SCIM Delete 221 SCIM Delete operations on normal resources MUST NOT remove the 222 resource, but put it in the soft deleted state by modifying the 223 resource and setting isSoftDeleted attribute on the resource to 224 "true" and setting the softDeleted timestamp value to the time of the 225 delete operation. 227 Delete operations on soft deleted resource MUST result in an HTTP NOT 228 FOUND 404 error. 230 [ToDo]Define reference semantics as resources are soft deleted 232 2.7. SCIM Bulk 234 SCIM Bulk operations should follow the semantics defined in this 235 section for regular SCIM operations.error. 237 2.8. SCIM Undelete 239 To allow soft deleted resources to be restored to regular state, a 240 SCIM modify operations can be performed with a query parameter of 241 "isSoftDeleted=true" on the resource. The SCIM Endpoint MUST change 242 the state of the resource to reflect the change from soft deleted 243 state back to normal by removing the softDeleted attribute from the 244 resource and setting the isSoftDeleted attribute value to "false". 246 Furthermore if the process of undeleting the resource results in a 247 namespace conflict, the operation MUST fail and return an HTTP Status 248 409, with "scimType" error code of "uniqueness". 250 The SCIM client can optionally provide new attribute values as part 251 of the modify request to resolve the conflicts. For example to 252 undelete a user resource where the userName has been recycled, a 253 modify with a new userName value can be sent to the SCIM endpoint to 254 undelete the user resource by setting the value of userName to the 255 new value to avoid the conflict case. 257 2.9. SCIM Hard Delete 259 A soft deleted resource can be permanently deleted by sending a SCIM 260 Delete request with a query parameter of "isSoftDeleted=true". This 261 SCIM endpoint SHOULD permanently remove the resource. 263 3. Security Considerations 265 Soft deleted users MUST NOT be allowed to authenticate to the service 266 provider or access any resources. Furthermore soft deleted resources 267 SHOULD NOT be used in authorization decision and act as if those 268 resources do not exist. 270 [TO BE COMPLETED] 272 4. IANA Considerations 274 [TO BE COMPLETED] 276 5. References 278 5.1. Normative References 280 [I-D.ietf-scim-api] 281 Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C. 282 Mortimore, "System for Cross-Domain Identity Management: 283 Protocol", draft-ietf-scim-api-16 (work in progress), 284 March 2015. 286 [I-D.ietf-scim-core-schema] 287 Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore, 288 "System for Cross-Domain Identity Management: Core 289 Schema", draft-ietf-scim-core-schema-17 (work in 290 progress), March 2015. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 296 Resource Identifier (URI): Generic Syntax", STD 66, RFC 297 3986, January 2005. 299 5.2. Informative References 301 [I-D.ietf-scim-use-cases] 302 Hunt, P., Khasnabish, B., Nadalin, A., Li, K., and Z. 303 Zeltsan, "SCIM Use Cases", draft-ietf-scim-use-cases-04 304 (work in progress), March 2015. 306 Appendix A. Contributors 308 Appendix B. Acknowledgments 310 The editor would like to thank the participants in the the SCIM 311 working group for their support of this specification. 313 Appendix C. Change Log 315 Draft 00 - MA - First Draft 317 Authors' Addresses 319 Morteza Ansari (editor) 320 Cisco Corporation 322 Email: morteza.ansari@cisco.com 323 Phil Hunt 324 Oracle Corporation 326 Email: phil.hunt@yahoo.com