<?xml version='1.0' encoding='UTF-8'?>

<!-- [rfced] pre-edited & formatted by ST 10/30/25 -->
<!-- [rfced] updated from -15 to -16 by ST 11/03/25 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-scim-events-16" number="0000" number="9967" ipr="trust200902" updates="7643, 7644" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" consensus="true" version="3">

  <front>
    <title abbrev="draft-ietf-scim-events">SCIM abbrev="SCIM Profile for SETs">System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens</title> Tokens (SETs)</title>
        <seriesInfo name="RFC" value="0000"/> value="9967"/>
        <author fullname="Phil Hunt" initials="P." role="editor" surname="Hunt">
            <organization abbrev="Independent Id">Independent Identity Inc</organization>
            <address>
                <email>phil.hunt@independentid.com</email>
            </address>
        </author>
        <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget">
            <organization abbrev="Cisco Systems">Cisco Systems</organization>
            <address>
                <email>ncamwing@cisco.com</email>
            </address>
        </author>
        <author fullname="Mike Kiser" initials="M." surname="Kiser">
            <organization abbrev="Sailpoint">Sailpoint Technologies</organization>
            <address>
                <email>mike.kiser@sailpoint.com</email>
            </address>
        </author>
        <author fullname="Jen Schreiber" initials="J." surname="Schreiber">
            <organization abbrev="Workday">Workday, Inc.</organization>
            <address>
                <email>jennifer.winer@workday.com</email>
                <email>jwschreib@gmail.com</email>
            </address>
        </author>
        <date year="2025" month="November"/> year="2026" month="May"/>
	<area>SEC</area>
        <workgroup>SCIM</workgroup>

        <keyword>Identity</keyword>
        <keyword>Event</keyword>
        <keyword>SET</keyword>
        <keyword>Provisioning</keyword>
        <keyword>Token</keyword>
        <keyword>SCIM</keyword>

        <abstract>
          <t>
                This specification defines a set of System for Cross-domain Identity Management (SCIM)
                Security Events using the Security Event Token Specification (SET) specification (RFC 8417) to enable
		the asynchronous exchange
                of messages between SCIM Service Providers service providers and receivers.
            </t>
            <t>
                This draft specification updates RFC7643 RFC 7643 by defining additional attributes for
                the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema schema, and it updates
                RFC7644
                RFC 7644 with an optional new Asynchronous asynchronous SCIM Request request capability.
            </t>
        </abstract>

    </front>
    <middle>
        <section anchor="intro" toc="default" numbered="true">
            <name>Introduction and Overview</name>
            <t>
                This specification defines Security Events for SCIM Service Providers service providers and receivers as specified by the
                Security Event Tokens (SET) (SETs) <xref target="RFC8417"/>. In this specification, SCIM Security
                Events in this specification include: include asynchronous request completion, resource replication, and
                provisioning co-ordination. coordination.
            </t>
            <t>
                This specification defines the use of the HTTP Header header "Prefer: respond-async" <xref target="RFC7240"/>
                to allow a SCIM Protocol Client client <xref target="RFC7644"/> to request an asynchronous response (see <xref target="asyncRequest"/>).
            </t>
            <t>
                Using the HTTP protocol, a SCIM Protocol Client client issues commands to a SCIM Service
                Provider service
                provider using HTTP methods such as POST, PATCH, and DELETE <xref target="RFC7644" format="default"/>
                that cause a state change to a SCIM Resource. resource. When multiple independent SCIM Clients clients update SCIM
                Resources,
                resources, individual clients become out of date as state changes occur. Some clients may need to be
                informed of these changes for co-ordination coordination or reconciliation purposes. This could be done using
                periodic SCIM GET requests over time, but this rapidly becomes problematic as the number of changes and the
                number of resources increases.
            </t>
            <t>
                SCIM Events can be shared over an established Event Feed event feed enabling receivers to monitor and trigger
                independent asynchronous action. This approach enables greater scale and timeliness, where only
                changed information is exchanged between parties.
            </t>
            <t>
                A SET conveys information about a state change that has occurred at a SCIM Service Provider. service provider.
                That SET may be of interest to one or more receivers. But instead of interpreting SETs as commands, each
                Event Receiver is able to determine the best local follow-up action to take within its own context.
                For example, a receiver can reconcile schema and resource type differences between domains.
            </t>

            <section>
                <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
            </section>
            <section anchor="notat" toc="default" numbered="true">
                <name>Notational Conventions</name>
                <t>
                    Throughout this document document, all figures may contain spaces and extra
                    line-wrapping
                    line wrapping for readability and space limitations. Similarly, some
                    URIs contained within examples, examples have been shortened for space and
                    readability reasons.
                </t>
            </section>
            <section anchor="defs" toc="default" numbered="true">
                <name>Definitions</name>
                <t>
                    This specification uses definitions from the following specifications:
                </t>
                <ul>
                    <li>JSON
                    <li>"JSON Web Tokens (JWT) Token (JWT)" <xref target="RFC7519"/>, </li>
                    <li>Security
                    <li>"Security Event Tokens (SET) Token (SET)" <xref target="RFC8417"
                                                    format="default"/>, and</li>
                    <li>System
                    <li>"System for Cross-Domain Cross-domain Identity Management Protocol Management: Protocol" <xref target="RFC7644"/>.
                    </li>
                </ul>
                <t>
                    In JSON Web Tokens (JWTs) and Security Event Tokens, the term "claim" refers to JSON attribute
                    values contained in a JSON Web Token JWT <xref target="RFC7519"/> structure. The term "claim" in tokens is used
                    to indicate that an attribute value may not be verified and its accuracy can be questioned. In the
                    context of SCIM, this distinction is not made. For this specification specification, the terms "claims"
                    and "attributes" are inter-changeable. interchangeable. For consistency, JWT and SET IANA registered attributes registered by IANA will
                    continue to be called claims, "claims", while event information attributes (i.e., those in an event payload) will be
                    referred to as attributes. "attributes".
                </t>
                <t>
                    Additionally, the following terms are defined:
                </t>
                <dl newline="true">
                    <dt>Attributes and Claims</dt> Claims:</dt>
                    <dd>
                        The JWT specification <xref target="RFC7519"/> target="RFC7519"/>, upon which SET is based based, uses the term "claims" to
                        refer to attributes in a JSON token. Web Token. In contrast, SCIM in contrast uses the term "attributes" to refer to
                        JSON attributes. For the purposes of this draft, document, the terms "attributes" and "claims" are equivalent.
                    </dd>

                    <dt>Co-ordinated

                    <dt>Coordinated Provisioning (CP)</dt> (CP):</dt>
                    <dd>
                        Defined
                        As defined in <xref target="coordination"/>, in co-ordinated provisioning CP
                        relationships, an Event Publisher and Receiver typically exchange resource change events without
                        exchanging data (see <xref target="scimProvEvents"/>). For a receiver to know the value of the data,
                        the Event Receiver usually calls back
                        to the SCIM Event Publisher domain to receive a new copy of data (e.g., Uses uses a SCIM GET request).
                    </dd>

                    <dt>Domain Based

                    <dt>Domain-Based Replication (DBR)</dt> (DBR):</dt>
                    <dd>
                        Defined
                        As defined in <xref target="replication"/>, in this domain-based replication
                        mode the DBR mode,
                        there is an administrative relationship spanning multiple operational domains, domains; data
                        shared in Events typically uses the "full" mode variation of change events (see <xref target="scimProvEvents"/>) including
                        the "data" payload attribute. This eliminates the need for a callback
                        to retrieve additional data.
                    </dd>

                    <dt>Event Feed / Event Stream</dt> Stream:</dt>
                    <dd>
                        An Event Feed (equivalently Event Stream) event feed (or equivalently an event stream) is a logical series of events shared with a unique receiving client.
                        A SET transfer (see <xref target="RFC8935"/> and <xref target="RFC8936"/>) Service Provider service provider may
                        offer to allow Event Receivers to "subscribe" to specific event types or events about specific
                        resources (see Feed Management feed events in <xref target="scimFeedEvents"/>).
                    </dd>

                    <dt>Event Receiver</dt> Receiver:</dt>
                    <dd>
                        An entity typically receives events typically via as described in <xref target="RFC8935"/>, target="RFC8935"/> and <xref target="RFC8936"/>, target="RFC8936"/> or
                        via HTTP GET (see <xref target="asyncRequest"/>). In the case of push-based SET Push Transfer delivery
                        <xref target="RFC8935"/>, the Event Receiver is an HTTP Service Endpoint endpoint that receives requests.
                        In the case of poll-based SET Poll-Based Transfer delivery <xref target="RFC8936"/>, the receiver is an HTTP client
                        that initiates HTTP request requests to an Event Publisher endpoint.
                    </dd>

                    <dt>Event Publisher</dt> Publisher:</dt>
                    <dd>
                        A system that issues SETs based on a resource state change that has occurred at a SCIM
                        Service Provider.
                        service provider. For example, events may be the result of a SCIM Create, Modify, or Delete operation
                        as defined in <xref section="3" target="RFC7644"/>. A SCIM Service Provider service provider may be an Event Publisher or an
                        independent service that aggregates events into Event Receiver feeds. As described above, when
                        using <xref target="RFC8935"/>, the Event Publisher is an HTTP Client client that initiates HTTP POST
                        requests to a defined Event Receiver endpoint. When using <xref target="RFC8936"/>, the Event
                        Publisher provides an HTTP endpoint endpoint, which a receiver may use to "poll" for Security Events.
                    </dd>

                    <dt>SCIM Client</dt> Client:</dt>
                    <dd>
                        Refers to an
                        An HTTP client that initiates SCIM Protocol protocol <xref target="RFC7644"/> requests and receives
                        responses which that may cause SCIM Events to be issued by the SCIM Service Provider. service provider. A SCIM Client client may
                        also be an Event Receiver, typically when making an asynchronous SCIM request (see <xref target="asyncRequest"/>).
                    </dd>

                    <dt>SCIM Service Provider</dt> Provider:</dt>
                    <dd>
                        An HTTP server that implements the SCIM Protocol protocol <xref target="RFC7644"/> and SCIM Schema schema
                        <xref target="RFC7643"/>. Upon processing a state change to a SCIM Resource, resource, it issues a SCIM Event
                        or causes an Event Publisher to issue a SCIM Event.
                    </dd>

                    <dt>SET</dt>
                    <dd>
                        Abbreviation for "Security
                    <dt>Security Event Token" as Token (SET):</dt>
                    <dd>
                        As defined in <xref target="RFC8417"/> target="RFC8417"/>.
                    </dd>

                </dl>
            </section>
        </section>

        <section anchor="scimEvents" numbered="true" toc="default">
            <name>SCIM Events</name>
            <t>
                A SCIM event Event is a signal, in the form of a Security Event Token <xref target="RFC8417" format="default"/>,
                that describes some event that has occurred. A SET event consists of a set of standard JWT "top-level"
                claims and an "events" claim that contains one or more event URI subclaims (JSON attributes) each with a
                JSON object containing relevant event information.
            </t>

            <t>
                This specification defines a the new URI prefix "urn:ietf:params:scim:event" "urn:ietf:params:scim:event", which is used
                as the prefix for the following defined SCIM Events (see <xref target="IANAevents"/>). Events are grouped
                into one of two sub-namespaces: "feed" (feed control notices) or "prov" (provisioning).
            </t>

            <section anchor="sub-id" numbered="true" toc="default">
                <name>Identifying the Subject of an Event</name>
                <t>
                    SCIM Events <bcp14>MUST</bcp14> use the "sub_id" claim, defined by <xref target="RFC9493"/>, to identify the
                    subject of events. The "sub_id" claim <bcp14>MUST</bcp14> be contained within the main JWT claims body and <bcp14>MUST NOT</bcp14> be located within an event
                    payload within the "events" claim. A SET with multiple event URIs indicates that the events
                    arise from the same transaction or resource state change for a single resource or subject.
                </t>
                <t>
                    The JWT "sub" claim <bcp14>MUST NOT</bcp14> be used to identify subjects to prevent confusion with JWT
                    authorization tokens (originally recommended in <xref section="3" target="RFC8417"/>).
                </t>
                <figure anchor="example_subid">
                    <name>SCIM
                    <name>Example SCIM Subject Id Example</name>
                    <artwork type="" align="left" alt=""><![CDATA[ Id</name>
                    <sourcecode type="json" ><![CDATA[
{
     "iss": "issuer.example.com",
     "iat": 1508184845,
     "aud": "aud.example.com",
     "sub_id": {
        "format": "scim",
        "uri": "/Users/2b2f880af6674ac284bae9381673d462",
        "externalId": "alice@example.com"
     },
     "events": {
       ...
     }
}]]></artwork>
}]]></sourcecode>
                </figure>
                <t>
                    Instead of "sub", the top-level claim "sub_id" <bcp14>SHALL</bcp14> be used. "sub_id" contains the subclaim attribute
                    "format" set to "scim" to indicate that the attributes present in the "sub_id"
                    object are SCIM attributes. The following "sub_id" attributes are defined:
                </t>
                <dl newline="true" spacing="normal">
                    <dt>uri</dt>
                    <dt>uri:</dt>
                    <dd>
                        The SCIM relative path for the resource which that usually consists of the resource type endpoint
                        plus the resource "id" (see <xref section="3.2" target="RFC7644"/>). For example target="RFC7644"/>), for example,
                        "/Users/2b2f880af6674ac284bae9381673d462".
                        This attribute <bcp14>MUST</bcp14> be provided in a SCIM Event "sub_id" claim. Note that the relative path
                        is the path component after the SCIM Service Provider service provider Base URI as defined in <xref target="RFC7644" section="1.3"/>.
                        In cases where the Event Receiver is unable to match a URI, the Event Receiver <bcp14>MAY</bcp14> issue a callback
                        to a previously agreed SCIM Service Provider service provider Base URI plus the relative "uri" value and
                        perform a SCIM GET request per <xref target="RFC7644" section="3.4.1"/>.
                    </dd>
                    <dt>externalId</dt>
                    <dt>externalId:</dt>
                    <dd>
                        If known, the "externalId" value (defined in <xref target="RFC7643" section="3.1"/>) of the SCIM
                        Resource
                        resource that <bcp14>MAY</bcp14> be used by a receiver to identify the corresponding resource in the Event
                        Receiver's domain.
                    </dd>
                    <dt>id</dt>
                    <dt>id:</dt>
                    <dd>
                        The SCIM Id "id" attribute (defined in <xref section="3.1" target="RFC7643"/>) <bcp14>MAY</bcp14> be used for backwards
                        compatibility reasons in addition to the "uri" claim.
                    </dd>
                </dl>
            <t>
                    In cases where SCIM identifiers ("id" and "externalId") are not enough to identify a
                    common resource between an Event Publisher and Event Receiver,
                    the "sub_id" object <bcp14>MAY</bcp14> contain attributes whose SCIM attribute types have "uniqueness" set to
                    "server" or "global" as per <xref section="7" target="RFC7643"/>. For example, attributes such as
                    "emails" or "username" "userName" (defined in <xref section="4" target="RFC7643"/>) are unique
                    with in
                    within a SCIM Service Provider. service provider. Such attributes should allow an Event Publisher and Event Receiver
                    to identify a commonly understood subject resource of an event.
                </t>
            </section>
            <section anchor="attributes" numbered="true" toc="default">
                <name>Common Event Attributes</name>
                <t>The following attributes are available for all events defined. Some attributes are defined as SET/JWT
                    claims, while others are "Event Payload" "event payload" claims as defined in <xref section="1.2" target="RFC8417"/>.
                    Only one of the claims, "data" or "attributes" claims "attributes", <bcp14>MUST</bcp14> be provided depending on the event
                    definition.
                </t>
                <dl newline="true" spacing="normal">
                    <dt>txn</dt>
                    <dt>txn:</dt>
                    <dd>
                        "txn" is a
                        A SET-defined claim with a STRING value (see <xref section="2.2" target="RFC8417"/>)
                        that uniquely identifies a transaction originating at a SCIM Service Provider service provider and/or its underlying data
                        repository or database where one or more SCIM Events may be subsequently issued. In contrast to
                        a "jti" claim (see <xref section="4.1.7" target="RFC7519"/>), which uniquely identifies
                        a token, the "txn" remains the same when
                        one or more SETs are generated for various purposes such as re-transmission, retransmission, publication to
                        multiple receivers receivers, etc. A distinct state change or transaction within a SCIM Service Provider service provider
                        <bcp14>MAY</bcp14> result in multiple SETs issued each with distinct "jit" values an and a common
                        "txn" value. "txn" is <bcp14>REQUIRED</bcp14> to support asynchronous SCIM requests,
                        co-ordinated provisioning,
                        CP, and replication to disambiguate or detect duplicate SETs regarding
                        the same underlying transaction.
                    </dd>
                    <dt>version</dt>
                    <dt>version:</dt>
                    <dd>
                        The Etag ETag version of the resource as a result of the event and corresponds event. Corresponds to the Etag ETag
                        response header described in <xref target="RFC7644" section="3.14"/>.
                    </dd>
                    <dt>data</dt>
                    <dt>data:</dt>
                    <dd>
                        This
                        An event payload attribute that contains information described in the SCIM Bulk
                        Operations "data" attribute in <xref section="3.7" target="RFC7644"/>. The JSON object
                        contains the equivalent SCIM command processed by the SCIM Service Provider. service provider. For example, after
                        processing a SCIM Create operation, the data contained includes the final representation of the
                        created
                        entity created by the SCIM Service Provider service provider including the assigned "id" value.
                    </dd>

                    <dt>attributes</dt>
                   <dt>attributes:</dt>
                    <dd>
                        This
                        A payload that contains an array of attributes that were added, revised, or removed. Names of
                        modified attributes <bcp14>SHOULD</bcp14> conform to the ABNF syntax rule for "path"> "path"
                        (<xref target="RFC7644" section="3.5.2"/>). For example: <br/>
                        <tt>"attributes": ["username","emails","name.familyName"]</tt> ["userName","emails","name.familyName"]</tt>.
                    </dd>
                </dl>

            </section>

            <section anchor="scimFeedEvents" numbered="true" toc="default">
                <name>SCIM Feed Events</name>
                <t>
                    This section defines events related to changes in the content of an event feed. Such as, feed such as
                    SCIM Resources resources that are being added or removed from an event feed or events used in
                    Co-operative
                    Coordinated Provisioning scenarios where only a sub-set subset of entities are shared across an
                    Event Feed.
                    event feed. The URI prefix for these events is
                    "urn:ietf:params:scim:event:feed" "urn:ietf:params:scim:event:feed".
                </t>
                <section anchor="feedAdd" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:feed:add</name>
                    <t>The specified resource has been added to the Event Feed. event feed. A "feed:add" does not indicate that a
                        resource is new or has been recently created. For example,
                        an existing user has had a new role (e.g., CRM_User) added to
                        their profile profile, which has caused their resource to join a feed.
                    </t>
                    <figure anchor="exampleFeedAddEvent">
                        <name>Example SCIM Feed Add Event</name>
                        <artwork type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "txn": "b7b953f11cc6489bbfb87834747cc4c1",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2b2f880af6674ac284bae9381673d462",
    "externalId": "jdoe"
  },
  "events":{
    "urn:ietf:params:scim:event:feed:add": {}
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                </section>
                <section anchor="feedRemove" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:feed:remove</name>
                    <t>The specified
                        resource has been removed from the feed. Removal does not indicate
                        that the resource was deleted or otherwise deactivated.
                    </t>
                    <figure anchor="exampleRemoveEvent">
                        <name>Example SCIM Feed Remove Event</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2b2f880af6674ac284bae9381673d462",
    "externalId": "jdoe",
  },
  "events":{
    "urn:ietf:params:scim:event:feed:remove": {}
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                </section>
            </section>
            <section anchor="scimProvEvents" numbered="true" toc="default">
                <name>SCIM Provisioning Events</name>
                <t>
                    This section defines resource changes that have occurred within a SCIM Service Provider. service provider. These
                    events are used in both Domain Based Domain-Based Replication (DBR) and Co-operative Coordinated Provisioning (CP) mode. The
                    URI prefix for these events is "urn:ietf:params:scim:event:prov".
                </t>
                <t>
                    For each of the following events when
                    When the "data" payload attribute is included, included for each of the following events, the
                    event URI <bcp14>MUST</bcp14> end with "full", otherwise "full"; otherwise, the event URI ends with "notice". In
                    "full" mode, the set of values reflecting the final representation of the resource (such as would
                    be returned in a SCIM protocol response) at the Service Provider service provider
                    are provided using the "data" attribute (see <xref target="exampleCreateEvent"/>). In "notice"
		    mode, the
                    "attributes" attribute is returned listing and lists the set of attributes created or modified in the
                    request (see <xref target="exampleCreateEventDef"/>). Exactly one of the payload attributes attributes, "data"
                    or "attributes", <bcp14>MUST</bcp14> be present. Both <bcp14>MUST NOT</bcp14> be present simultaneously.
                </t>
                <section anchor="provCreate" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:create:{notice|full}</name>
                    <t>
                        Indicates
                        The specified resource indicates that a new SCIM resource has been created by the SCIM Service Provider service provider
                        and has been added to the Event Feed. event feed.
                        Note that because the event may be used for replication, the "id"
                        attribute that was assigned by the SCIM Service Provider service provider is shared so that all replicas in the
                        domain <bcp14>MAY</bcp14> use the same resource identifier.
                    </t>
                    <figure anchor="exampleCreateEvent">
                        <name>Example SCIM Create Event (Full)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  "iat": 1458496404,
  "iss":"https://scim.example.com",
  "aud":[
    "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],
  "sub_id": {
    "format": "scim",
    "uri": "/Users/44f6142df96bd6ab61e7521d9",
     "externalId":"jdoe"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:create:full":{
      "data":{
        "schemas":[ "urn:ietf:params:scim:schemas:core:2.0:User"],
        "emails":[
          {"type":"work","value":"jdoe@example.com"}
        ],
        "userName":"jdoe",
        "name":{
          "givenName":"John",
          "familyName":"Doe"
        }
      }
    }
  }
}]]></artwork>
}]]></sourcecode>
                    </figure>

                    <figure anchor="exampleCreateEventDef">
                        <name>Example SCIM Create Event (Notice)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  "iat": 1458496404,
  "iss":"https://scim.example.com",
  "aud":[
    "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],
  "sub_id": {
    "format": "scim",
    "uri": "/Users/44f6142df96bd6ab61e7521d9",
    "externalId": "jdoe"
  },
  "events": {
    "urn:ietf:params:scim:event:prov:create:notice": {
      "attributes": [
        "id",
        "name",
        "userName",
        "password",
        "emails"
      ]
    }
  }
}]]></artwork>
}]]></sourcecode>
                    </figure>
                    <t>
                        The event shown in <xref target="exampleCreateEventDef"/> notifies the Event Receiver of which
                        attributes have changed changed, but it does not convey
                        the actual information. The Event Receiver <bcp14>MAY</bcp14> retrieve that information
                        by performing a SCIM GET based on the "sub_id" value provided.
                    </t>
                </section>

                <section anchor="provPatch" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:patch:{notice|full}</name>
                    <t>
                        The specified resource has been updated using SCIM PATCH. In "full" mode, the
                        "data" payload attribute is included (see <xref target="examplePatchEventFull"/>).
                        When the event URI ends with "notice", the list of modified attributes is provided
                        (see <xref target="examplePatchEventBrief"/>).
                    </t>
                    <figure anchor="examplePatchEventFull">
                        <name>Example SCIM Patch Event (Full)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
    "externalId": "crmUsers"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:patch:full": {
      "version": "a330bc54f0671c9",
      "data": {
        "schemas":
      ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations":[{
          "op":"add",
          "path":"members",
          "value":[{
             "display": "Babs Jensen",
             "$ref": "/Users/2819c223...413861904646",
             "value": "2819c223-7f76-453a-919d-413861904646"
          }]
        }]
      }
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                    <figure anchor="examplePatchEventBrief">
                        <name>Example SCIM Patch Event (Notice)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
    "externalId": "crmUsers"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:patch:notice": {
      "attributes": ["members"],
      "version": "a330bc54f0671c9"
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                </section>
                <section anchor="provPut" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:put:{notice|full}</name>
                    <t>
                        The specified resource has been updated (e.g., one or more attributes has
                        changed). In "full" mode, the SCIM PUT request body is included in the "data"
                        attribute (see <xref target="examplePutEventFull"/>). In "notice" mode, the modified
                        attributes are listed using "attributes" (see <xref target="examplePutEventBrief"/>).
                    </t>
                    <figure anchor="examplePutEventFull">
                        <name>Example SCIM Put Event (Full)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json" ><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:put:full": {
      "version": "a330bc54f0671c9",
      "data": {
        "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
        "userName":"jdoe",
        "externalId":"jdoe",
        "name":{
           "formatted":"Mr. Jon Jack Doe III",
           "familyName":"Doe",
           "givenName":"Jon",
           "middleName":"Jack"
        },
        "roles":[],
        "emails":[
          {"value":"jdoe@example.com"},
          {"value":"anon@jdoe.org"}
        ]
      }
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                    <figure anchor="examplePutEventBrief">
                        <name>Example SCIM Put Event (Notice)</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:put:notice": {
      "version": "a330bc54f0671c9",
      "attributes": ["userName","externalId","name","roles","emails"]
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>

                </section>

                <section anchor="provDelete" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:delete</name>
                    <t>
                        The specified resource has been deleted from the SCIM Service Provider. service provider.
                        The resource is also removed from the feed. When a
                        DELETE is sent, a corresponding "feedRemove" <bcp14>SHALL NOT</bcp14> be issued. A delete
                        event has no payload attributes. Note that because the delete event has
                        no attributes, the qualifiers "full" and "notice" <bcp14>SHALL NOT</bcp14> be used.
                    </t>

                    <figure anchor="exampleDeleteEvent">
                        <name>Example SCIM Delete Event</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2b2f880af6674ac284bae9381673d462",
    "externalId": "jDoe"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:delete": {}
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                </section>
                <section anchor="provActivate" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:activate</name>
                    <t>
                        The specified resource (e.g., User) has been "activated". This does not necessarily reflect
                        any particular state change at the SCIM Service Provider service provider but may simply indicate that the
                        account defined by the SCIM resource is ready for use as agreed upon by the Event Publisher and
                        Event Receiver. For example, an activated resource can represent an account that may be logged in.
                    </t>
                    <figure anchor="exampleActivateEvent">
                        <name>Example SCIM Activate Event</name>
                        <artwork name="" type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2b2f880af6674ac284bae9381673d462"
  },
  "events":{
    "urn:ietf:params:scim:event:prov:activate": {}
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                </section>
                <section anchor="provDeactivate" numbered="true" toc="default">
                    <name>urn:ietf:params:scim:event:prov:deactivate</name>
                    <t>
                        The specified resource (e.g., User) has been deactivated and
                        disabled. The exact meaning <bcp14>SHOULD</bcp14> be agreed to by the Event Publisher
                        and its corresponding Event Receiver. Typically, this means the subject
                        may no longer have an active security session.
                    </t>
                </section>
            </section>
            <section anchor="scimMisc" numbered="true" toc="default">
                <name>Miscellaneous Events</name>
                <t>
                    This section defines related miscellaneous events such as Asynchronous Request asynchronous request completion
                    that has occurred within a SCIM Service Provider. service provider. The URI prefix for these events is
                    "urn:ietf:params:scim:event:misc".
                </t>

                <section anchor="asyncEvent" numbered="true" toc="default">
                    <name>Asynchronous Events</name>
                    <section anchor="asyncRequest" numbered="true" toc="default">
                        <name>Making an Asynchronous SCIM Request</name>
                        <t>
                            A SCIM Client client making SCIM HTTP requests defined in <xref target="RFC7644" section="3"/> <bcp14>MAY</bcp14> request
                            asynchronous processing using the "Prefer" HTTP Header header as defined in
                            <xref target="RFC7240" section="4.1"/>. The client may do this for a number of reasons such as avoiding
                            holding HTTP connections open during long requests, requests because the result of the request is not
                            needed,
                            needed or for co-ordination reasons where the result is delivered to another entity for further action. action for coordination reasons.
                        </t>
                        <t>
                            To initiate an asynchronous SCIM request, a normal SCIM protocol POST, PUT,
                            PATCH, or DELETE request is performed with the HTTP "Prefer" Header header set to
                            "respond-async" (<xref target="RFC7240" section="4.1"/>). The HTTP "Accept"
                            header <bcp14>MUST</bcp14> be ignored for purposes of an asynchronous response. Additionally, per
                            <xref target="RFC7240" section="4.3"/>, the "wait"
                            preference <bcp14>SHOULD</bcp14> be supported to establish a maximum time
                            before a SCIM Service Provider service provider <bcp14>MAY</bcp14> choose to respond asynchronously.
                        </t>
                        <t>
                            In response, the SCIM Service Provider either service provider returns either a normal SCIM response or returns
                            HTTP Status status code 202 (Accepted).
                            The asynchronous response <bcp14>MUST</bcp14> contain no response body. To enable correlation of the
                            future event, the HTTP response header "Set-Txn" (see <xref target="settxnheader"/>) is
                            returned with a value that <bcp14>MUST</bcp14> match the "txn" claim in a subsequent Security Event
                            Token. Per <xref target="RFC7240" section="3" sectionFormat="comma"/>, the response will also include the
                            "Preference-Applied" header. The "Location" header value <bcp14>MUST</bcp14> be one of the
                            following: (a) a URI where the completion SCIM Event Token <bcp14>MAY</bcp14> be retrieved using HTTP GET, GET
                            or (b) the normal SCIM location header response specified by <xref target="RFC7644"/>.
                        </t>
                        <t keepWithNext="true">
                            In the following non-normative example, a "Prefer" header is set to "respond-async":
                        </t>
                        <figure anchor="asyncRequestFigure">
                          <name>Example Asynchronous SCIM Protocol Request</name>
                            <artwork align="left"><![CDATA[

                           <sourcecode type="json"><![CDATA[
PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: scim.example.com
Prefer: respond-async
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8

{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III"
  },
  "roles":[],
  "emails":[
    {
        "value":"bjensen@example.com"
    }
  ]
}]]></artwork>
}]]></sourcecode>

                        </figure>
                        <t>
                            The SCIM Service Provider service provider responds with HTTP status code 202 Accepted (Accepted) and includes the Set-Txn header:
                        </t>

<figure>
                            <artwork><![CDATA[
  <name>Async SCIM Request with Prefer Header</name>
                            <sourcecode type="json"><![CDATA[
HTTP/1.1 202 Accepted
Set-Txn: 734f0614e3274f288f93ac74119dcf78
Preference-Applied: respond-async
Location:
  "/Users/2819c223-7f76-453a-919d-413861904646"
]]></artwork>
]]></sourcecode>
                        </figure>
                    </section>
                    <section anchor="asyncBulkRequest" numbered="true" toc="default">
                        <name>Asynchronous Bulk Endpoint Requests</name>
                        <t>
                            <xref section="3.7" target="RFC7644"/> provides the ability to submit multiple
                            SCIM operations in a single "bulk" request. When an asynchronous response is requested, a single
                            Asynchronous Request Completion Event <bcp14>MUST</bcp14> be generated for each requested operation. For example,
                            if a single "bulk" request had 10 operations, then 10 Asynchronous Event completions completion events
                            would be generated.
                        </t>
                        <t>
                            The "txn" claim <bcp14>MUST</bcp14> be set to the value originally returned to the requesting SCIM Client client (see
                            <xref target="asyncRequest"/>) appended with a colon ":" and the zero-based array index of
                            the operation expressed in the "Operations" attribute of the
                            original bulk request. The "bulkId" parameter <bcp14>MUST NOT</bcp14> be used for this purpose as
                            it is a temporary identifier and is not required for every operation.
                        </t>
                        <t>
                            For example, if a SCIM Service Provider service provider received a Bulk bulk request with two or more operations,
                            and had a "txn" claim value of "2d80e537a3f64622b0347b641ebc8f44",
                            then the first Asynchronous Response Event Token representing the first operation has
                            a "txn" claim value of "2d80e537a3f64622b0347b641ebc8f44:0", the second operation has a value of
                            "2d80e537a3f64622b0347b641ebc8f44:1", and so on.
                        </t>
                        <t>
                            If a SCIM Service Provider service provider optimizes the sequence of operations (per <xref target="RFC7644" section="3.7"/>), the
                            Asynchronous Request Completion events generated Events <bcp14>MAY</bcp14> be generated out of sequence from the
                            original request.  In this
                            case, the "txn" claims in those events <bcp14>MUST</bcp14> use operation numbers that correspond to the
                            order in the original request.
                        </t>
                    </section>
                    <section>
                    <name>urn:ietf:params:scim:event:misc:asyncresp</name>
                    <t>
                        The Asynchronous Response event Event signals the completion of a SCIM request. The event payload contains
                        the attributes defined in <xref target="RFC7644" section="3.7"/> and is the same as a
                        single SCIM Bulk Response Operation as per Section <xref target="RFC7644" section="3.7.3" sectionFormat="bare"/>. section="3.7.3"/>. In the event, the "txn" claim <bcp14>MUST</bcp14> be
                        set to the value originally returned to the requesting SCIM Client client (see <xref target="asyncRequest"/>).
                    </t>

                    <figure anchor="exampleAsyncEvent">
                        <name>Example SCIM Asynchronous Response Event</name>
                        <artwork type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
  "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
  },
  "txn": "734f0614e3274f288f93ac74119dcf78",
  "events":{
    "urn:ietf:params:scim:event:misc:asyncresp": {
        "method": "PUT",
        "version": "W\/\"huJj29dMNgu3WXPD\"",
        "status": "200"
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                    </figure>

                    <t>
                        If an error occurs during asynchronous processing,
                        the event operation <bcp14>MUST</bcp14> include a "response" attribute indicating a non-200-series HTTP status
                        as defined in <xref section="3.7" target="RFC7644"/>, and that "response" attribute <bcp14>MUST</bcp14> contain the
                        sub-attributes defined in <xref section="3.12" target="RFC7644"/>. The "status" attribute
                        of the event operation typically matches the "status" attribute of the response.
                    </t>
                    <figure anchor="exampleAsyncErrorEvent">
                        <name>Example SCIM Asynchronous Error Response Event</name>
                        <artwork type="" align="left" alt=""><![CDATA[
                        <sourcecode type="json"><![CDATA[
{
 "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
 "sub_id": {
   "format": "scim",
   "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
 },
 "txn": "734f0614e3274f288f93ac74119dcf78",
 "events":{
   "urn:ietf:params:scim:event:misc:asyncresp": {
       "method": "PUT",
       "version": "W\/\"huJj29dMNgu3WXPD\"",
       "status": "400",
       "response": {
           "schemas": [
               "urn:ietf:params:scim:api:messages:2.0:Error"
           ],
           "scimType":"invalidSyntax",
           "detail": "Request is unparsable",
           "status":"400"
       }
   }
 },
 "iat": 1458505044,
 "iss":"https://scim.example.com",
 "aud":[
  "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
 ]
}]]></artwork>
}]]></sourcecode>
                    </figure>
                    <t>The following 4 four figures show Asynchronous Completion asynchronous completion events for the example in
                    <xref target="RFC7644" section="3.7.3"/>.</t>
                        <figure anchor="exampleAsyncBulk1">
                            <name>Example SCIM Asynchronous Response Event Operation 1/4</name>
                            <artwork type="" align="left" alt=""><![CDATA[ (1 of 4)</name>
                            <sourcecode type="json"><![CDATA[
{
  "jti": "dbae9d7506b34329aa7f2f0d3827848b",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a"
  },
  "txn": "2d80e537a3f64622b0347b641ebc8f44:1",
  "events":{
    "urn:ietf:params:scim:event:misc:asyncresp": {
         "method": "POST",
         "bulkId": "qwerty",
         "version": "W\/\"oY4m4wn58tkVjJxK\"",
         "status": "201"
    }
  },
  "iat": 1458505044,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                        </figure>
                        <figure anchor="exampleAsyncBulk2">
                            <name>Example SCIM Asynchronous Response Event Operation 2/4</name>
                            <artwork type="" align="left" alt=""><![CDATA[ (2 of 4)</name>
                            <sourcecode type="json"><![CDATA[
{
  "jti": "ca977d05ba5c43929e3a69023d5392a9",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/b7c14771-226c-4d05-8860-134711653041"
  },
  "txn": "2d80e537a3f64622b0347b641ebc8f44:2",
  "events":{
    "urn:ietf:params:scim:event:misc:asyncresp": {
          "method": "PUT",
          "version": "W\/\"huJj29dMNgu3WXPD\"",
          "status": "200"
    }
  },
  "iat": 1458505045,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                        </figure>
                        <figure anchor="exampleAsyncBulk3">
                            <name>Example SCIM Asynchronous Response Event Operation 3/4</name>
                            <artwork type="" align="left" alt=""><![CDATA[ (3 of 4)</name>
                            <sourcecode type="json"><![CDATA[
{
  "jti": "4bb87d70a4ab463bbdcd1f99111cbbf1",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc"
  },
  "txn": "2d80e537a3f64622b0347b641ebc8f44:3",
  "events":{
    "urn:ietf:params:scim:event:misc:asyncresp": {
          "method": "PATCH",
          "version": "W\/\"huJj29dMNgu3WXPD\"",
          "status": "200"
    }
  },
  "iat": 1458505046,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                        </figure>
                        <figure anchor="exampleAsyncBulk4">
                            <name>Example SCIM Asynchronous Response Event Operation 4/4</name>
                            <artwork type="" align="left" alt=""><![CDATA[ (4 of 4)</name>
                            <sourcecode type="json"><![CDATA[
{
  "jti": "6a7843a7f5244d0eb62ca38b641d9139",
  "sub_id": {
    "format": "scim",
    "uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b"
  },
  "txn": "2d80e537a3f64622b0347b641ebc8f44:4",
  "events":{
    "urn:ietf:params:scim:event:misc:asyncresp": {
          "method": "DELETE",
          "status": "204"
    }
  },
  "iat": 1458505047,
  "iss":"https://scim.example.com",
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
  ]
}]]></artwork>
}]]></sourcecode>
                        </figure>

                    </section>
                </section>
            </section>

        </section>

        <section anchor="settxnheader" numbered="true" toc="default">
            <name>Set-Txn HTTP Response Header for Asynchronous Requests</name>
            <t>
                This specification defines a new HTTP Header field "Set-Txn" header field, "Set-Txn", which serves the purpose of conveying
                request completion information to SCIM HTTP clients that request an asynchronous response as described
                in <xref target="asyncRequest"/>.  The header field <bcp14>MUST</bcp14> be used in SCIM Responses responses when HTTP
                Status
                status code 202 Accepted (Accepted) is being returned with no message body.
            </t>
            <t>
                The "Set-Txn" HTTP Header header field value is a unique STRING (e.g., a GUID) Globally Unique Identifier (GUID)) used by the SCIM HTTP
                client to look for a matching SET event with a matching "txn" claim (see
                <xref target="RFC8417" section="2"/>) confirming the request
                completion status as described in <xref target="asyncRequest"/>.
            </t>
            <t>
                Intermediaries <bcp14>SHOULD NOT</bcp14> insert, modify, or delete the field's value.
            </t>
            <t>
                SCIM clients <bcp14>MAY</bcp14> ignore the header in cases where confirmation of completion is not required. For
                example
                example, a SCIM client may simply not want to wait for synchronous completion.
            </t>
        </section>

        <section anchor="serviceProviderConfig" numbered="true" toc="default">
            <name>Events Discovery Schema for Service Provider Configuration</name>
            <t><xref section="5" target="RFC7643"/> defines SCIM Service Provider service provider configuration schemas. This section
            defines additional attributes that enable a SCIM Client client to discover the additional capabilities defined
            by this specification.</t>
            <dl newline="true">
                <dt>securityEvents</dt>
                <dt>securityEvents:</dt>
                <dd>
                    <t>
                        A SCIM Complex complex attribute that specifies the available capabilities
                        related to asynchronous Security Events based on <xref target="RFC8417"/>. This attribute is <bcp14>OPTIONAL</bcp14> <bcp14>OPTIONAL</bcp14>, and
                        when absent absent, it indicates the SCIM Service Provider service provider does not support or is not currently configured for Security Events.
                        The following sub-attributes are defined: </t>
                    <dl newline="true">
                        <dt>asyncRequest</dt>
                        <dt>asyncRequest:</dt>
                        <dd>
                            <t>
                                A case-insensitive string value specifying one of the following:</t>
                                <ul>
                                    <li>"none" indicates that asynchronous SCIM requests defined in <xref target="asyncRequest"/> are not supported; </li>
                                    <li>"long" indicates that the server completes requests asynchronously at server the server's discretion (e.g. (e.g.,
                                    based on a max wait time);</li> time); and</li>
                                    <li>"request" indicates that the server completes requests asynchronously when requested by
                                        the SCIM Client.</li> client.</li>
                                </ul>
                        </dd>
                        <dt>eventUris</dt>
                        <dt>eventUris:</dt>
                        <dd>

                            <t>
                                A multivalued string listing the SET Event URIs (defined in <xref target="RFC8417"/>) that
                                the server is capable of generating and deliverable delivering via a SET Stream (see <xref target="RFC8935"/> and <xref target="RFC8936"/>).
                                This information is informational only. Stream registration and configuration are out of scope of this specification.
                            </t>
                        </dd>
                    </dl>
                </dd>
            </dl>

        </section>
        <section anchor="Security" toc="default" numbered="true">
            <name>Security Considerations</name>
            <t>
                As this specification is based upon the Security Event Tokens SETs specification and the associated delivery specifications specifications, the
                following
                Security Considerations security considerations are also applicable to this specification:
            </t>
            <ul>
                <li><xref section="5" target="RFC8417"/> (Security Event Token)</li>
                <li><xref section="5" target="RFC8935"/> (Push-based (Push-Based SET Delivery Using HTTP)</li>
                <li><xref section="4" target="RFC8936"/> (Poll-Based SET Delivery Using HTTP) </li>
            </ul>
            <t>
                SETs may contain sensitive information, including Personally Identifiable Information (PII). In such
                cases, SET Transmitters and SET Recipients <bcp14>MUST</bcp14> protect the confidentiality of the SET contents in transit
                using TLS <xref target="BCP195"/>.
            </t>
            <t>
                When co-ordinating coordinating provisioning between entities, the long-term series of changes may be critical to the
                information integrity and recovery requirements of both sides. To address this, Event Publishers can
                make events available for receivers for longer periods of time than might typically be used for recovering
                from momentary delivery failures and retries per <xref target="RFC8935"/> or <xref target="RFC8936"/>.
                Similarly, Event Receivers <bcp14>MUST</bcp14> ensure events are persisted
                directly or indirectly to meet local recovery needs before acknowledging the SET Events were received.
            </t>
            <t>
                An attacker might leverage transaction and/or signal information contained in a SET Event Publisher or
                Receiver system. To mitigate this, access to event recovery and forwarding <bcp14>MUST</bcp14> be limited to the
                parties needed to support recovery or SET forwarding.
            </t>
            <t>
                When SET Events are transferred in such a way as that the Event Publisher is not communicating directly to the
                Event Receiver, it may become possible for an attacker or other system to insert an event.
                To mitigate, Event Receivers <bcp14>MUST</bcp14> verify the originator of a SET using JWS JSON Web
              Signature (JWS) <xref target="RFC7515"/>
                signatures when the Event Publisher is not communicating directly with the Event Receiver.
                Validating event signatures may also be useful for auditing purposes as signed SET Events are protected from tampering in the event that
                an intermediate system, such as a TLS-terminating proxy, decrypts the SET payload before sending it onward
                to its intended recipient.
            </t>
            <t>
                In operation, some SCIM Resources resources such as SCIM Groups may have a high rate of change. For examples example, groups
                with more than a few thousand member values could lead to excessive change rates that rates, which could lead to a
                loss of SET Events between Event Publishers and Event Receivers. To mitigate this risk, consider the
                following to help mitigate with throughput issues:
                </t>
            <ul>
                <li>
                    The use of SCIM PUT (<xref section="3.5.1" target="RFC7644"/>), particularly with large SCIM Groups,
                    can result in excessive data being
                    conveyed in Security Event payloads. Instead, it is <bcp14>RECOMMENDED</bcp14> to use SCIM PATCH
                    (<xref target="RFC7644" section="3.5.2"/>) to focus on updating and notifying about changed information. Alternatively,
                    use SCIM PUT Event Notice (urn:ietf:params:scim:event:prov:put:notice) as a trigger to later retrieve the
                    full information when needed.
                </li>
                <li>
                    Use SCIM Patch Event Notice (urn:ietf:params:scim:event:prov:patch:notice) to reduce event content combined with
                    periodic SCIM GETs (see <xref section="3.4" target="RFC7644"/>) to retrieve current group state.
                </li>
                <li>

                    Aggregate multiple PATCH Events into a single event. Providing If providing the exact date of each membership change
                    is not critical but instead that the information content remains intact. critical, consider using a PATCH to aggregate multiple membership changes into a single event.                </li>
            </ul>
            <t>
                When using Asynchronous asynchronous SCIM Requests requests (see <xref target="asyncRequest"/>), a SCIM Service service provider returns
                a SCIM Accepted response with a URI for retrieving the event result. An unauthorized entity or attacker
                could obtain asynchronous request completion event Asynchronous Request Completion Event information by querying the asynchronous operation
                result endpoint used by a SCIM Service Provider. service provider. To mitigate, the returned URI endpoint <bcp14>MUST</bcp14> be
                protected requiring and requires an HTTP Authorization header or some other form of client authentication.
            </t>
        </section>
        <section anchor="Privacy" toc="default" numbered="true">
            <name>Privacy Considerations</name>
            <t>
                As this specification is based upon the Security Event Tokens SET specification and the associated delivery specifications specifications, the following
                Privacy Considerations
                privacy considerations are also applicable to this specification:
            </t>
            <ul>
                <li><xref section="6" target="RFC8417"/> (Security Event Token)</li>
                <li><xref section="6" target="RFC8935"/> (Push-based (Push-Based SET Delivery Using HTTP)</li>
                <li><xref section="5" target="RFC8936"/> (Poll-Based SET Delivery Using HTTP) </li>
            </ul>
            <t>
                This specification enables the sharing of information between domains. The specification assumes domains; therefore, it is assumed
                that implementers and deployers are operating under one of the following scenarios:
            </t>
            <ul>
                <li>A common administrative domain where there is one administrative owner of the data. In these cases,
                the goal is to protect privacy and security of the owner and user data by keeping information
                systems co-ordinated coordinated and up-to-date. up to date. For example, the domains decide to use Domain Based Replication DBR
                mode to keep employee information synchronized.
                </li>
                <li>In a co-operative cooperative or co-ordinated coordinated relationship, parties have decided to share a limited amount
                of data and/or signals for the benefits of their users. Depending on end-user consent, information
                is shared on an as-authorized and/or as-needed basis. For example, the domains agree to use Co-ordinated
                Provision CP mode that exchanges things like such as account status or specific minimal attribute information
                that must be fetched on request after receiving notice of a change. This enables authorization to
                be verified each time data is transferred.
                </li>
            </ul>
            <t>In general, the sharing of SCIM Event information falls within a pre-existing SCIM Client client and Service
            Provider service
            provider relationship and carry carries no additional personal information.</t>

        </section>
        <section anchor="IANA" numbered="true" toc="default">
          <name>IANA Considerations</name>

<!-- [rfced] In Section 7.4, the header of the first column in
Table 1 is "Event URI", but it is "Schema URI" in the
"SCIM Event URIs" registry <https://www.iana.org/assignments/scim/>.
Do you prefer to use "Event URI" or "Schema URI"?  Note that we
will communicate any changes to the registry to IANA.

Action: use "Event URI" and update the "SCIM Event URIs" registry accordingly.
-->
            <section anchor="IANAheader" numbered="true" toc="default">
              <name>SCIM Asynchronous Txn Set-Txn Header Registration</name>

                <t>
                    This specification registers the HTTP "Set-Txn" field name in the "HTTP "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in <xref target="RFC9110" section="16.3.1"/>.
                </t>
                <dl newline="false" spacing="normal"> spacing="compact">
                    <dt>Field name:</dt><dd>Set-Txn</dd>
                    <dt>Status:</dt><dd>Permanent</dd>
                    <dt>Reference:</dt><dd>See Section <xref
                    <dt>Status:</dt><dd>permanent</dd>
                    <dt>Reference:</dt><dd><xref target="settxnheader"/> of this document.</dd> RFC 9967.</dd>
                </dl>
            </section>
            <section anchor="spcRegister" numbered="true" toc="default">
                <name>Registering Event Capability with Scim Service Provider Config</name>
                <t>
                    For the SCIM Schema Registry <xref section="10.4" target="RFC7643"/>, under Service Provider
                    Configuration Schema ("urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"),
                    add Configuration</name>
                <t>A reference to <xref target="serviceProviderConfig"/> of this document has been added to the Reference column. "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" entry in the "SCIM Server-Related Schema URIs" registry (<xref section="10.4" target="RFC7643"/>) under the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group.
		</t>
	    </section>
            <section anchor="IANAevents" numbered="true" toc="default">
                <name>Registration
                <name>Creation of the SCIM Event URIs Registry</name>
                <t>
                    IANA will add has created a new registry called "SCIM Event URIs" to under the "System for Cross-domain Identity
                    Management (SCIM) Schema URIs" registry group define by <xref (<xref target="RFC7643" section="10.1"/> section="10.1"/>)
                    at https://www.iana.org/assignments/scim. <eref brackets="angle" target="https://www.iana.org/assignments/scim"/>.
                </t>
                <t>
                    The registration procedure is Expert Review <xref target="RFC8126"/>. New registrations for this registry are evaluated by a designated expert(s)
                    for relevance to SCIM-based systems, and, systems and to avoid possible duplication or conflict
                    with other event definitions that may lie outside SCIM (e.g., Shared Signals <xref target="SSF"/>).
                </t>
                <dl newline="true">
                    <dt>Namespace ID:</dt>
                    <dd>
                        The sub-namespace ID of "event" is assigned within the "scim" namespace.
                    </dd>
                    <dt>Syntactic Structure:</dt>
                    <dd>
                        <t>The Namespace Specific String (NSS) of all URNs that use the "event" Namespace ID has the
                            following structure:</t>
                        <sourcecode><![CDATA["urn:ietf:params:scim:event:{class}:{name}:{other}"]]></sourcecode>
 <sourcecode><![CDATA[
"urn:ietf:params:scim:event:{class}:{name}:{other}"]]></sourcecode>
                        <t>The keywords have the following meaning:</t>
                        <dl newline="true">
                            <dt>class</dt>
                            <dd>The class of events events, which is one of: "feed", "prov" "prov", or "misc".</dd>

                            <dt>name</dt>
                            <dd>A US-ASCII ASCII string that conforms to URN syntax requirements (see <xref target="RFC8141"/>)
                                and defines a descriptive event name (e.g., "create").</dd>
                            <dt>other</dt>
                            <dd>An optional US-ASCII ASCII string that conforms to URN syntax requirements (see <xref target="RFC8141"/>)
                                and serves as an additional sub-category or qualifier. For example qualifier, for example, "full" and "notice".</dd>
                        </dl>
                    </dd>
                    <dt>Identifier Uniqueness Considerations:</dt>
                    <dd>The designated contact is responsible for reviewing and enforcing uniqueness.</dd>
                    <dt>Identifier Persistence Considerations:</dt>
                    <dd>Once a name has been allocated allocated, it <bcp14>MUST NOT</bcp14> be
                        re-allocated
                        reallocated for a different purpose. The rules provided for
                        assignments the
                        assignment of values within a sub-namespace <bcp14>MUST</bcp14> be constructed
                        so that the meaning of values cannot change. This registration
                        mechanism is not appropriate for naming values whose meaning may
                        change over time.</dd>
                    <dt>Registration format:</dt> Format:</dt>
                    <dd>
                        <t>An event registration <bcp14>MUST</bcp14> include the following fields:</t>
                        <ul>
                            <li>Event Uri</li> URI</li>
                            <li>Descriptive Name</li> name</li>
                            <li>Reference to event definition</li>
                        </ul>
                        <t>Initial values to be added to the SCIM Events Registry are listed in <xref target="initialEvents"/>.</t>
                    </dd>
                </dl>

            </section>
            <section anchor="initialEvents" numbered="true" toc="default">
                <name>Initial Events Contents of the SCIM Event URIs Registry</name>

                <t keepWithNext="true">Summary of keepWithNext="true">IANA has added the following initial entries to the "SCIM Event URI registrations:</t> URIs" registry:</t>
                <table>
                <thead>
                    <tr>
                        <th align="left">Event URI</th>
                        <th align="left">Name</th>
                        <th align="left">Ref.</th> align="left">Reference</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:feed:add</td>
                        <td align="left">Resource added to Feed Event</td>
                        <td align="left">
                            <xref target="feedAdd" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:feed:remove</td>
                        <td align="left">Remove resource From from Feed Event</td>
                        <td align="left">
                            <xref target="feedRemove" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:create:
                            notice</td>
                        <td align="left">New Resource Event (notice only)</td>
                        <td align="left">
                            <xref target="provCreate" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:create:
                            full</td>
                        <td align="left">New Resource Event (full data)</td>
                        <td align="left">
                            <xref target="provCreate" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:patch:
                            notice</td>
                        <td align="left">Resource Patch Event (notice only)</td>
                        <td align="left">
                            <xref target="provPatch" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:patch:
                            full</td>
                        <td align="left">Resource Patch Event (full data)</td>
                        <td align="left">
                            <xref target="provPatch" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:put:
                            notice</td>
                        <td align="left">Resource Put Event (notice only)</td>
                        <td align="left">
                            <xref target="provPut" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:put:full</td>
                        <td align="left">Resource Put Event (full data)</td>
                        <td align="left">
                            <xref target="provPut" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:delete</td>
                        <td align="left">Resource Deleted Event</td>
                        <td align="left">
                            <xref target="provDelete" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:activate</td>
                        <td align="left">Resource Activated Event</td>
                        <td align="left">
                            <xref target="provActivate" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:prov:deactivate</td>
                        <td align="left">Resource Deactivated Event</td>
                        <td align="left">
                            <xref target="provDeactivate" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>
                    <tr>
                        <td align="left">urn:ietf:params:scim:event:misc:asyncresp</td>
                        <td align="left">Asynchronous Request Completion</td>
                        <td align="left">
                            <xref target="asyncEvent" format="default"/> of this document. RFC 9967
                        </td>
                    </tr>

                </tbody>
            </table>
            </section>
        </section>
    </middle>
    <back>
       <displayreference   target="I-D.hunt-idevent-scim" to="SCIM-EVENT-EXT"/>
        <references>
            <name>References</name>
            <references>
                <name>Normative References</name>

<!-- [Note to Ted] I'm not sure what to do with the BCP 0195 ref. Please review. -->

                <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml"/>

                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7240.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7643.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7644.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8935.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8936.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8417.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9493.xml"/>

            </references>

            <references>
                <name>Informative References</name>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-hunt-idevent-scim-00.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

<!-- [I-D.hunt-idevent-scim]
draft-hunt-idevent-scim-00
IESG State: Expired as of 5/4/26
-->
<reference anchor="I-D.hunt-idevent-scim" target="https://datatracker.ietf.org/doc/html/draft-hunt-idevent-scim-00">
   <front>
      <title>SCIM Event Extension</title>
      <author initials="P." surname="Hunt" fullname="Phil Hunt" role="editor">
         <organization>Oracle</organization>
      </author>
      <author initials="W." surname="Denniss" fullname="William Denniss">
         <organization>Google</organization>
      </author>
      <author initials="M." surname="Ansari" fullname="Morteza Ansari">
         <organization>Cisco</organization>
      </author>
      <date month="March" day="20" year="2016" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-hunt-idevent-scim-00" />
</reference>

                <reference anchor="SSF"> anchor="SSF" target="https://openid.net/specs/openid-sharedsignals-framework-1_0.html">
                    <front>
                        <title>Shared
                        <title>OpenID Shared Signals Framework</title>
                        <author><organization>OpenID Foundation</organization></author> Framework Specification 1.0</title>
                        <author fullname="A. Tulshibagwale"/>
                        <author fullname="T. Cappalli"/>
                        <author fullname="M. Scurtescu"/>
                        <author fullname="A. Backman"/>
                        <author fullname="J. Bradley"/>
                        <author fullname="S. Miel"/>
                        <date day="29" month="August" year="2025"/>
                    </front>
                    <format target="https://openid.net/specs/openid-sharedsignals-framework-1_0.html" type="HTML"/>
                </reference>
            </references>
        </references>
        <section anchor="modes" numbered="true" toc="default">
            <name>Use Cases</name>
            <t>
                SCIM Events may be used in a number of ways. The following non-normative sections describe some of
                the expected uses.
            </t>

            <section anchor="replication" toc="default" numbered="true">
                <name>Domain Based
                <name>Domain-Based Replication</name>
                <t>
                    The objective of "Domain Based Replication" DBR events (DBR) is to synchronize resource changes between
                    SCIM Service Providers service providers in a common administrative domain. In this mode, complete information about
                    modified resources are shared between replicas for immediate processing.
                </t>
                <figure align="left" anchor="dbrSequence">
                    <name>Domain Based
                    <name>Domain-Based Replication Sequence</name>
                    <artset>
                        <artwork type="ascii-art"><![CDATA[
                  +----------------+
                  |  SCIM
+-------------+   +---------------------+   +------------------------+
|SCIM Client A A|   |SCIM Service Provider|   |Service Provider Replica|
+-------------+   +---------------------+   +------------------------+
       |                     |                           |
                  +----------------+
       | [1] SCIM Operation  |
                           v
                  +----------------+
                  | Service                           |
       |-------------------->|                           | Provider
       |
                  +----------------+
                           ^ [2] SCIM Response   |                           |
                           v
                  +------------------------+
       |<--------------------|                           |
       | Service Provider                     |                           | Replica
       |
                  +------------------------+                     | [3] Event SCIM:prov:<op> id=xyz  |
                           v
                  +----------------+
       |                     |          id:xyz           |
       |                     |- - - - - - - - - - - - - >|
       |                     |                           |
       |                     |     [4] Update local node |--+
       |                     |                           |  | node [4]
       |
                  +----------------+]]></artwork>                     |                           |<-+
       |                     |                           |
       v                     v                           v]]></artwork>
                        <artwork align="center" type="svg">
                    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 697.0 550.0">

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

    <rect x="0.0" y="0.0" width="697.0" height="594.0" fill="#FFFFFF" fill-opacity="1.0"/>
    <g class="ParticipantView">
        <rect x="60.0" y="60.0" width="129.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="124.5" y="90.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Client fill-opacity="1.0">SCIM Client A</text>
    </g>
    <g class="ParticipantView">
        <rect x="209.0" y="50.0" width="180.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="299.0" y="82.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM</text>
        <text x="299.0" y="99.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider</text>
    </g>
    <g class="ParticipantView">
        <rect x="409.0" y="60.0" width="228.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="523.0" y="90.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider Replica</text>
    </g>
    <g class="LifelineView">
        <line x1="124.0" y1="121.0" x2="126.0" y2="472.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="298.0" y1="132.0" x2="300.0" y2="462.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="522.0" y1="121.0" x2="524.0" y2="472.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="291.0" y="193.0" width="16.0" height="115.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="515.0" y="300.0" width="16.0" height="56.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalMessageView">
        <text x="208.0" y="180.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[1] SCIM Operation</text>
    </g>
    <g class="SignalMessageView">
        <text x="208.0" y="225.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[2] SCIM Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="415.0" y="271.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[3] Event SCIM:prov:&lt;op&gt;</text>
        <text x="415.0" y="287.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">id:xyz</text>
    </g>
    <g class="SignalMessageView">
        <text x="511.0" y="332.5" text-anchor="end" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[4] Update local node</text>
    </g>
    <g class="SignalLineView">
        <path d="M 281.0,192.0 L 291.0,197.5 L 281.0,202.0 L 281.0, 192.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="125.0" y1="197.5" x2="281.0" y2="197.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 135.0,237.0 L 125.0,242.5 L 135.0,247.0 L 135.0, 237.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="135.0" y1="242.5" x2="291.0" y2="242.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,299.0 L 515.0,304.5 L 505.0,309.0 L 505.0, 299.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="307.0" y1="304.5" x2="505.0" y2="304.5" stroke-dasharray="5.0, 3.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 541.0,342.0 L 530.5,346.5 L 541.0,352.0 L 541.0,342.0" fill="#000000" fill-opacity="1.0"/>
        <line x1="531.5" y1="324.5" x2="570.5" y2="324.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <line x1="570.5" y1="346.5" x2="541.0" y2="346.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <path d="M 570.5,324.5 Q 580.5,324.5 580.5, 334.5 L 580.5 336.5 Q 580.5,346.5 570.5,346.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->
</svg>
                        </artwork>
                    </artset>
                  </figure>

                <t>
                    From a security perspective, it is assumed that servers sharing DBR events are secured by a common
                    access policy and all servers are required to be up-to-date. up to date.
                    From a privacy perspective, because all servers are in the same administrative domain, the primary objective
                    is to keep individual Service Provider service provider nodes or cluster clusters synchronized.
                </t>
            </section>
            <section anchor="coordination" toc="default" numbered="true">
                <name>Co-ordinated
                <name>Coordinated Provisioning</name>
                <t>
                    In "Co-ordinated Provisioning" (CP), CP, SCIM resource change events perform the function of change
                    notification without the need to provide raw data. In any Event Publisher and Receiver
                    relationship, the set of SCIM Resources resources (e.g., Users) that are linked or co-ordinated coordinated is managed
                    within the context of an event feed and may be a subset of the total set of resources on
                    either side. For example, an event feed could be limited to users who have consented to the sharing
                    of information between domains. To support capability, "feed" specific events are defined to indicate
                    the addition and removal of SCIM Resources resources from a feed. For example, when a user consents to
                    the sharing of information between domains, events about the User may be added to the feed
                    between the Event Publisher and Receiver.
                </t>

<figure align="left"><name>Co-Ordinated align="left"><name>Coordinated Provisioning Sequence</name>
<artset><artwork type="ascii-art" align="center"><![CDATA[
+-----------+  +---------------+  +-----------------+  +---------------+   +---------------+
| SCIM Clnt |
|SCIM Client|  | SCIM Service  |  | Client A Co-op| Event Receiver  | Co-op  | Coord. Action |
|   (CA)           |  |   Provider (SP)    |  | Receiver (ER)                 |  | Endpoint(LEP)   Endpoint    |
+-----------+  +---------------+   +---------------+  +-----------------+  +---------------+
      |                |                   |                   |
      | "SCIM Operation" [1] SCIM       |                   |                   |
     +----------------->|
      |     Operation  |
     |<-----------------+ "SCIM Response"                   |                   |
      |--------------->|                   |                   |
      |                |                   |                  |--> "Event SCIM:prov:<op>, id=xyz" --->|                   |
      | [2] SCIM       |                   |                   |
      |     Response   |                   |                   |
      |<---------------|                   |                   |
      |                |                   |                   |
      |                +=== loop ==========+===================+
      |                |                   |                   |
      |                | [3] Event         |                   |
      |                | SCIM:prov:<op>    |                   |
      |                | id:xyz            |                   |
      |                |- - - - - - - - - >|                   |
      |                |                   |                   |
      |                |                   | Note: Receiver    |
      |                |                   | may accumulate    |
      |                |                   | events for        |
      |                |                   | periodic action action.  |
      |                  |<------------------+ "SCIM                |                   |                   |
      |                | [4] SCIM GET <id>" <id> |                   |
      |                |<------------------|                   |
      |                |                   |                  |------------------>| "Filtered                   |
      |                | [5] Filtered      |                   |
      |                |     Resource Resp."      |                   |
      |                |     Response      |                   |
      |                |------------------>|                   |
      |                |                   |                   |
      |                |                   | [6] Coordinated   |
      |                |                   +------------------>|                   |     Action        |
      |                | "Co-ord Action"                   |------------------>|
      |                |                   |                   |
      |
]]></artwork>                +=== end loop ======+===================+
      v                v                   v                   v]]></artwork>
                        <artwork type="svg" align="center">
                       <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 912.0 857.0"> 660 620">

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

    <g transform="scale(0.7237)">
    <rect x="0.0" y="0.0" width="912.0" height="857.0" fill="#FFFFFF" fill-opacity="1.0"/>
    <g class="ParticipantView">
        <rect x="60.0" y="70.0" width="154.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="137.0" y="100.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM Client</text>
    </g>
    <g class="ParticipantView">
        <rect x="234.0" y="60.0" width="180.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="324.0" y="92.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM</text>
        <text x="324.0" y="109.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider</text>
    </g>
    <g class="ParticipantView">
        <rect x="434.0" y="60.0" width="177.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="522.5" y="92.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Client A</text>
                                    <text x="522.5" y="109.5" y="105.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Co-op fill-opacity="1.0">Event Receiver</text>
    </g>
    <g class="ParticipantView">
        <rect x="631.0" y="70.0" width="221.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="741.5" y="100.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Co-op fill-opacity="1.0">Coord. Action Endpoint</text>
    </g>
    <g class="LifelineView">
        <line x1="136.0" y1="131.0" x2="138.0" y2="735.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="323.0" y1="142.0" x2="325.0" y2="725.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="522.0" y1="142.0" x2="524.0" y2="725.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="741.0" y1="131.0" x2="743.0" y2="735.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="316.0" y="213.0" width="16.0" height="160.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="515.0" y="365.0" width="16.0" height="234.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="InteractionFrameView">
        <rect x="269.0" y="287.0" width="528.0" height="328.0" fill="#FFFFFF" fill-opacity="0.0"/>
        <path d="M 269.0,287.0 L 324.0,287.0 L 324.0,295.0 L 318.0,303.0 L 269.0,303.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <rect x="269.0" y="287.0" width="528.0" height="328.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <text x="296.5" y="295.0" text-anchor="middle" font-family="sans-serif" font-size="12.0" fill="#000000" fill-opacity="1.0">    loop    </text>
        <text x="344.0" y="295.0" text-anchor="start" font-family="sans-serif" font-size="12.0" fill="#000000" fill-opacity="1.0"/>
    </g>
    <g class="SignalMessageView">
        <text x="226.5" y="200.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[1] SCIM Operation</text>
    </g>
    <g class="SignalMessageView">
        <text x="226.5" y="245.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[2] SCIM Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="427.5" y="336.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[3] Event SCIM:prov:&lt;op&gt;</text>
        <text x="427.5" y="352.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">id:xyz</text>
    </g>
    <g class="SignalMessageView">
        <text x="419.5" y="471.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[4] SCIM GET &lt;id&gt;</text>
    </g>
    <g class="SignalMessageView">
        <text x="419.5" y="517.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[5] Filtered</text>
        <text x="419.5" y="533.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">Resource Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="636.5" y="578.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[6] Co-ordinated Coordinated Action</text>
    </g>
    <g class="SignalLineView">
        <path d="M 306.0,212.0 L 316.0,217.5 L 306.0,222.0 L 306.0, 212.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="137.0" y1="217.5" x2="306.0" y2="217.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 147.0,257.0 L 137.0,262.5 L 147.0,267.0 L 147.0, 257.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="147.0" y1="262.5" x2="316.0" y2="262.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,364.0 L 515.0,369.5 L 505.0,374.0 L 505.0, 364.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="332.0" y1="369.5" x2="505.0" y2="369.5" stroke-dasharray="5.0, 3.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 334.0,483.0 L 324.0,488.5 L 334.0,493.0 L 334.0, 483.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="334.0" y1="488.5" x2="515.0" y2="488.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,545.0 L 515.0,550.5 L 505.0,555.0 L 505.0, 545.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="324.0" y1="550.5" x2="505.0" y2="550.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 732.0,590.0 L 742.0,595.5 L 732.0,600.0 L 732.0, 590.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="531.0" y1="595.5" x2="732.0" y2="595.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="NoteView">
        <rect x="429.0" y="379.0" width="188.0" height="54.0" rx="5.0" ry="5.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <text x="443.0" y="397.5" text-anchor="start" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Receiver may accumulate</text>
        <text x="443.0" y="414.5" text-anchor="start" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">events for periodic action.</text>
    </g>

    </g>
    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

</svg>
                        </artwork>
                    </artset>
                </figure>
                <t>
                    In CP mode, the receiver of an event must call back to the originating SCIM Service Provider service provider
                    (e.g., using a SCIM GET request) to reconcile the newly changed resource in
                    order to obtain the changes.
                </t>
                <t>
                    Co-ordinated provisioning
                    CP has the following benefits:
                </t>
                <ul>
                    <li>
                        Differences in schema (e.g., attributes) between domains. For example, a receiving domain may
                        only be interested in or allowed to access to a few attributes (e.g., role-based access data) to
                        enable access to an application.
                    </li>
                    <li>
                        Different Event Receivers may have differing needs when accessing information and thus may be assigned
                        varying access rights. Minimal information events combined with callbacks for data allows
                        data filtering to be applied.
                    </li>
                    <li>
                        Receivers can take independent action. Such action such as deciding which attributes or resource lifecycle life cycle
                        changes to accept. For example, in the case of a conflict, a receiver can prioritize one domain
                        source over another.
                    </li>
                    <li>
                        A receiver may throttle or buffer changes rather than act immediately on a notification. For
                        example, for a frequently changing resource, the
                        receiver may choose to make a scheduled SCIM GET for resources that have been marked "dirty" by
                        events received in the last scheduled cycle.
                    </li>
                </ul>
                <t>
                    A disadvantage of the CP approach is that it may be considered costly in the sense that each event
                    received might trigger a callback to the event issuer. This cost should be weighed against the cost
                    producing filtered information in each event for each receiver. Furthermore, a receiver is not required
                    to make a callback on every provisioning event.
                </t>

                <t>
                    It is assumed that an underlying relationship between domains exists that permits the exchange of
                    personal information and credentials. For example, in a cross-domain scenario scenario, a SCIM Service Provider service provider
                    would have been previously authorized to perform SCIM provisioning operations and publish change events.
                    As such, appropriate confidentiality and privacy agreements should be in place between the domains.
                </t>
                <t>
                    When sharing information between parties, CP Events minimize the information shared in each message and
                    require the Security Event Receiver to receive more information from the Event Publisher as needed.
                    In this way, the Event Receiver is able to have regular access to information through normal
                    SCIM protocol access restrictions. The Event Receiver and Publisher may agree to communicate these
                    updates through a variety of transmission methods such as push push- and pull based pull-based HTTP like in <xref target="RFC8935"/>, target="RFC8935"/>
                    <xref target="RFC8936"/>, target="RFC8936"/> or HTTP GET (see <xref target="asyncRequest"/>), target="asyncRequest"/>); streaming technologies
                    (e.g., Kafka or Kinesis), Kinesis); or via webhooks such as in the <xref target="SSF" format="default">Shared Signals Framework</xref>.
                </t>

            </section>

        </section>

        <section anchor="Acknowledgements" numbered="false" toc="include">
            <name>Acknowledgements</name>

            <t>The authors would like to thank the following contributors:</t>
            <ul>
                <li><t><contact fullname="Morteza Ansari"/> and <contact
                fullname="William Denniss"/>, who contributed significantly to
                <xref target="I-D.hunt-idevent-scim"/>, target="I-D.hunt-idevent-scim"/> upon which this
                document is based.</t></li>
                <li>The participants of the SCIM working group Working Group and the
                IETF id-event mailing list for their support of this specification.</li>
                <li><t>Thanks to <contact
                <li><t><contact fullname="Deb Cooley"/>, <contact
                fullname="Dean Saxe"/>, <contact fullname="Elliot Lear"/>,
                <contact fullname="Pamela Dingle"/>, <contact fullname="Mark
                Nottingham"/>, <contact fullname="R Gideon"/>, <contact
                fullname="Paulo Jorge Correia"/>, <contact fullname="Shuping
                Peng"/>, <contact fullname="Elwyn Davies"/>, <contact
                fullname="Luigi Lannone"/>, <contact fullname="Mohamed
                Boucadair"/>, <contact fullname="Roman Danyliw"/>, <contact
                fullname="Ketan Talaulikar"/>, <contact fullname="Mahesh
                Jethanandani"/>, and <contact fullname="Mike Bishop"/> for
                their write-ups and reviews</t></li> reviews.</t></li>
            </ul>
        </section>

<!-- [rfced] Terminology

Currently updated as follows:

 Asynchronous Request Completion Event
 Asynchronous Event completion events
 Asynchronous Response Event Token
 Asynchronous Response event

 asynchronous completion events
 asynchronous request completion
 asynchronous response
 asynchronous SCIM request capability
 asynchronous SCIM request

 event feed (per RFC 8417 and other RFCs)
 event payload (per RFC 8417)

 SCIM Event
 SCIM Event Token
 Event Receiver
 Event Publisher
 PATCH Event
 SET Event
 Security Event

 SCIM Client -> SCIM client (per RFCs 7643 and 7644)
 SCIM Complex attribute -> SCIM complex attribute (per RFC 7644)
 SCIM Protocol -> SCIM protocol (per RFC 7644)
 SCIM Resource -> SCIM resource (per RFCs 7643 and 7644)
 SCIM Response -> SCIM response (per RFC 7644)
 SCIM Schema -> SCIM schema (per RFC 7643)
 SCIM Service Provider -> SCIM service provider (per RFCs 7643, 7644, and 9865)
-->

    </back>
</rfc>