<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ansari-scim-soft-delete-00"
     ipr="trust200902">
  <front>
    <title abbrev="draft-ansari-scim-soft-delete">SCIM Soft Delete</title>

    <author fullname="Morteza Ansari" initials="M." role="editor"
            surname="Ansari">
      <organization abbrev="Cisco">Cisco Corporation</organization>

      <address>
        <email>morteza.ansari@cisco.com</email>
      </address>
    </author>

    <author fullname="Phil Hunt" initials="P." surname="Hunt">
      <organization abbrev="Oracle">Oracle Corporation</organization>

      <address>
        <email>phil.hunt@yahoo.com</email>
      </address>
    </author>

    <date month="March" year="2015"/>

    <keyword>SCIM</keyword>

    <abstract>
      <t>The System for Cross-Domain Identity Management (SCIM) specification
      is an HTTP based protocol that makes managing identities in multi-domain
      scenarios easier to support through a standardized HTTP service.</t>

      <t>Among other operations, SCIM defines delete operation where upon
      successful completion of the call, the SCIM endpoint is supposed to
      delete the requested object and the object should not be available for
      future SCIM calls and not used in uniqueness criteria requirements.</t>

      <t>While this model is sufficient for a number of SCIM implementations,
      there are cases this simple definition of delete may not meet product or
      business requirements. For example a service provider may require a user
      object to continue to exist as other objects/data is linked with it or
      for billing purposes, etc. For example a cloud file storage mechanism
      may require to show basic information about who created a given file or
      modified one even if the user is de-provisioned from the system.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction and Overview" toc="default">
      <t>The System for Cross-Domain Identity Management (SCIM) specification
      is an HTTP based protocol that makes managing identities in multi-domain
      scenarios easier to support through a standardized HTTP service.</t>

      <t>For some services, even after a resource has been “deleted” from the
      identity system, there are many artifacts that remain in the
      application/services layer that were created/touched by the deleted
      user. Such objects need to remain connected to the deleted object and
      provide basic information. For example if a user created a document,
      post, event, even after the user is removed, other users of the system
      may still interact with these objects and need to see who created the
      object even if the user is no longer part of the system. Another use
      case is to protect against accidental loss of references in case of a
      mistaken “delete” of a resource. Once a resource is removed from the
      identity system, all that resource’s references to any data type is lost
      given the id of the resource will not be recycled. Recreating the same
      resource is not going to revive its id and essentially creates a new
      instance with a new id.</t>

      <t>While SCIM delete operation as defined in Section 3.6 of <xref
      target="I-D.ietf-scim-api"/> allows a service provider to keep a
      resource after deletion, it does not provide any additional guidance or
      specification on how the "deleted" resource will be managed beyond the
      initial delete in cases the service provider does not want to
      permanently remove a resource.</t>

      <t>This specification defines a set of extensions to SCIM API <xref
      target="I-D.ietf-scim-api"/> to allow additional operations on resources
      that have been soft deleted: <list style="symbols">
          <t>Query for resources that have been soft deleted</t>

          <t>Hard delete a soft deleted resource</t>

          <t>Undelete a soft deleted resource</t>

          <t>Extension to the ServiceProviderConfig <xref
          target="I-D.ietf-scim-core-schema"></xref> to allow discovery of
          softDelete extensions</t>
        </list></t>

      <section anchor="notat" title="Notational Conventions" toc="default">
        <t>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 <xref
        target="RFC2119"/>. These keywords are capitalized when used to
        unambiguously specify requirements of the protocol or application
        features and behavior that affect the interoperability and security of
        implementations. When these words are not capitalized, they are meant
        in their natural-language sense.</t>

        <t>For purposes of readability examples are not URL encoded.
        Implementers MUST percent encode URLs as described in <xref
        target="RFC3986">Section 2.1 of</xref>.</t>

        <t>Throughout this documents all figures MAY contain spaces and extra
        line-wrapping for readability and space limitations. Similarly, some
        URI's contained within examples, have been shortened for space and
        readability reasons.</t>
      </section>

      <section anchor="defs" title="Definitions" toc="default">
        <t><list style="hanging">
            <t hangText="Soft Deleted Resources">A SCIM resource that has been
            deleted using standard SCIM DELETE operation</t>
          </list></t>
      </section>
    </section>

    <section anchor="process" title="Soft Delete">
      <t>A SCIM endpoint supporting Soft Delete extensions MUST implement SCIM
      DELETE operation in such a way that the resource being deleted is not
      permanently deleted and stored in an alternate "soft deleted" state.
      Other standard SCIM operations will continue to function as if soft
      deleted resources do not exist in the system. READ, MODIFY, PATCH, BULK
      requests with the soft deleted resource id MUST result in a HTTP
      NOT FOUND (404). A create request for a user resource with a userName
      that has been soft deleted, MUST NOT fail with an HTTP status 409 due
      to the userName conflict with the soft deleted record.</t>

      <section anchor="schema" title="Soft Delete Schema Extension">
        <t>Any SCIM resource type that supports soft delete extensions
        MUST extend the schema of the resource type by adding the extension
        defined in this section.</t>

        <t>The following Singular Attributes are defined:

        <list style="hanging">
          <t hangText="isSoftDeleted"><vspace blankLines="0"/>A Boolean attribute
          set to "true" for any resource that is soft deleted. No value or
          "false" means the resource is not soft deleted. This attribute has
          mutability of "readOnly"</t>

          <t hangText="softDeleted"><vspace blankLines="0"/>A DateTime attribute
          set to the time the resource was softDeleted. This attribute has mutability
          of "readOnly". This attribute should be deleted once a resource is not
          in soft delete state.</t>
        </list></t>
      </section>

      <section anchor="serviceproviderconfig" title="ServiceProviderConfig Extension">
        <t>SCIM endpoints that support Soft Delete extensions MUST advertise
        this support in the ServiceProviderConfig endpoint as defined:
        <list style="hanging">
          <t hangText="softDelete"><vspace blankLines="0"/>A complex type that
          specifies Soft Delete configuration options. REQUIRED.</t>
          <t>supported  Boolean value specifying whether the operation is
          supported. REQUIRED.</t>
        </list></t>
      </section>

      <section anchor="scimcreate" title="SCIM Create">
        <t>SCIM Create SHOULD NOT ignore namespace conflicts arising from soft deleted
        objects. For example if there exists a user resource with userName value
        of "user1" that have been soft deleted, a create request for userName
        with the same value should not fail because of userName conflict.</t>
      </section>

      <section anchor="scimread" title="SCIM Retrieve">
        <t>SCIM retrieve operations MUST NOT match soft deleted objects unless
        the request includes a filter with the value of "isSoftDeleted=true".
        This is the only case where a soft deleted resource can be returned
        as a result of a retrieve operation.</t>
      </section>

      <section anchor="scimmodify" title="SCIM Modify">
        <t>SCIM modify operation on resources that have been soft deleted MUST
        result in a HTTP NOT FOUND 404.</t>
      </section>

      <section anchor="scimdelete" title="SCIM Delete">
        <t>SCIM Delete operations on normal resources MUST NOT remove the
        resource, but put it in the soft deleted state by modifying the
        resource and setting isSoftDeleted attribute on the resource to
        "true" and setting the softDeleted timestamp value to the time
        of the delete operation.</t>
        <t>Delete operations on soft deleted resource MUST result in an
        HTTP NOT FOUND 404 error.</t>
        <t>[ToDo]Define reference semantics as resources are soft deleted</t>
      </section>

      <section anchor="scimbulk" title="SCIM Bulk">
        <t>SCIM Bulk operations should follow the semantics defined in this
        section for regular SCIM operations.error.</t>
      </section>

      <section anchor="scimundelete" title="SCIM Undelete">
        <t>To allow soft deleted resources to be restored to regular state,
        a SCIM modify operations can be performed with a query parameter of
        "isSoftDeleted=true" on the resource. The SCIM Endpoint MUST change
        the state of the resource to reflect the change from soft deleted
        state back to normal by removing the softDeleted attribute from the
        resource and setting the isSoftDeleted attribute value to "false".</t>
        <t>Furthermore if the process of undeleting the resource results in
        a namespace conflict, the operation MUST fail and return an HTTP
        Status 409, with "scimType" error code of "uniqueness".</t>
        <t>The SCIM client can optionally provide new attribute values
        as part of the modify request to resolve the conflicts. For
        example to undelete a user resource where the userName has been
        recycled, a modify with a new userName value can be sent to the
        SCIM endpoint to undelete the user resource by setting the value
        of userName to the new value to avoid the conflict case.</t>
      </section>

      <section anchor="scimharddelete" title="SCIM Hard Delete">
        <t>A soft deleted resource can be permanently deleted by sending a
        SCIM Delete request with a query parameter of "isSoftDeleted=true".
        This SCIM endpoint SHOULD permanently remove the resource.</t>
      </section>


    </section>

    <section anchor="Security" title="Security Considerations" toc="default">
      <t>Soft deleted users MUST NOT be allowed to authenticate to the service provider
      or access any resources. Furthermore soft deleted resources SHOULD NOT be used
      in authorization decision and act as if those resources do not exist.</t>
      <t>[TO BE COMPLETED]</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>[TO BE COMPLETED]</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-scim-api-16.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-scim-core-schema-17.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
    </references>

    <references title="Informative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-scim-use-cases-04.xml'?>
    </references>

    <section title="Contributors"/>

    <section title="Acknowledgments">
      <t>The editor would like to thank the participants in the the SCIM
      working group for their support of this specification.</t>
    </section>

    <section title="Change Log">
      <t>Draft 00 - MA - First Draft</t>
    </section>
  </back>
</rfc>
