rfc9967.original.xml   rfc9967.xml 
<?xml version='1.0' encoding='UTF-8'?> <?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 [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-scim-events-16" number="0000" ipr="trust200902" updates="7643, 7644" obsolete s="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs= "true" sortRefs="true" consensus="true" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-scim-events-16" number="0000" ipr="trust200902" updates="7643, 7644" obsolete s="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs= "true" sortRefs="true" consensus="true" version="3">
<front> <front>
<title abbrev="draft-ietf-scim-events">SCIM Profile for Security Event T
okens</title> <!--[rfced] Please note that the title of the document has
been updated as follows. Abbreviations have been expanded per
Section 3.6 of RFC 7322 ("RFC Style Guide"), and the short title
that spans the header of the PDF file has been updated as shown
below. Please review.
Original (document title):
SCIM Profile for Security Event Tokens
Current:
System for Cross-domain Identity Management (SCIM) Profile for
Security Event Tokens (SETs)
...
Original (short title):
draft-ietf-scim-events-16
Current:
SCIM Profile for SETs
-->
<title abbrev="SCIM Profile for SETs">System for Cross-Domain Identity M
anagement (SCIM) Profile for Security Event Tokens (SETs)</title>
<seriesInfo name="RFC" value="0000"/> <seriesInfo name="RFC" value="0000"/>
<author fullname="Phil Hunt" initials="P." role="editor" surname="Hunt"> <author fullname="Phil Hunt" initials="P." role="editor" surname="Hunt">
<organization abbrev="Independent Id">Independent Identity Inc</orga nization> <organization abbrev="Independent Id">Independent Identity Inc</orga nization>
<address> <address>
<email>phil.hunt@independentid.com</email> <email>phil.hunt@independentid.com</email>
</address> </address>
</author> </author>
<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget"> <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget">
<organization abbrev="Cisco Systems">Cisco Systems</organization> <organization abbrev="Cisco Systems">Cisco Systems</organization>
<address> <address>
skipping to change at line 42 skipping to change at line 60
<address> <address>
<email>mike.kiser@sailpoint.com</email> <email>mike.kiser@sailpoint.com</email>
</address> </address>
</author> </author>
<author fullname="Jen Schreiber" initials="J." surname="Schreiber"> <author fullname="Jen Schreiber" initials="J." surname="Schreiber">
<organization abbrev="Workday">Workday, Inc.</organization> <organization abbrev="Workday">Workday, Inc.</organization>
<address> <address>
<email>jennifer.winer@workday.com</email> <email>jennifer.winer@workday.com</email>
</address> </address>
</author> </author>
<date year="2025" month="November"/> <date year="2026" month="May"/>
<area>SEC</area> <area>SEC</area>
<workgroup>SCIM</workgroup> <workgroup>SCIM</workgroup>
<keyword>Identity</keyword> <keyword>Identity</keyword>
<keyword>Event</keyword> <keyword>Event</keyword>
<keyword>SET</keyword> <keyword>SET</keyword>
<keyword>Provisioning</keyword> <keyword>Provisioning</keyword>
<keyword>Token</keyword> <keyword>Token</keyword>
<keyword>SCIM</keyword> <keyword>SCIM</keyword>
<abstract> <abstract>
<t> <!--[rfced] Abstract: FYI, we added the RFC number of the SET specification
(RFC 8417) so that the text is more specific. Please let us know if you
prefer otherwise.
Original:
This specification defines a set of System for Cross-domain Identity
Management (SCIM) Security Events using the Security Event Token
Specification to enable the asynchronous exchange of messages between
SCIM Service Providers and receivers.
Current:
This specification defines a set of System for Cross-domain Identity
Management (SCIM) Security Events using the Security Event Token
(SET) specification (RFC 8417) to enable the asynchronous exchange of
messages between SCIM Service Providers and receivers.
-->
<t>
This specification defines a set of System for Cross-domain Iden tity Management (SCIM) This specification defines a set of System for Cross-domain Iden tity Management (SCIM)
Security Events using the Security Event Token Specification to Security Events using the Security Event Token (SET) specificati
enable the asynchronous exchange on (RFC 8417) to enable
the asynchronous exchange
of messages between SCIM Service Providers and receivers. of messages between SCIM Service Providers and receivers.
</t> </t>
<t> <t>
This draft updates RFC7643 defining additional attributes for This specification updates RFC 7643 by defining additional attri
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" sc butes for
hema and updates the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig
RFC7644 with optional new Asynchronous SCIM Request capability. " schema, and it updates
RFC 7644 with an optional new Asynchronous SCIM Request capabili
ty.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" toc="default" numbered="true"> <section anchor="intro" toc="default" numbered="true">
<name>Introduction and Overview</name> <name>Introduction and Overview</name>
<t> <t>
This specification defines Security Events for SCIM Service Prov This specification defines Security Events for SCIM Service Prov
iders and receivers as specified by the iders and receivers as specified by
Security Event Tokens (SET) <xref target="RFC8417"/>. SCIM Secur Security Event Tokens (SETs) <xref target="RFC8417"/>. In this s
ity pecification, SCIM Security
Events in this specification include: asynchronous request compl Events include asynchronous request completion, resource replica
etion, resource replication, and tion, and
provisioning co-ordination. provisioning co-ordination.
</t> </t>
<t> <t>
This specification defines the use of the HTTP Header "Prefer: r
espond-async" <xref target="RFC7240"/> <!--[rfced] The term "SCIM Protocol Client" does not appear in RFC 7644
or other RFCs, so may we update it to "SCIM client" (2 instances), which
is used in RFC 7644?
Original:
This specification defines the use of the HTTP Header "Prefer:
respond-async" [RFC7240] to allow a SCIM Protocol Client [RFC7644] to
request an asynchronous response (see Section 2.5.1.1).
Using the HTTP protocol, a SCIM Protocol Client issues commands...
Perhaps:
This specification defines the use of the HTTP Header "Prefer:
respond-async" [RFC7240] to allow a SCIM client [RFC7644] to
request an asynchronous response (see Section 2.5.1.1).
Using the HTTP protocol, a SCIM client issues commands...
-->
This specification defines the use of the HTTP header "Prefer: r
espond-async" <xref target="RFC7240"/>
to allow a SCIM Protocol Client <xref target="RFC7644"/> to requ est an asynchronous response (see <xref target="asyncRequest"/>). to allow a SCIM Protocol Client <xref target="RFC7644"/> to requ est an asynchronous response (see <xref target="asyncRequest"/>).
</t> </t>
<t> <t>
Using HTTP protocol, a SCIM Protocol Client issues commands to a SCIM Service Using the HTTP protocol, a SCIM Protocol Client issues commands to a SCIM Service
Provider using HTTP methods such as POST, PATCH, and DELETE <xre f target="RFC7644" format="default"/> Provider using HTTP methods such as POST, PATCH, and DELETE <xre f target="RFC7644" format="default"/>
that cause a state change to a SCIM Resource. When multiple inde pendent SCIM Clients update SCIM that cause a state change to a SCIM Resource. When multiple inde pendent SCIM Clients update SCIM
Resources, individual clients become out of date as state change s occur. Some clients may need to be Resources, individual clients become out of date as state change s occur. Some clients may need to be
informed of these changes for co-ordination or reconciliation pu rposes. This could be done using informed of these changes for co-ordination or reconciliation pu rposes. This could be done using
periodic SCIM GET requests over time, but this rapidly becomes p roblematic as the number of changes and the periodic SCIM GET requests over time, but this rapidly becomes p roblematic as the number of changes and the
number of resources increases. number of resources increases.
</t> </t>
<t> <t>
SCIM Events can be shared over an established Event Feed enablin g receivers to monitor and trigger SCIM Events can be shared over an established Event Feed enablin g receivers to monitor and trigger
independent asynchronous action. This approach enables greater s cale and timeliness, where only independent asynchronous action. This approach enables greater s cale and timeliness, where only
skipping to change at line 114 skipping to change at line 169
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", 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 "<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"/> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="notat" toc="default" numbered="true"> <section anchor="notat" toc="default" numbered="true">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t> <t>
Throughout this document all figures may contain spaces and Throughout this document, all figures may contain spaces and
extra extra
line-wrapping for readability and space limitations. Similar line wrapping for readability and space limitations. Similar
ly, some ly, some
URIs contained within examples, have been shortened for spac URIs contained within examples have been shortened for space
e and and
readability reasons. readability reasons.
</t> </t>
</section> </section>
<section anchor="defs" toc="default" numbered="true"> <section anchor="defs" toc="default" numbered="true">
<name>Definitions</name> <name>Definitions</name>
<t> <t>
This specification uses definitions from the following speci fications: This specification uses definitions from the following speci fications:
</t> </t>
<ul> <ul>
<li>JSON Web Tokens (JWT) <xref target="RFC7519"/>, </li> <li>"JSON Web Token (JWT)" <xref target="RFC7519"/>, </li>
<li>Security Event Tokens (SET) <xref target="RFC8417" <li>"Security Event Token (SET)" <xref target="RFC8417"
format="default"/>, and</li> format="default"/>, and</li>
<li>System for Cross-Domain Identity Management Protocol <xr ef target="RFC7644"/>. <li>"System for Cross-domain Identity Management: Protocol" <xref target="RFC7644"/>.
</li> </li>
</ul> </ul>
<t> <t>
In JSON Web Tokens and Security Event Tokens, the term "clai In JSON Web Tokens (JWTs) and Security Event Tokens, the ter
m" refers to JSON attribute m "claim" refers to JSON attribute
values contained in a JSON Web Token <xref target="RFC7519"/ values contained in a JWT <xref target="RFC7519"/> structure
> structure. The term "claim" in tokens is used . 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 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 spec context of SCIM, this distinction is not made. For this spec
ification the terms "claims" ification, the terms "claims"
and "attributes" are inter-changeable. For consistency, JWT and "attributes" are interchangeable. For consistency, JWT a
and SET IANA registered attributes will nd SET attributes registered by IANA will
continue to be called claims, while event information attrib continue to be called "claims", while event information attr
utes (i.e., those in an event payload) will be ibutes (i.e., those in an event payload) will be
referred to as attributes. referred to as "attributes".
</t> </t>
<t> <t>
Additionally, the following terms are defined: Additionally, the following terms are defined:
</t> </t>
<dl newline="true"> <dl newline="true">
<dt>Attributes and Claims</dt> <dt>Attributes and Claims:</dt>
<dd> <dd>
The JWT specification <xref target="RFC7519"/> upon whic The JWT specification <xref target="RFC7519"/>, upon whi
h SET is based uses the term "claims" to ch SET is based, uses the term "claims" to
refer to attributes in a JSON token. SCIM in contrast us refer to attributes in a JSON token. In contrast, SCIM u
es the term "attributes" to refer to ses the term "attributes" to refer to
JSON attributes. For the purposes of this draft, the ter JSON attributes. For the purposes of this document, the
ms "attributes" and "claims" are equivalent. terms "attributes" and "claims" are equivalent.
</dd> </dd>
<dt>Co-ordinated Provisioning (CP)</dt> <dt>Co-ordinated Provisioning (CP):</dt>
<dd> <dd>
Defined in <xref target="coordination"/>, in co-ordinate d provisioning As defined in <xref target="coordination"/>, in CP
relationships, an Event Publisher and Receiver typically exchange resource change events without relationships, an Event Publisher and Receiver typically exchange resource change events without
exchanging data (see <xref target="scimProvEvents"/>). F or a receiver to know the value of the data, exchanging data (see <xref target="scimProvEvents"/>). F or a receiver to know the value of the data,
the Event Receiver usually calls back the Event Receiver usually calls back
to the SCIM Event Publisher domain to receive a new copy of data (e.g., Uses a SCIM GET request). to the SCIM Event Publisher domain to receive a new copy of data (e.g., uses a SCIM GET request).
</dd> </dd>
<dt>Domain Based Replication (DBR)</dt> <dt>Domain-Based Replication (DBR):</dt>
<dd> <dd>
Defined in <xref target="replication"/>, in this domain- As defined in <xref target="replication"/>, in the DBR m
based replication ode,
mode there is an administrative relationship spanning mu there is an administrative relationship spanning multipl
ltiple operational domains, data e operational domains; data
shared in Events typically uses the "full" mode variatio n of change events (see <xref target="scimProvEvents"/>) including shared in Events typically uses the "full" mode variatio n of change events (see <xref target="scimProvEvents"/>) including
the "data" payload attribute. This eliminates the need f or a callback the "data" payload attribute. This eliminates the need f or a callback
to retrieve additional data. to retrieve additional data.
</dd> </dd>
<dt>Event Feed / Event Stream</dt> <dt>Event Feed / Event Stream:</dt>
<dd> <dd>
An Event Feed (equivalently Event Stream) is a logical s eries of events shared with a unique receiving client. An Event Feed (or equivalently an Event Stream) is a log ical series of events shared with a unique receiving client.
A SET transfer (see <xref target="RFC8935"/> and <xref t arget="RFC8936"/>) Service Provider may A SET transfer (see <xref target="RFC8935"/> and <xref t arget="RFC8936"/>) Service Provider may
offer to allow Event Receivers to "subscribe" to specifi c event types or events about specific offer to allow Event Receivers to "subscribe" to specifi c event types or events about specific
resources (see Feed Management events in <xref target="s cimFeedEvents"/>). resources (see Feed Management events in <xref target="s cimFeedEvents"/>).
</dd> </dd>
<dt>Event Receiver</dt> <dt>Event Receiver:</dt>
<!-- [rfced] We note that RFC 8935 does not use the terms "SET Push
Transfer" or "Push Transfer"; it does use "push-based SET
delivery". RFC 8936 does not use "SET Poll-Based Transfer" or
"Poll-Based Transfer"; it does use "poll-based SET delivery". Is
an update needed for consistency?
Original:
In the case of SET Push Transfer [RFC8935], the Event Receiver is
an HTTP Service Endpoint that receives requests. In the case of SET
Poll-Based Transfer [RFC8936], the receiver is an HTTP client that
initiates HTTP request to an Event Publisher endpoint.
Perhaps:
In the case of push-based SET delivery [RFC8935], the Event Receiver
is an HTTP Service Endpoint that receives requests. In the case of
poll-based SET delivery [RFC8936], the receiver is an HTTP client
that initiates HTTP requests to an Event Publisher endpoint.
-->
<dd> <dd>
An entity receives events typically via <xref target="RF An entity typically receives events as described in <xre
C8935"/>, <xref target="RFC8936"/>, or f target="RFC8935"/> and <xref target="RFC8936"/> or
HTTP GET (see <xref target="asyncRequest"/>). In the cas via HTTP GET (see <xref target="asyncRequest"/>). In the
e of SET Push Transfer case of SET Push Transfer
<xref target="RFC8935"/>, the Event Receiver is an HTTP Service Endpoint that receives requests. <xref target="RFC8935"/>, the Event Receiver is an HTTP Service Endpoint that receives requests.
In the case of SET Poll-Based Transfer <xref target="RFC In the case of SET Poll-based Transfer <xref target="RFC
8936"/>, the receiver is an HTTP client 8936"/>, the receiver is an HTTP client
that initiates HTTP request to an Event Publisher endpoi that initiates an HTTP request to an Event Publisher end
nt. point.
</dd> </dd>
<dt>Event Publisher</dt> <dt>Event Publisher:</dt>
<dd> <dd>
A system that issues SETs based on a resource state chan ge that has occurred at a SCIM A system that issues SETs based on a resource state chan ge that has occurred at a SCIM
Service Provider. For example, events may be the result of a SCIM Create, Modify, or Delete 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 SC IM Service Provider may be an Event Publisher or an as defined in <xref section="3" target="RFC7644"/>. A SC IM Service Provider may be an Event Publisher or an
independent service that aggregates events into Event Re ceiver feeds. As described above, when independent service that aggregates events into Event Re ceiver feeds. As described above, when
using <xref target="RFC8935"/>, the Event Publisher is a n HTTP Client that initiates HTTP POST using <xref target="RFC8935"/>, the Event Publisher is a n HTTP client that initiates HTTP POST
requests to a defined Event Receiver endpoint. When usin g <xref target="RFC8936"/>, the Event requests to a defined Event Receiver endpoint. When usin g <xref target="RFC8936"/>, the Event
Publisher provides an HTTP endpoint which a receiver may use to "poll" for Security Events. Publisher provides an HTTP endpoint, which a receiver ma y use to "poll" for Security Events.
</dd> </dd>
<dt>SCIM Client</dt> <dt>SCIM Client:</dt>
<dd> <dd>
Refers to an HTTP client that initiates SCIM Protocol <x An HTTP client that initiates SCIM protocol <xref target
ref target="RFC7644"/> requests and receives ="RFC7644"/> requests and receives
responses which may cause SCIM Events to be issued by th responses that may cause SCIM Events to be issued by the
e SCIM Service Provider. A SCIM Client may SCIM Service Provider. A SCIM Client may
also be an Event Receiver, typically when making an asyn chronous SCIM request (see <xref target="asyncRequest"/>). also be an Event Receiver, typically when making an asyn chronous SCIM request (see <xref target="asyncRequest"/>).
</dd> </dd>
<dt>SCIM Service Provider</dt> <dt>SCIM Service Provider:</dt>
<dd> <dd>
An HTTP server that implements SCIM Protocol <xref targe An HTTP server that implements the SCIM protocol <xref t
t="RFC7644"/> and SCIM Schema arget="RFC7644"/> and SCIM schema
<xref target="RFC7643"/>. Upon processing a state change <xref target="RFC7643"/>. Upon processing a state change
to a SCIM Resource, issues a SCIM Event to a SCIM Resource, it issues a SCIM Event
or causes an Event Publisher to issue a SCIM Event. or causes an Event Publisher to issue a SCIM Event.
</dd> </dd>
<dt>SET</dt> <!--[rfced] In Section 3.1, we replaced "SET" with "Security Event
Token (SET)" for consistency with how the other terms are
displayed in the list. Please let us know of any objection.
Original:
SET: Abbreviation for "Security Event Token" as defined in [RFC8417]
Current:
Security Event Token (SET): As defined in [RFC8417].
-->
<dt>Security Event Token (SET):</dt>
<dd> <dd>
Abbreviation for "Security Event Token" as defined in <x ref target="RFC8417"/> As defined in <xref target="RFC8417"/>.
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="scimEvents" numbered="true" toc="default"> <section anchor="scimEvents" numbered="true" toc="default">
<name>SCIM Events</name> <name>SCIM Events</name>
<t> <t>
A SCIM event is a signal, in the form of a Security Event Token <xref target="RFC8417" format="default"/>, A SCIM 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 consist s of a set of standard JWT "top-level" that describes some event that has occurred. A SET event consist s 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 claims and an "events" claim that contains one or more event URI subclaims (JSON attributes) each with a
JSON object containing relevant event information. JSON object containing relevant event information.
</t> </t>
<t> <t>
This specification defines a new URI prefix "urn:ietf:params:sci This specification defines the new URI prefix "urn:ietf:params:s
m:event" which is used cim:event", which is used
as the prefix for the following defined SCIM Events (see <xref t as the prefix for the defined SCIM Events (see <xref target="IAN
arget="IANAevents"/>). Events are grouped Aevents"/>). Events are grouped
into one of two sub-namespaces: "feed" (feed control notices) or "prov" (provisioning). into one of two sub-namespaces: "feed" (feed control notices) or "prov" (provisioning).
</t> </t>
<section anchor="sub-id" numbered="true" toc="default"> <section anchor="sub-id" numbered="true" toc="default">
<name>Identifying the Subject of an Event</name> <name>Identifying the Subject of an Event</name>
<t> <t>
SCIM Events <bcp14>MUST</bcp14> use the "sub_id" claim, defi ned by <xref target="RFC9493"/>, to identify the SCIM Events <bcp14>MUST</bcp14> use the "sub_id" claim, defi ned 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 locate d within an event subject of events. The "sub_id" claim <bcp14>MUST</bcp14> be contained within the main JWT claims body and <bcp14>MUST NOT</bcp14> be locate d within an event
payload within the "events" claim. A SET with multiple event URIs indicates that the events 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. arise from the same transaction or resource state change for a single resource or subject.
</t> </t>
<t> <t>
The JWT "sub" claim <bcp14>MUST NOT</bcp14> be used to ident ify subjects to prevent confusion with JWT The JWT "sub" claim <bcp14>MUST NOT</bcp14> be used to ident ify subjects to prevent confusion with JWT
authorization tokens (originally recommended in <xref sectio n="3" target="RFC8417"/>). authorization tokens (originally recommended in <xref sectio n="3" target="RFC8417"/>).
</t> </t>
<figure anchor="example_subid"> <figure anchor="example_subid">
<name>SCIM Subject Id Example</name> <name>Example SCIM Subject Id</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json" ><![CDATA[
{ {
"iss": "issuer.example.com", "iss": "issuer.example.com",
"iat": 1508184845, "iat": 1508184845,
"aud": "aud.example.com", "aud": "aud.example.com",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "alice@example.com" "externalId": "alice@example.com"
}, },
"events": { "events": {
... ...
} }
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t> <t>
Instead of "sub", the top-level claim "sub_id" <bcp14>SHALL< /bcp14> be used. "sub_id" contains the subclaim attribute 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 the attributes present in the "sub_id" "format" set to "scim" to indicate that the attributes prese nt in the "sub_id"
object are SCIM attributes. The following "sub_id" attribute s are defined: object are SCIM attributes. The following "sub_id" attribute s are defined:
</t> </t>
<!--[rfced] In Sections 2.1, 2.2, and 4, may we add colons to the list of
terms/attributes that are defined, or do you prefer no colons?
One example
Original:
uri
The SCIM relative path for the resource which usually consists of
the resource type endpoint plus the resource "id" ...
Perhaps
uri:
The SCIM relative path for the resource that usually consists of
the resource type endpoint plus the resource "id" ...
-->
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>uri</dt> <dt>uri</dt>
<dd> <dd>
The SCIM relative path for the resource which usually co The SCIM relative path for the resource that usually con
nsists of the resource type endpoint sists of the resource type endpoint
plus the resource "id" (see <xref section="3.2" target=" plus the resource "id" (see <xref section="3.2" target="
RFC7644"/>). For example RFC7644"/>), for example,
"/Users/2b2f880af6674ac284bae9381673d462". "/Users/2b2f880af6674ac284bae9381673d462".
This attribute <bcp14>MUST</bcp14> be provided in a SCIM Event "sub_id" claim. Note the relative path 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 Ba se URI as defined in <xref target="RFC7644" section="1.3"/>. is the path component after the SCIM Service Provider Ba se URI as defined in <xref target="RFC7644" section="1.3"/>.
In cases where the Event Receiver is unable to match a U RI, the Event Receiver <bcp14>MAY</bcp14> issue a callback In cases where the Event Receiver is unable to match a U RI, the Event Receiver <bcp14>MAY</bcp14> issue a callback
to a previously agreed SCIM Service Provider Base URI pl us the relative "uri" value and to a previously agreed SCIM Service Provider Base URI pl us the relative "uri" value and
perform a SCIM GET request per <xref target="RFC7644" se ction="3.4.1"/>. perform a SCIM GET request per <xref target="RFC7644" se ction="3.4.1"/>.
</dd> </dd>
<dt>externalId</dt> <dt>externalId</dt>
<dd> <dd>
If known, the "externalId" value (defined in <xref targe t="RFC7643" section="3.1"/>) of the SCIM If known, the "externalId" value (defined in <xref targe t="RFC7643" section="3.1"/>) of the SCIM
Resource that <bcp14>MAY</bcp14> be used by a receiver t o identify the corresponding resource in the Event Resource that <bcp14>MAY</bcp14> be used by a receiver t o identify the corresponding resource in the Event
Receiver's domain. Receiver's domain.
</dd> </dd>
<dt>id</dt> <dt>id</dt>
<!--[rfced] Section 3.1 of [RFC7643] uses "id" rather than "Id". Is an
update needed in this sentence for consistency?
Current:
id
The SCIM Id attribute (defined in Section 3.1 of [RFC7643]) MAY be
used for backwards compatibility reasons in addition to the "uri"
claim.
Perhaps:
id
The SCIM "id" attribute (defined in Section 3.1 of [RFC7643]) MAY be
used for backwards compatibility reasons in addition to the "uri"
claim.
-->
<dd> <dd>
The SCIM Id attribute (defined in <xref section="3.1" ta rget="RFC7643"/>) <bcp14>MAY</bcp14> be used for backwards The SCIM Id attribute (defined in <xref section="3.1" ta rget="RFC7643"/>) <bcp14>MAY</bcp14> be used for backwards
compatibility reasons in addition to the "uri" claim. compatibility reasons in addition to the "uri" claim.
</dd> </dd>
</dl> </dl>
<t> <t>
In cases where SCIM identifiers ("id" and "externalId") are not enough to identify a In cases where SCIM identifiers ("id" and "externalId") are not enough to identify a
common resource between an Event Publisher and Event Receive r, common resource between an Event Publisher and Event Receive r,
the "sub_id" object <bcp14>MAY</bcp14> contain attributes wh ose SCIM attribute types have "uniqueness" set to the "sub_id" object <bcp14>MAY</bcp14> contain attributes wh ose SCIM attribute types have "uniqueness" set to
"server" or "global" as per <xref section="7" target="RFC764 "server" or "global" as per <xref section="7" target="RFC764
3"/>. For example, attributes such as 3"/>.
<!-- [rfced] Section 4 of [RFC7643] uses "userName" rather than
"username" when referring to the attribute. Should this text
be updated accordingly?
Section 2.1
Current:
For example, attributes such as "emails" or "username" (defined in
Section 4 of [RFC7643]) are unique with in a SCIM Service Provider.
Perhaps:
For example, attributes such as "emails" or "userName" (defined in
Section 4 of [RFC7643]) are unique with in a SCIM Service Provider.
...
Section 2.2
Current:
For example: "attributes": ["username","emails","name.familyName"]
Perhaps:
For example: "attributes": ["userName","emails","name.familyName"]
-->
For example, attributes such as
"emails" or "username" (defined in <xref section="4" target= "RFC7643"/>) are unique "emails" or "username" (defined in <xref section="4" target= "RFC7643"/>) are unique
with in a SCIM Service Provider. Such attributes should allo w an Event Publisher and Event Receiver within a SCIM Service Provider. Such attributes should allow an Event Publisher and Event Receiver
to identify a commonly understood subject resource of an eve nt. to identify a commonly understood subject resource of an eve nt.
</t> </t>
</section> </section>
<section anchor="attributes" numbered="true" toc="default"> <section anchor="attributes" numbered="true" toc="default">
<name>Common Event Attributes</name> <name>Common Event Attributes</name>
<t>The following attributes are available for all events defined . Some attributes are defined as SET/JWT <t>The following attributes are available for all events defined . Some attributes are defined as SET/JWT
claims, while others are "Event Payload" claims as defined i n <xref section="1.2" target="RFC8417"/>. claims, while others are "Event Payload" claims as defined i n <xref section="1.2" target="RFC8417"/>.
Only one of "data" or "attributes" claims <bcp14>MUST</bcp14 > be provided depending on the event Only one of the claims, "data" or "attributes", <bcp14>MUST< /bcp14> be provided depending on the event
definition. definition.
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>txn</dt> <dt>txn</dt>
<dd> <dd>
"txn" is a SET-defined claim with a STRING value (see <x ref section="2.2" target="RFC8417"/>) A SET-defined claim with a STRING value (see <xref secti on="2.2" target="RFC8417"/>)
that uniquely identifies a transaction originating at a SCIM Service Provider and/or its underlying data that uniquely identifies a transaction originating at a SCIM Service Provider and/or its underlying data
repository or database where one or more SCIM Events may be subsequently issued. In contrast to 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 "jti" claim (see <xref section="4.1.7" target="RFC7519 "/>), which uniquely identifies
a token, the "txn" remains the same when a token, the "txn" remains the same when
one or more SETs are generated for various purposes such one or more SETs are generated for various purposes such
as re-transmission, publication to as retransmission, publication to
multiple receivers etc. A distinct state change or trans multiple receivers, etc. A distinct state change or tran
action within a SCIM Service Provider saction within a SCIM Service Provider
<bcp14>MAY</bcp14> result in multiple SETs issued each w <bcp14>MAY</bcp14> result in multiple SETs issued each w
ith distinct "jit" values an a common ith distinct "jit" values and a common
"txn" value. "txn" is <bcp14>REQUIRED</bcp14> to support asynchronous SCIM requests, "txn" value. "txn" is <bcp14>REQUIRED</bcp14> to support asynchronous SCIM requests,
co-ordinated provisioning, and replication to disambigua te or detect duplicate SETs regarding CP, and replication to disambiguate or detect duplicate SETs regarding
the same underlying transaction. the same underlying transaction.
</dd> </dd>
<dt>version</dt> <dt>version</dt>
<dd> <dd>
The Etag version of the resource as a result of the even t and corresponds to the Etag The ETag version of the resource as a result of the even t. Corresponds to the ETag
response header described in <xref target="RFC7644" sect ion="3.14"/>. response header described in <xref target="RFC7644" sect ion="3.14"/>.
</dd> </dd>
<dt>data</dt> <dt>data</dt>
<dd> <dd>
This event payload attribute contains information descri bed in the SCIM Bulk An event payload attribute that contains information des cribed in the SCIM Bulk
Operations "data" attribute in <xref section="3.7" targe t="RFC7644"/>. The JSON object Operations "data" attribute in <xref section="3.7" targe t="RFC7644"/>. The JSON object
contains the equivalent SCIM command processed by the SC IM Service Provider. For example, after contains the equivalent SCIM command processed by the SC IM Service Provider. For example, after
processing a SCIM Create operation, the data contained i ncludes the final representation of the processing a SCIM Create operation, the data contained i ncludes the final representation of the
created entity by the SCIM Service Provider including th e assigned "id" value. entity created by the SCIM Service Provider including th e assigned "id" value.
</dd> </dd>
<dt>attributes</dt> <!--[rfced] FYI, in Section 2.2 about "attributes", please review:
- removed the extraneous '>' in '"path">'. Seems it was a typo.
- removed the line break after "For example:". If you prefer that
the example be in a sourcecode element, please let us know.
Original:
Names of modified attributes SHOULD conform to the ABNF syntax rule
for "path"> (Section 3.5.2 of [RFC7644]).
For example:
"attributes": ["username","emails","name.familyName"]
Current:
Names of modified attributes SHOULD conform to the ABNF syntax
rule for "path" (see Section 3.5.2 of [RFC7644] and [RFC5234]).
For example: "attributes": ["username","emails","name.familyName"].
-->
<dt>attributes</dt>
<dd> <dd>
This payload contains an array of attributes that were a A payload that contains an array of attributes that were
dded, revised, or removed. Names of added, revised, or removed. Names of
modified attributes <bcp14>SHOULD</bcp14> conform to the modified attributes <bcp14>SHOULD</bcp14> conform to the
ABNF syntax rule for "path"> ABNF syntax rule for "path"
(<xref target="RFC7644" section="3.5.2"/>). For example: (<xref target="RFC7644" section="3.5.2"/>). For example:
<br/> <tt>"attributes": ["username","emails","name.familyName"
<tt>"attributes": ["username","emails","name.familyName" ]</tt>.
]</tt>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="scimFeedEvents" numbered="true" toc="default"> <section anchor="scimFeedEvents" numbered="true" toc="default">
<name>SCIM Feed Events</name> <name>SCIM Feed Events</name>
<t> <t>
This section defines events related to changes in the conten t of an event feed. Such as, This section defines events related to changes in the conten t of an event feed such as
SCIM Resources that are being added or removed from an event feed or events used in SCIM Resources that are being added or removed from an event feed or events used in
Co-operative Provisioning scenarios where only a sub-set of Co-operative Provisioning scenarios where only a subset of e
entities are shared across an ntities are shared across an
Event Feed. The URI prefix for these events is Event Feed. The URI prefix for these events is "urn:ietf:par
"urn:ietf:params:scim:event:feed" ams:scim:event:feed".
</t> </t>
<section anchor="feedAdd" numbered="true" toc="default"> <section anchor="feedAdd" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:feed:add</name> <name>urn:ietf:params:scim:event:feed:add</name>
<t>The specified resource has been added to the Event Feed. A "feed:add" does not indicate a <t>The specified resource has been added to the Event Feed. A "feed:add" does not indicate that a
resource is new or has been recently created. For exampl e, resource is new or has been recently created. For exampl e,
an existing user has had a new role (e.g., CRM_User) add ed to an existing user has had a new role (e.g., CRM_User) add ed to
their profile which has caused their resource to join a feed. their profile, which has caused their resource to join a feed.
</t> </t>
<figure anchor="exampleFeedAddEvent"> <figure anchor="exampleFeedAddEvent">
<name>Example SCIM Feed Add Event</name> <name>Example SCIM Feed Add Event</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"txn": "b7b953f11cc6489bbfb87834747cc4c1", "txn": "b7b953f11cc6489bbfb87834747cc4c1",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe" "externalId": "jdoe"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:feed:add": {} "urn:ietf:params:scim:event:feed:add": {}
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="feedRemove" numbered="true" toc="default"> <section anchor="feedRemove" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:feed:remove</name> <name>urn:ietf:params:scim:event:feed:remove</name>
<t>The specified <t>The specified
resource has been removed from the feed. Removal does no t indicate resource has been removed from the feed. Removal does no t indicate
that the resource was deleted or otherwise deactivated. that the resource was deleted or otherwise deactivated.
</t> </t>
<figure anchor="exampleRemoveEvent"> <figure anchor="exampleRemoveEvent">
<name>Example SCIM Feed Remove Event</name> <name>Example SCIM Feed Remove Event</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe", "externalId": "jdoe",
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:feed:remove": {} "urn:ietf:params:scim:event:feed:remove": {}
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="scimProvEvents" numbered="true" toc="default"> <section anchor="scimProvEvents" numbered="true" toc="default">
<name>SCIM Provisioning Events</name> <name>SCIM Provisioning Events</name>
<t> <t>
This section defines resource changes that have occurred wit hin a SCIM Service Provider. These This section defines resource changes that have occurred wit hin a SCIM Service Provider. These
events are used in both Domain Based Replication (DBR) and C o-operative Provisioning (CP) mode. The events are used in both Domain-Based Replication (DBR) and C o-operative Provisioning (CP) mode. The
URI prefix for these events is "urn:ietf:params:scim:event:p rov". URI prefix for these events is "urn:ietf:params:scim:event:p rov".
</t> </t>
<t> <t>
For each of the following events when the "data" payload att When the "data" payload attribute is included for each of th
ribute is included, the e following events, the
event URI <bcp14>MUST</bcp14> end with "full", otherwise the event URI <bcp14>MUST</bcp14> end with "full"; otherwise, th
event URI ends with "notice". In e event URI ends with "notice". In
"full" mode, the set of values reflecting the final represen tation of the resource (such as would "full" mode, the set of values reflecting the final represen tation of the resource (such as would
be returned in a SCIM protocol response) at the Service Prov ider be returned in a SCIM protocol response) at the Service Prov ider
are provided using the "data" attribute (see <xref target="e are provided using the "data" attribute (see <xref target="e
xampleCreateEvent"/>). In "notice" mode, the xampleCreateEvent"/>). In "notice"
"attributes" attribute is returned listing the set of attrib mode, the
utes created or modified in the "attributes" attribute is returned and lists the set of attr
request (see <xref target="exampleCreateEventDef"/>). Exactl ibutes created or modified in the
y one of the payload attributes "data" request (see <xref target="exampleCreateEventDef"/>). Exactl
y one of the payload attributes, "data"
or "attributes", <bcp14>MUST</bcp14> be present. Both <bcp14 >MUST NOT</bcp14> be present simultaneously. or "attributes", <bcp14>MUST</bcp14> be present. Both <bcp14 >MUST NOT</bcp14> be present simultaneously.
</t> </t>
<section anchor="provCreate" numbered="true" toc="default"> <section anchor="provCreate" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:create:{notice|full}</ name> <name>urn:ietf:params:scim:event:prov:create:{notice|full}</ name>
<t> <t>
Indicates a new SCIM resource has been created by the SC IM Service Provider The specified resource indicates that a new SCIM resourc e has been created by the SCIM Service Provider
and has been added to the Event Feed. and has been added to the Event Feed.
Note that because the event may be used for replication, the "id" Note that because the event may be used for replication, the "id"
attribute that was assigned by the SCIM Service Provider is shared so that all replicas in the attribute that was assigned by the SCIM Service Provider is shared so that all replicas in the
domain <bcp14>MAY</bcp14> use the same resource identifi er. domain <bcp14>MAY</bcp14> use the same resource identifi er.
</t> </t>
<figure anchor="exampleCreateEvent"> <figure anchor="exampleCreateEvent">
<name>Example SCIM Create Event (Full)</name> <name>Example SCIM Create Event (Full)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "4d3559ec67504aaba65d40b0363faad8", "jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404, "iat": 1458496404,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
skipping to change at line 474 skipping to change at line 632
{"type":"work","value":"jdoe@example.com"} {"type":"work","value":"jdoe@example.com"}
], ],
"userName":"jdoe", "userName":"jdoe",
"name":{ "name":{
"givenName":"John", "givenName":"John",
"familyName":"Doe" "familyName":"Doe"
} }
} }
} }
} }
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="exampleCreateEventDef"> <figure anchor="exampleCreateEventDef">
<name>Example SCIM Create Event (Notice)</name> <name>Example SCIM Create Event (Notice)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "4d3559ec67504aaba65d40b0363faad8", "jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404, "iat": 1458496404,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
skipping to change at line 504 skipping to change at line 662
"urn:ietf:params:scim:event:prov:create:notice": { "urn:ietf:params:scim:event:prov:create:notice": {
"attributes": [ "attributes": [
"id", "id",
"name", "name",
"userName", "userName",
"password", "password",
"emails" "emails"
] ]
} }
} }
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t> <t>
The event shown in <xref target="exampleCreateEventDef"/ The event shown in <xref target="exampleCreateEventDef"/
> notifies the Event Receiver which > notifies the Event Receiver of which
attributes have changed but does not convey attributes have changed, but it does not convey
the actual information. The Event Receiver <bcp14>MAY</b cp14> retrieve that information the actual information. The Event Receiver <bcp14>MAY</b cp14> retrieve that information
by performing a SCIM GET based on the "sub_id" value pro vided. by performing a SCIM GET based on the "sub_id" value pro vided.
</t> </t>
</section> </section>
<section anchor="provPatch" numbered="true" toc="default"> <section anchor="provPatch" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:patch:{notice|full}</n ame> <name>urn:ietf:params:scim:event:prov:patch:{notice|full}</n ame>
<t> <t>
The specified resource has been updated using SCIM PATCH . In "full" mode, the The specified resource has been updated using SCIM PATCH . In "full" mode, the
"data" payload attribute is included (see <xref target=" examplePatchEventFull"/>). "data" payload attribute is included (see <xref target=" examplePatchEventFull"/>).
When the event URI ends with "notice", the list of modif ied attributes is provided When the event URI ends with "notice", the list of modif ied attributes is provided
(see <xref target="examplePatchEventBrief"/>). (see <xref target="examplePatchEventBrief"/>).
</t> </t>
<figure anchor="examplePatchEventFull"> <figure anchor="examplePatchEventFull">
<name>Example SCIM Patch Event (Full)</name> <name>Example SCIM Patch Event (Full)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2", "uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers" "externalId": "crmUsers"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:patch:full": { "urn:ietf:params:scim:event:prov:patch:full": {
"version": "a330bc54f0671c9", "version": "a330bc54f0671c9",
skipping to change at line 555 skipping to change at line 713
}] }]
}] }]
} }
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="examplePatchEventBrief"> <figure anchor="examplePatchEventBrief">
<name>Example SCIM Patch Event (Notice)</name> <name>Example SCIM Patch Event (Notice)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2", "uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers" "externalId": "crmUsers"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:patch:notice": { "urn:ietf:params:scim:event:prov:patch:notice": {
"attributes": ["members"], "attributes": ["members"],
"version": "a330bc54f0671c9" "version": "a330bc54f0671c9"
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="provPut" numbered="true" toc="default"> <section anchor="provPut" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:put:{notice|full}</nam e> <name>urn:ietf:params:scim:event:prov:put:{notice|full}</nam e>
<t> <t>
The specified resource has been updated (e.g., one or mo re attributes has The specified resource has been updated (e.g., one or mo re attributes has
changed). In "full" mode, the SCIM PUT request body is i ncluded in the "data" changed). In "full" mode, the SCIM PUT request body is i ncluded in the "data"
attribute (see <xref target="examplePutEventFull"/>). In "notice" mode, the modified attribute (see <xref target="examplePutEventFull"/>). In "notice" mode, the modified
attributes are listed using "attributes" (see <xref targ et="examplePutEventBrief"/>). attributes are listed using "attributes" (see <xref targ et="examplePutEventBrief"/>).
</t> </t>
<figure anchor="examplePutEventFull"> <figure anchor="examplePutEventFull">
<name>Example SCIM Put Event (Full)</name> <name>Example SCIM Put Event (Full)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json" ><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646" "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:put:full": { "urn:ietf:params:scim:event:prov:put:full": {
"version": "a330bc54f0671c9", "version": "a330bc54f0671c9",
"data": { "data": {
skipping to change at line 624 skipping to change at line 782
{"value":"anon@jdoe.org"} {"value":"anon@jdoe.org"}
] ]
} }
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="examplePutEventBrief"> <figure anchor="examplePutEventBrief">
<name>Example SCIM Put Event (Notice)</name> <name>Example SCIM Put Event (Notice)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646" "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:put:notice": { "urn:ietf:params:scim:event:prov:put:notice": {
"version": "a330bc54f0671c9", "version": "a330bc54f0671c9",
"attributes": ["userName","externalId","name","roles","emails"] "attributes": ["userName","externalId","name","roles","emails"]
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="provDelete" numbered="true" toc="default"> <section anchor="provDelete" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:delete</name> <name>urn:ietf:params:scim:event:prov:delete</name>
<t> <t>
The specified resource has been deleted from the SCIM Se rvice Provider. The specified resource has been deleted from the SCIM Se rvice Provider.
The resource is also removed from the feed. When a The resource is also removed from the feed. When a
DELETE is sent, a corresponding "feedRemove" <bcp14>SHAL L NOT</bcp14> be issued. A delete DELETE is sent, a corresponding "feedRemove" <bcp14>SHAL L NOT</bcp14> be issued. A delete
event has no payload attributes. Note that because the d elete event has event has no payload attributes. Note that because the d elete event has
no attributes, the qualifiers "full" and "notice" <bcp14 >SHALL NOT</bcp14> be used. no attributes, the qualifiers "full" and "notice" <bcp14 >SHALL NOT</bcp14> be used.
</t> </t>
<figure anchor="exampleDeleteEvent"> <figure anchor="exampleDeleteEvent">
<name>Example SCIM Delete Event</name> <name>Example SCIM Delete Event</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462", "uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jDoe" "externalId": "jDoe"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:delete": {} "urn:ietf:params:scim:event:prov:delete": {}
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="provActivate" numbered="true" toc="default"> <section anchor="provActivate" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:activate</name> <name>urn:ietf:params:scim:event:prov:activate</name>
<t> <t>
The specified resource (e.g., User) has been "activated" . This does not necessarily reflect The specified resource (e.g., User) has been "activated" . This does not necessarily reflect
any particular state change at the SCIM Service Provider but may simply indicate the any particular state change at the SCIM 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 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 r epresent an account that may be logged in. Event Receiver. For example, an activated resource can r epresent an account that may be logged in.
</t> </t>
<figure anchor="exampleActivateEvent"> <figure anchor="exampleActivateEvent">
<name>Example SCIM Activate Event</name> <name>Example SCIM Activate Event</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462" "uri": "/Users/2b2f880af6674ac284bae9381673d462"
}, },
"events":{ "events":{
"urn:ietf:params:scim:event:prov:activate": {} "urn:ietf:params:scim:event:prov:activate": {}
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="provDeactivate" numbered="true" toc="default"> <section anchor="provDeactivate" numbered="true" toc="default">
<name>urn:ietf:params:scim:event:prov:deactivate</name> <name>urn:ietf:params:scim:event:prov:deactivate</name>
<t> <t>
The specified resource (e.g., User) has been deactivated and The specified resource (e.g., User) has been deactivated and
disabled. The exact meaning <bcp14>SHOULD</bcp14> be agr eed to by the Event Publisher disabled. The exact meaning <bcp14>SHOULD</bcp14> be agr eed to by the Event Publisher
and its corresponding Event Receiver. Typically, this me ans the subject and its corresponding Event Receiver. Typically, this me ans the subject
may no longer have an active security session. may no longer have an active security session.
</t> </t>
skipping to change at line 734 skipping to change at line 892
that has occurred within a SCIM Service Provider. The URI pr efix for these events is that has occurred within a SCIM Service Provider. The URI pr efix for these events is
"urn:ietf:params:scim:event:misc". "urn:ietf:params:scim:event:misc".
</t> </t>
<section anchor="asyncEvent" numbered="true" toc="default"> <section anchor="asyncEvent" numbered="true" toc="default">
<name>Asynchronous Events</name> <name>Asynchronous Events</name>
<section anchor="asyncRequest" numbered="true" toc="default" > <section anchor="asyncRequest" numbered="true" toc="default" >
<name>Making an Asynchronous SCIM Request</name> <name>Making an Asynchronous SCIM Request</name>
<t> <t>
A SCIM Client making SCIM HTTP requests defined in < xref target="RFC7644" section="3"/> <bcp14>MAY</bcp14> request A SCIM Client making SCIM HTTP requests defined in < xref target="RFC7644" section="3"/> <bcp14>MAY</bcp14> request
asynchronous processing using the "Prefer" HTTP Head er as defined in asynchronous processing using the "Prefer" HTTP head er as defined in
<xref target="RFC7240" section="4.1"/>. The client m ay do this for a number of reasons such as avoiding <xref target="RFC7240" section="4.1"/>. The client m ay do this for a number of reasons such as avoiding
holding HTTP connections open during long requests, holding HTTP connections open during long requests b
because the result of the request is not ecause the result of the request is not
needed, or for co-ordination reasons where the resul needed or the result is delivered to another entity
t is delivered to another entity for for further action for co-ordination reasons.
further action.
</t> </t>
<t> <t>
To initiate an asynchronous SCIM request, a normal S CIM protocol POST, PUT, To initiate an asynchronous SCIM request, a normal S CIM protocol POST, PUT,
PATCH, or DELETE request is performed with the HTTP "Prefer" Header set to PATCH, or DELETE request is performed with the HTTP "Prefer" header set to
"respond-async" (<xref target="RFC7240" section="4.1 "/>). The HTTP "Accept" "respond-async" (<xref target="RFC7240" section="4.1 "/>). The HTTP "Accept"
header <bcp14>MUST</bcp14> be ignored for purposes o f an asynchronous response. Additionally, per header <bcp14>MUST</bcp14> be ignored for purposes o f an asynchronous response. Additionally, per
<xref target="RFC7240" section="4.3"/>, the "wait" <xref target="RFC7240" section="4.3"/>, the "wait"
preference <bcp14>SHOULD</bcp14> be supported to est ablish a maximum time preference <bcp14>SHOULD</bcp14> be supported to est ablish a maximum time
before a SCIM Service Provider <bcp14>MAY</bcp14> ch oose to respond asynchronously. before a SCIM Service Provider <bcp14>MAY</bcp14> ch oose to respond asynchronously.
</t> </t>
<t> <t>
In response, the SCIM Service Provider either return s a normal SCIM response or returns In response, the SCIM Service Provider returns eithe r a normal SCIM response or
HTTP Status 202 (Accepted). HTTP Status 202 (Accepted).
The asynchronous response <bcp14>MUST</bcp14> contai n no response body. To enable correlation of the The asynchronous response <bcp14>MUST</bcp14> contai n no response body. To enable correlation of the
future event, the HTTP response header "Set-Txn" (se e <xref target="settxnheader"/>) is future event, the HTTP response header "Set-Txn" (se e <xref target="settxnheader"/>) is
returned with a value that <bcp14>MUST</bcp14> match the "txn" claim in a subsequent Security Event returned with a value that <bcp14>MUST</bcp14> match the "txn" claim in a subsequent Security Event
Token. Per <xref target="RFC7240" section="3" sectio nFormat="comma"/>, the response will also include the Token. Per <xref target="RFC7240" section="3" sectio nFormat="comma"/>, the response will also include the
"Preference-Applied" header. The "Location" header v alue <bcp14>MUST</bcp14> be one of the "Preference-Applied" header. The "Location" header v alue <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, following: (a) a URI where the completion SCIM Event Token <bcp14>MAY</bcp14> be retrieved using HTTP GET
or (b) the normal SCIM location header response spec ified by <xref target="RFC7644"/>. or (b) the normal SCIM location header response spec ified by <xref target="RFC7644"/>.
</t> </t>
<t keepWithNext="true"> <t keepWithNext="true">
In the following non-normative example, a "Prefer" h eader is set to "respond-async": In the following non-normative example, a "Prefer" h eader is set to "respond-async":
</t> </t>
<figure anchor="asyncRequestFigure"> <figure anchor="asyncRequestFigure">
<name>Example Asynchronous SCIM Protocol Request</na <name>Example Asynchronous SCIM Protocol Request</name
me> >
<artwork align="left"><![CDATA[
<!--[rfced] Should the middle initial for Barbara Jensen III be "J."
(with a period) in Figure 12, or is the current text correct?
Current:
"formatted":"Ms. Barbara J Jensen III"
Perhaps:
"formatted":"Ms. Barbara J. Jensen III"
-->
<sourcecode type="json"><![CDATA[
PUT /Users/2819c223-7f76-453a-919d-413861904646 PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: scim.example.com Host: scim.example.com
Prefer: respond-async Prefer: respond-async
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
{ {
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"], "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646", "id":"2819c223-7f76-453a-919d-413861904646",
"userName":"bjensen", "userName":"bjensen",
"externalId":"bjensen", "externalId":"bjensen",
"name":{ "name":{
"formatted":"Ms. Barbara J Jensen III" "formatted":"Ms. Barbara J Jensen III"
}, },
"roles":[], "roles":[],
"emails":[ "emails":[
{ {
"value":"bjensen@example.com" "value":"bjensen@example.com"
} }
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t> <t>
The SCIM Service Provider responds with HTTP 202 Acc epted and includes the Set-Txn header: The SCIM Service Provider responds with HTTP 202 Acc epted and includes the Set-Txn header:
</t> </t>
<!--[rfced] We note that Figure 13 is the only figure without a
title. Would you like to add one? If so, please provide the
desired text.
-->
<figure> <figure>
<artwork><![CDATA[ <artwork><![CDATA[
HTTP/1.1 202 Accepted HTTP/1.1 202 Accepted
Set-Txn: 734f0614e3274f288f93ac74119dcf78 Set-Txn: 734f0614e3274f288f93ac74119dcf78
Preference-Applied: respond-async Preference-Applied: respond-async
Location: Location:
"/Users/2819c223-7f76-453a-919d-413861904646" "/Users/2819c223-7f76-453a-919d-413861904646"
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="asyncBulkRequest" numbered="true" toc="defa ult"> <section anchor="asyncBulkRequest" numbered="true" toc="defa ult">
<name>Asynchronous Bulk Endpoint Requests</name> <name>Asynchronous Bulk Endpoint Requests</name>
<t> <t>
<xref section="3.7" target="RFC7644"/> provides the ability to submit multiple <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 SCIM operations in a single "bulk" request. When an asynchronous response is requested, a single
Asynchronous Request Completion Event <bcp14>MUST</b cp14> be generated for each requested operation. For example, Asynchronous Request Completion Event <bcp14>MUST</b cp14> be generated for each requested operation. For example,
if a single "bulk" request had 10 operations, then 1 0 Asynchronous Event completions events if a single "bulk" request had 10 operations, then 1 0 Asynchronous Event completion events
would be generated. would be generated.
</t> </t>
<t> <t>
The "txn" claim <bcp14>MUST</bcp14> be set to the va lue originally returned to the requesting SCIM Client (see The "txn" claim <bcp14>MUST</bcp14> be set to the va lue originally returned to the requesting SCIM Client (see
<xref target="asyncRequest"/>) appended with a colon ":" and the zero-based array index of <xref target="asyncRequest"/>) appended with a colon ":" and the zero-based array index of
the operation expressed in the "Operations" attribut e of the the operation expressed in the "Operations" attribut e of the
original bulk request. The "bulkId" parameter <bcp14 >MUST NOT</bcp14> be used for this purpose as 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. it is a temporary identifier and is not required for every operation.
</t> </t>
<t> <t>
For example, if a SCIM Service Provider received a B ulk request with two or more operations, For example, if a SCIM Service Provider received a b ulk request with two or more operations,
and had a "txn" claim value of "2d80e537a3f64622b034 7b641ebc8f44", and had a "txn" claim value of "2d80e537a3f64622b034 7b641ebc8f44",
then the first Asynchronous Response Event Token rep resenting the first operation has then the first Asynchronous Response Event Token rep resenting the first operation has
a "txn" claim value of "2d80e537a3f64622b0347b641ebc 8f44:0", the second operation has a value of a "txn" claim value of "2d80e537a3f64622b0347b641ebc 8f44:0", the second operation has a value of
"2d80e537a3f64622b0347b641ebc8f44:1", and so on. "2d80e537a3f64622b0347b641ebc8f44:1", and so on.
</t> </t>
<t> <t>
If a SCIM Service Provider optimizes the sequence of operations (per <xref target="RFC7644" section="3.7"/>), the If a SCIM Service Provider optimizes the sequence of operations (per <xref target="RFC7644" section="3.7"/>), the
Asynchronous Request Completion events generated <bc p14>MAY</bcp14> be generated out of sequence from the Asynchronous Request Completion events <bcp14>MAY</b cp14> be generated out of sequence from the
original request. In this original request. In this
case, the "txn" claims in those events <bcp14>MUST</ bcp14> use operation numbers that correspond to the case, the "txn" claims in those events <bcp14>MUST</ bcp14> use operation numbers that correspond to the
order in the original request. order in the original request.
</t> </t>
</section> </section>
<section> <section>
<name>urn:ietf:params:scim:event:misc:asyncresp</name> <name>urn:ietf:params:scim:event:misc:asyncresp</name>
<t> <t>
The Asynchronous Response event signals the completion o f a SCIM request. The event payload contains The Asynchronous Response event signals the completion o f a SCIM request. The event payload contains
the attributes defined in <xref target="RFC7644" section ="3.7"/> and is the same as a 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"/>. In the event, the "txn " claim <bcp14>MUST</bcp14> be single SCIM Bulk Response Operation as per <xref target= "RFC7644" section="3.7.3"/>. In the event, the "txn" claim <bcp14>MUST</bcp14> b e
set to the value originally returned to the requesting S CIM Client (see <xref target="asyncRequest"/>). set to the value originally returned to the requesting S CIM Client (see <xref target="asyncRequest"/>).
</t> </t>
<figure anchor="exampleAsyncEvent"> <figure anchor="exampleAsyncEvent">
<name>Example SCIM Asynchronous Response Event</name> <name>Example SCIM Asynchronous Response Event</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646" "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
}, },
"txn": "734f0614e3274f288f93ac74119dcf78", "txn": "734f0614e3274f288f93ac74119dcf78",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT", "method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"", "version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200" "status": "200"
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t> <t>
If an error occurs during asynchronous processing, If an error occurs during asynchronous processing,
the event operation <bcp14>MUST</bcp14> include a "respo nse" attribute indicating a non-200-series HTTP status the event operation <bcp14>MUST</bcp14> include a "respo nse" attribute indicating a non-200-series HTTP status
as defined in <xref section="3.7" target="RFC7644"/>, an d that "response" attribute <bcp14>MUST</bcp14> contain the as defined in <xref section="3.7" target="RFC7644"/>, an d that "response" attribute <bcp14>MUST</bcp14> contain the
sub-attributes defined in <xref section="3.12" target="R FC7644"/>. The "status" attribute sub-attributes defined in <xref section="3.12" target="R FC7644"/>. The "status" attribute
of the event operation typically matches the "status" at tribute of the response. of the event operation typically matches the "status" at tribute of the response.
</t> </t>
<figure anchor="exampleAsyncErrorEvent"> <figure anchor="exampleAsyncErrorEvent">
<name>Example SCIM Asynchronous Error Response Event</na me> <name>Example SCIM Asynchronous Error Response Event</na me>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8", "jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646" "uri": "/Users/2819c223-7f76-453a-919d-413861904646"
}, },
"txn": "734f0614e3274f288f93ac74119dcf78", "txn": "734f0614e3274f288f93ac74119dcf78",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT", "method": "PUT",
skipping to change at line 904 skipping to change at line 1078
"detail": "Request is unparsable", "detail": "Request is unparsable",
"status":"400" "status":"400"
} }
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<t>The following 4 figures show Asynchronous Completion even ts for the example in <t>The following four figures show Asynchronous Completion e vents for the example in
<xref target="RFC7644" section="3.7.3"/>.</t> <xref target="RFC7644" section="3.7.3"/>.</t>
<figure anchor="exampleAsyncBulk1"> <figure anchor="exampleAsyncBulk1">
<name>Example SCIM Asynchronous Response Event Opera <name>Example SCIM Asynchronous Response Event Opera
tion 1/4</name> tion (1 of 4)</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "dbae9d7506b34329aa7f2f0d3827848b", "jti": "dbae9d7506b34329aa7f2f0d3827848b",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a" "uri": "/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:1", "txn": "2d80e537a3f64622b0347b641ebc8f44:1",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "POST", "method": "POST",
"bulkId": "qwerty", "bulkId": "qwerty",
"version": "W\/\"oY4m4wn58tkVjJxK\"", "version": "W\/\"oY4m4wn58tkVjJxK\"",
"status": "201" "status": "201"
} }
}, },
"iat": 1458505044, "iat": 1458505044,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="exampleAsyncBulk2"> <figure anchor="exampleAsyncBulk2">
<name>Example SCIM Asynchronous Response Event Opera <name>Example SCIM Asynchronous Response Event Opera
tion 2/4</name> tion (2 of 4)</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "ca977d05ba5c43929e3a69023d5392a9", "jti": "ca977d05ba5c43929e3a69023d5392a9",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/b7c14771-226c-4d05-8860-134711653041" "uri": "/Users/b7c14771-226c-4d05-8860-134711653041"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:2", "txn": "2d80e537a3f64622b0347b641ebc8f44:2",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PUT", "method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"", "version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200" "status": "200"
} }
}, },
"iat": 1458505045, "iat": 1458505045,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="exampleAsyncBulk3"> <figure anchor="exampleAsyncBulk3">
<name>Example SCIM Asynchronous Response Event Opera <name>Example SCIM Asynchronous Response Event Opera
tion 3/4</name> tion (3 of 4)</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "4bb87d70a4ab463bbdcd1f99111cbbf1", "jti": "4bb87d70a4ab463bbdcd1f99111cbbf1",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc" "uri": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:3", "txn": "2d80e537a3f64622b0347b641ebc8f44:3",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "PATCH", "method": "PATCH",
"version": "W\/\"huJj29dMNgu3WXPD\"", "version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200" "status": "200"
} }
}, },
"iat": 1458505046, "iat": 1458505046,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
<figure anchor="exampleAsyncBulk4"> <figure anchor="exampleAsyncBulk4">
<name>Example SCIM Asynchronous Response Event Opera <name>Example SCIM Asynchronous Response Event Opera
tion 4/4</name> tion (4 of 4)</name>
<artwork type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"jti": "6a7843a7f5244d0eb62ca38b641d9139", "jti": "6a7843a7f5244d0eb62ca38b641d9139",
"sub_id": { "sub_id": {
"format": "scim", "format": "scim",
"uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b" "uri": "/Users/e9025315-6bea-44e1-899c-1e07454e468b"
}, },
"txn": "2d80e537a3f64622b0347b641ebc8f44:4", "txn": "2d80e537a3f64622b0347b641ebc8f44:4",
"events":{ "events":{
"urn:ietf:params:scim:event:misc:asyncresp": { "urn:ietf:params:scim:event:misc:asyncresp": {
"method": "DELETE", "method": "DELETE",
"status": "204" "status": "204"
} }
}, },
"iat": 1458505047, "iat": 1458505047,
"iss":"https://scim.example.com", "iss":"https://scim.example.com",
"aud":[ "aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754" "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
] ]
}]]></artwork> }]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="settxnheader" numbered="true" toc="default"> <section anchor="settxnheader" numbered="true" toc="default">
<name>Set-Txn HTTP Response Header for Asynchronous Requests</name> <name>Set-Txn HTTP Response Header for Asynchronous Requests</name>
<t> <t>
This specification defines a new HTTP Header field "Set-Txn" whi ch serves the purpose of conveying This specification defines a new HTTP header field, "Set-Txn", w hich serves the purpose of conveying
request completion information to SCIM HTTP clients that request an asynchronous response as described 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 when HTTP in <xref target="asyncRequest"/>. The header field <bcp14>MUST< /bcp14> be used in SCIM Responses when HTTP
Status 202 Accepted is being returned with no message body. Status 202 Accepted is being returned with no message body.
</t> </t>
<t> <t>
The "Set-Txn" HTTP Header field value is a unique STRING (e.g., a GUID) used by the SCIM HTTP The "Set-Txn" HTTP header field value is a unique STRING (e.g., a Globally Unique Identifier (GUID)) used by the SCIM HTTP
client to look for a matching SET event with a matching "txn" cl aim (see client to look for a matching SET event with a matching "txn" cl aim (see
<xref target="RFC8417" section="2"/>) confirming the request <xref target="RFC8417" section="2"/>) confirming the request
completion status as described in <xref target="asyncRequest"/>. completion status as described in <xref target="asyncRequest"/>.
</t> </t>
<t> <t>
Intermediaries <bcp14>SHOULD NOT</bcp14> insert, modify, or dele te the field's value. Intermediaries <bcp14>SHOULD NOT</bcp14> insert, modify, or dele te the field's value.
</t> </t>
<t> <t>
SCIM clients <bcp14>MAY</bcp14> ignore the header in cases where confirmation of completion is not required. For SCIM clients <bcp14>MAY</bcp14> ignore the header in cases where confirmation of completion is not required. For
example a SCIM client may simply not want to wait for synchronou s completion. example, a SCIM client may simply not want to wait for synchrono us completion.
</t> </t>
</section> </section>
<section anchor="serviceProviderConfig" numbered="true" toc="default"> <section anchor="serviceProviderConfig" numbered="true" toc="default">
<name>Events Discovery Schema for Service Provider Configuration</na me> <name>Events Discovery Schema for Service Provider Configuration</na me>
<t><xref section="5" target="RFC7643"/> defines SCIM Service Provide r configuration schemas. This section <t><xref section="5" target="RFC7643"/> defines SCIM Service Provide r configuration schemas. This section
defines additional attributes that enable a SCIM Client to discover the additional capabilities defined defines additional attributes that enable a SCIM Client to discover the additional capabilities defined
by this specification.</t> by this specification.</t>
<dl newline="true"> <dl newline="true">
<dt>securityEvents</dt> <dt>securityEvents</dt>
<dd> <dd>
<t> <t>
A SCIM Complex attribute that specifies the available ca pabilities A SCIM Complex attribute that specifies the available ca pabilities
related to asynchronous Security Events based on <xref t related to asynchronous Security Events based on <xref t
arget="RFC8417"/>. This attribute is <bcp14>OPTIONAL</bcp14> and arget="RFC8417"/>. This attribute is <bcp14>OPTIONAL</bcp14>, and
when absent indicates the SCIM Service Provider does not when absent, it indicates the SCIM Service Provider does
support or is not currently configured for Security Events. not support or is not currently configured for Security Events.
The following sub-attributes are defined: </t> The following sub-attributes are defined: </t>
<dl newline="true"> <dl newline="true">
<dt>asyncRequest</dt> <dt>asyncRequest</dt>
<dd> <dd>
<t> <t>
A case-insensitive string value specifying one o f the following:</t> A case-insensitive string value specifying one o f the following:</t>
<ul> <ul>
<li>"none" indicates asynchronous SCIM reque <li>"none" indicates that asynchronous SCIM
sts defined in <xref target="asyncRequest"/> are not supported; </li> requests defined in <xref target="asyncRequest"/> are not supported; </li>
<li>"long" indicates the server completes re <li>"long" indicates that the server complet
quests asynchronously at server discretion (e.g. es requests asynchronously at the server's discretion (e.g.,
based on a max wait time);</li> based on a max wait time); and</li>
<li>"request" indicates the server completes <li>"request" indicates that the server comp
requests asynchronously when requested by letes requests asynchronously when requested by
the SCIM Client.</li> the SCIM Client.</li>
</ul> </ul>
</dd> </dd>
<dt>eventUris</dt> <dt>eventUris</dt>
<dd> <dd>
<t> <t>
A multivalued string listing the SET Event URIs (defined in <xref target="RFC8417"/>) that A multivalued string listing the SET Event URIs (defined in <xref target="RFC8417"/>) that
the server is capable of generating and delivera ble via a SET Stream (see <xref target="RFC8935"/> and <xref target="RFC8936"/>) . the server is capable of generating and deliveri ng via a SET Stream (see <xref target="RFC8935"/> and <xref target="RFC8936"/>).
This information is informational only. Stream r egistration and configuration are out of scope of this specification. This information is informational only. Stream r egistration and configuration are out of scope of this specification.
</t> </t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="Security" toc="default" numbered="true"> <section anchor="Security" toc="default" numbered="true">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
As this specification is based upon the Security Event Tokens sp As this specification is based upon the SETs specification and t
ecification and the associated delivery specifications the following he associated delivery specifications, the
Security Considerations are also applicable to this specificatio following security considerations are also applicable to this sp
n: ecification:
</t> </t>
<ul> <ul>
<li><xref section="5" target="RFC8417"/> (Security Event Token)< /li> <li><xref section="5" target="RFC8417"/> (Security Event Token)< /li>
<li><xref section="5" target="RFC8935"/> (Push-based Delivery Us <li><xref section="5" target="RFC8935"/> (Push-Based SET Deliver
ing HTTP)</li> y Using HTTP)</li>
<li><xref section="4" target="RFC8936"/> (Poll-Based Delivery Us <li><xref section="4" target="RFC8936"/> (Poll-Based SET Deliver
ing HTTP) </li> y Using HTTP) </li>
</ul> </ul>
<t> <t>
SETs may contain sensitive information, including Personally Ide ntifiable Information (PII). In such SETs may contain sensitive information, including Personally Ide ntifiable Information (PII). In such
cases, SET Transmitters and SET Recipients <bcp14>MUST</bcp14> p rotect the confidentiality of the SET contents in transit cases, SET Transmitters and SET Recipients <bcp14>MUST</bcp14> p rotect the confidentiality of the SET contents in transit
using TLS <xref target="BCP195"/>. using TLS <xref target="BCP195"/>.
</t> </t>
<t> <t>
When co-ordinating provisioning between entities, the long-term series of changes may be critical to the When co-ordinating provisioning between entities, the long-term series of changes may be critical to the
information integrity and recovery requirements of both sides. T o address this, Event Publishers can information integrity and recovery requirements of both sides. T o address this, Event Publishers can
make events available for receivers for longer periods of time t han might typically be used for recovering make events available for receivers for longer periods of time t han might typically be used for recovering
from momentary delivery failures and retries per <xref target="R FC8935"/> or <xref target="RFC8936"/>. from momentary delivery failures and retries per <xref target="R FC8935"/> or <xref target="RFC8936"/>.
Similarly, Event Receivers <bcp14>MUST</bcp14> ensure events are persisted Similarly, Event Receivers <bcp14>MUST</bcp14> ensure events are persisted
directly or indirectly to meet local recovery needs before ackno wledging the SET Events were received. directly or indirectly to meet local recovery needs before ackno wledging the SET Events were received.
</t> </t>
<t> <t>
An attacker might leverage transaction and/or signal information contained in SET Event Publisher or 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 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. parties needed to support recovery or SET forwarding.
</t> </t>
<t> <t>
When SET Events are transferred in such a way as the Event Publi sher is not communicating directly to the When SET Events are transferred in such a way that the Event Pub lisher is not communicating directly to the
Event Receiver, it may become possible for an attacker or other system to insert an event. 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 orig To mitigate, Event Receivers <bcp14>MUST</bcp14> verify the orig
inator of a SET using JWS <xref target="RFC7515"/> inator of a SET using JSON Web
Signature (JWS) <xref target="RFC7515"/>
signatures when the Event Publisher is not communicating directl y with the Event Receiver. signatures when the Event Publisher is not communicating directl y with the Event Receiver.
Validating event signatures may also be useful for auditing purp oses as signed SET Events are protected from tampering in the event that Validating event signatures may also be useful for auditing purp oses as signed SET Events are protected from tampering in the event that
an intermediate system, such as a TLS-terminating proxy, decrypt s the SET payload before sending it onward an intermediate system, such as a TLS-terminating proxy, decrypt s the SET payload before sending it onward
to its intended recipient. to its intended recipient.
</t> </t>
<t> <t>
In operation, some SCIM Resources such as SCIM Groups may have a In operation, some SCIM Resources such as SCIM Groups may have a
high rate of change. For examples groups high rate of change. For example, groups
with more than a few thousand member values could lead to excess with more than a few thousand member values could lead to excess
ive change rates that could lead to a ive change rates, which could lead to a
loss of SET Events between Event Publishers and Event Receivers. To mitigate this risk, consider the loss of SET Events between Event Publishers and Event Receivers. To mitigate this risk, consider the
following to help mitigate throughput issues: following to help with throughput issues:
</t> </t>
<ul> <ul>
<li> <li>
The use of SCIM PUT (<xref section="3.5.1" target="RFC7644"/ >), particularly with large SCIM Groups, The use of SCIM PUT (<xref section="3.5.1" target="RFC7644"/ >), particularly with large SCIM Groups,
can result in excessive data being can result in excessive data being
conveyed in Security Event payloads. Instead, it is <bcp14>R ECOMMENDED</bcp14> to use SCIM PATCH conveyed in Security Event payloads. Instead, it is <bcp14>R ECOMMENDED</bcp14> to use SCIM PATCH
(<xref target="RFC7644" section="3.5.2"/>) to focus on updat ing and notifying about changed information. Alternatively, (<xref target="RFC7644" section="3.5.2"/>) to focus on updat ing and notifying about changed information. Alternatively,
use SCIM PUT Event Notice (urn:ietf:params:scim:event:prov:p ut:notice) as a trigger to later retrieve the use SCIM PUT Event Notice (urn:ietf:params:scim:event:prov:p ut:notice) as a trigger to later retrieve the
full information when needed. full information when needed.
</li> </li>
<li> <li>
Use SCIM Patch Event Notice (urn:ietf:params:scim:event:prov :patch:notice) to reduce event content combined with 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. periodic SCIM GETs (see <xref section="3.4" target="RFC7644" />) to retrieve current group state.
</li> </li>
<li> <li>
<!--[rfced] The following sentence does not parse. Please let us know
how we may update for clarity.
Original:
Providing the exact date of each membership change is not critical
but instead that the information content remains intact.
-->
Aggregate multiple PATCH Events into a single event. Providi ng the exact date of each membership change Aggregate multiple PATCH Events into a single event. Providi ng the exact date of each membership change
is not critical but instead that the information content rem ains intact. is not critical but instead that the information content rem ains intact.
</li> </li>
</ul> </ul>
<t> <t>
When using Asynchronous SCIM Requests (see <xref target="asyncRe quest"/>), a SCIM Service provider returns When using Asynchronous SCIM Requests (see <xref target="asyncRe quest"/>), a SCIM Service Provider returns
a SCIM Accepted response with a URI for retrieving the event res ult. An unauthorized entity or attacker a SCIM Accepted response with a URI for retrieving the event res ult. An unauthorized entity or attacker
could obtain asynchronous request completion event information b y querying the asynchronous operation could obtain asynchronous request completion event information b y querying the asynchronous operation
result endpoint used by a SCIM Service Provider. To mitigate, th e returned URI endpoint <bcp14>MUST</bcp14> be result endpoint used by a SCIM Service Provider. To mitigate, th e returned URI endpoint <bcp14>MUST</bcp14> be
protected requiring an HTTP Authorization header or some other f orm of client authentication. protected and requires an HTTP Authorization header or some othe r form of client authentication.
</t> </t>
</section> </section>
<section anchor="Privacy" toc="default" numbered="true"> <section anchor="Privacy" toc="default" numbered="true">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t> <t>
As this specification is based upon the Security Event Tokens an As this specification is based upon the SET specification and th
d the associated delivery specifications the following e associated delivery specifications, the following
Privacy Considerations are also applicable to this specification privacy considerations are also applicable to this specification
: :
</t> </t>
<ul> <ul>
<li><xref section="6" target="RFC8417"/> (Security Event Token)< /li> <li><xref section="6" target="RFC8417"/> (Security Event Token)< /li>
<li><xref section="6" target="RFC8935"/> (Push-based Delivery Us <li><xref section="6" target="RFC8935"/> (Push-Based SET Deliver
ing HTTP)</li> y Using HTTP)</li>
<li><xref section="5" target="RFC8936"/> (Poll-Based Delivery Us <li><xref section="5" target="RFC8936"/> (Poll-Based SET Deliver
ing HTTP) </li> y Using HTTP) </li>
</ul> </ul>
<t> <t>
This specification enables the sharing of information between do mains. The specification assumes This specification enables the sharing of information between do mains; therefore, it is assumed
that implementers and deployers are operating under one of the f ollowing scenarios: that implementers and deployers are operating under one of the f ollowing scenarios:
</t> </t>
<ul> <ul>
<li>A common administrative domain where there is one administra tive owner of the data. In these cases, <li>A common administrative domain where there is one administra tive owner of the data. In these cases,
the goal is to protect privacy and security of the owner and use r data by keeping information the goal is to protect privacy and security of the owner and use r data by keeping information
systems co-ordinated and up-to-date. For example, the domains de cide to use Domain Based Replication systems co-ordinated and up to date. For example, the domains de cide to use DBR
mode to keep employee information synchronized. mode to keep employee information synchronized.
</li> </li>
<li>In a co-operative or co-ordinated relationship, parties have decided to share a limited amount <li>In a co-operative or co-ordinated relationship, parties have decided to share a limited amount
of data and/or signals for the benefits of their users. Dependin g on end-user consent, information of data and/or signals for the benefits of their users. Dependin g on end-user consent, information
is shared on an as-authorized and/or as-needed basis. For exampl is shared on an as-authorized and/or as-needed basis. For exampl
e, the domains agree to use Co-ordinated e, the domains agree to use CP mode that exchanges things such as account status
Provision mode that exchanges things like account status or spec or specific minimal attribute information
ific minimal attribute information
that must be fetched on request after receiving notice of a chan ge. This enables authorization to that must be fetched on request after receiving notice of a chan ge. This enables authorization to
be verified each time data is transferred. be verified each time data is transferred.
</li> </li>
</ul> </ul>
<t>In general, the sharing of SCIM Event information falls within a pre-existing SCIM Client and Service <t>In general, the sharing of SCIM Event information falls within a pre-existing SCIM Client and Service
Provider relationship and carry no additional personal information.< /t> Provider relationship and carries no additional personal information .</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
a) In Section 7.4, we note that the header of the first column in
Table 1 is named "Event URI", but it is named "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.)
b)
-->
<section anchor="IANAheader" numbered="true" toc="default"> <section anchor="IANAheader" numbered="true" toc="default">
<name>SCIM Asynchronous Txn Header Registration</name> <name>SCIM Asynchronous Set-Txn Header Registration</name>
<t> <t>
This specification registers the HTTP "Set-Txn" field name i n the "HTTP Field Name Registry" defined in <xref target="RFC9110" section="16.3 .1"/>. This specification registers the HTTP "Set-Txn" field name i n the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in <xref target="RFC9110" section="16.3.1"/>.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="compact">
<dt>Field name:</dt><dd>Set-Txn</dd> <dt>Field name:</dt><dd>Set-Txn</dd>
<dt>Status:</dt><dd>Permanent</dd> <dt>Status:</dt><dd>permanent</dd>
<dt>Reference:</dt><dd>See Section <xref target="settxnheade <dt>Reference:</dt><dd>See <xref target="settxnheader"/> of
r"/> of this document.</dd> RFC 9967.</dd>
</dl> </dl>
</section> </section>
<section anchor="spcRegister" numbered="true" toc="default"> <section anchor="spcRegister" numbered="true" toc="default">
<name>Registering Event Capability with Scim Service Provider Co <name>Registering Event Capability with SCIM Service Provider Co
nfig</name> nfiguration</name>
<t> <t>A reference to <xref target="serviceProviderConfig"/> of this
For the SCIM Schema Registry <xref section="10.4" target="RF document has been added to the "urn:ietf:params:scim:schemas:core:2.0:ServicePr
C7643"/>, under Service Provider oviderConfig" entry in the "SCIM Server-Related Schema URIs" registry (<xref sec
Configuration Schema ("urn:ietf:params:scim:schemas:core:2.0 tion="10.4" target="RFC7643"/>) under the "System for Cross-domain Identity Mana
:ServiceProviderConfig"), gement (SCIM) Schema URIs" registry group.
add <xref target="serviceProviderConfig"/> of this document
to the Reference column. <!-- For the SCIM Schema Registry <xref section="10.4"
</t> target="RFC7643"/>, under Service Provider Configuration Schema
</section> ("urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"), add
<xref target="serviceProviderConfig"/> of this document to the
Reference column.
-->
</t>
</section>
<section anchor="IANAevents" numbered="true" toc="default"> <section anchor="IANAevents" numbered="true" toc="default">
<name>Registration of the SCIM Event URIs Registry</name> <name>Creation of the SCIM Event URIs Registry</name>
<t> <t>
IANA will add a new registry called "SCIM Event URIs" to the IANA has created a new registry called "SCIM Event URIs" und
"System for Cross-domain Identity er the "System for Cross-domain Identity
Management (SCIM) Schema URIs" registry group define by <xre Management (SCIM) Schema URIs" registry group (<xref target=
f target="RFC7643" section="10.1"/> "RFC7643" section="10.1"/>)
at https://www.iana.org/assignments/scim. at <eref brackets="angle" target="https://www.iana.org/assig
nments/scim"/>.
</t> </t>
<t> <t>
New registrations for this registry are evaluated by a desig nated expert(s) New registrations for this registry are evaluated by a desig nated expert(s)
for relevance to SCIM-based systems, and, to avoid possible duplication or conflict for relevance to SCIM-based systems and to avoid possible du plication or conflict
with other event definitions that may lie outside SCIM (e.g. , Shared Signals <xref target="SSF"/>). with other event definitions that may lie outside SCIM (e.g. , Shared Signals <xref target="SSF"/>).
</t> </t>
<dl newline="true"> <dl newline="true">
<dt>Namespace ID:</dt> <dt>Namespace ID:</dt>
<dd> <dd>
The sub-namespace ID of "event" is assigned within the " scim" namespace. The sub-namespace ID of "event" is assigned within the " scim" namespace.
</dd> </dd>
<dt>Syntactic Structure:</dt> <dt>Syntactic Structure:</dt>
<dd> <dd>
<t>The Namespace Specific String (NSS) of all URNs that use the "event" Namespace ID has the <t>The Namespace Specific String (NSS) of all URNs that use the "event" Namespace ID has the
following structure:</t> following structure:</t>
<sourcecode><![CDATA["urn:ietf:params:scim:event:{class} <artwork><![CDATA[
:{name}:{other}"]]></sourcecode> "urn:ietf:params:scim:event:{class}:{name}:{other}"]]></artwork>
<t>The keywords have the following meaning:</t> <t>The keywords have the following meaning:</t>
<dl newline="true"> <dl newline="true">
<dt>class</dt> <dt>class</dt>
<dd>The class of events which is one of: "feed", "pr <dd>The class of events, which is one of: "feed", "p
ov" or "misc".</dd> rov", or "misc".</dd>
<!-- [rfced] The RFC Production Center has been advised that "ASCII"
and not "US-ASCII" should be used. May we change instances of
"US-ASCII" in this document to "ASCII" as shown below?
Original:
name A US-ASCII string that conforms to URN syntax requirements (see
[RFC8141]) and defines a descriptive event name (e.g.,
"create").
other An optional US-ASCII string that conforms to URN syntax
requirements (see [RFC8141]) and serves as an additional sub-
category or qualifier.
Perhaps:
name An ASCII string that conforms to URN syntax requirements (see
[RFC8141]) and defines a descriptive event name (e.g.,
"create").
other An optional ASCII string that conforms to URN syntax
requirements (see [RFC8141]) and serves as an additional sub-
category or qualifier.
-->
<dt>name</dt> <dt>name</dt>
<dd>A US-ASCII string that conforms to URN syntax re quirements (see <xref target="RFC8141"/>) <dd>A US-ASCII string that conforms to URN syntax re quirements (see <xref target="RFC8141"/>)
and defines a descriptive event name (e.g., "cre ate").</dd> and defines a descriptive event name (e.g., "cre ate").</dd>
<dt>other</dt> <dt>other</dt>
<dd>An optional US-ASCII string that conforms to URN syntax requirements (see <xref target="RFC8141"/>) <dd>An optional US-ASCII string that conforms to URN syntax requirements (see <xref target="RFC8141"/>)
and serves as an additional sub-category or qual ifier. For example "full" and "notice".</dd> and serves as an additional sub-category or qual ifier, for example, "full" and "notice".</dd>
</dl> </dl>
</dd> </dd>
<dt>Identifier Uniqueness Considerations:</dt> <dt>Identifier Uniqueness Considerations:</dt>
<dd>The designated contact is responsible for reviewing and enforcing uniqueness.</dd> <dd>The designated contact is responsible for reviewing and enforcing uniqueness.</dd>
<dt>Identifier Persistence Considerations:</dt> <dt>Identifier Persistence Considerations:</dt>
<dd>Once a name has been allocated it <bcp14>MUST NOT</bcp14 <dd>Once a name has been allocated, it <bcp14>MUST NOT</bcp1
> be 4> be
re-allocated for a different purpose. The rules provided reallocated for a different purpose. The rules provided
for for the
assignments of values within a sub-namespace <bcp14>MUST assignment of values within a sub-namespace <bcp14>MUST<
</bcp14> be constructed /bcp14> be constructed
so that the meaning of values cannot change. This regist ration so that the meaning of values cannot change. This regist ration
mechanism is not appropriate for naming values whose mea ning may mechanism is not appropriate for naming values whose mea ning may
change over time.</dd> change over time.</dd>
<dt>Registration format:</dt> <dt>Registration Format:</dt>
<dd> <dd>
<t>An event registration <bcp14>MUST</bcp14> include the following fields:</t> <t>An event registration <bcp14>MUST</bcp14> include the following fields:</t>
<ul> <ul>
<li>Event Uri</li> <li>Event Uri</li>
<li>Descriptive Name</li> <li>Descriptive name</li>
<li>Reference to event definition</li> <li>Reference to event definition</li>
</ul> </ul>
<t>Initial values to be added to the SCIM Events Registr y are listed in <xref target="initialEvents"/>.</t> <!-- <t>Initial values to be added to the SCIM Events Registry are listed in <xref target="initialEvents"/>.</t>-->
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="initialEvents" numbered="true" toc="default"> <section anchor="initialEvents" numbered="true" toc="default">
<name>Initial Events Registry</name> <name>Initial Contents of the SCIM Event URIs Registry</name>
<t keepWithNext="true">Summary of Event URI registrations:</t> <t keepWithNext="true">IANA has added the following initial entr ies to the "SCIM Event URIs" registry:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Event URI</th> <th align="left">Event URI</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Ref.</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:feed:add</td > <td align="left">urn:ietf:params:scim:event:feed:add</td >
<td align="left">Resource added to Feed Event</td> <td align="left">Resource added to Feed Event</td>
<td align="left"> <td align="left">
<xref target="feedAdd" format="default"/> of this do cument. <xref target="feedAdd" format="default"/> of RFC 996 7
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:feed:remove< /td> <td align="left">urn:ietf:params:scim:event:feed:remove< /td>
<td align="left">Remove resource From Feed Event</td> <td align="left">Remove resource from Feed Event</td>
<td align="left"> <td align="left">
<xref target="feedRemove" format="default"/> of this document. <xref target="feedRemove" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:create: <td align="left">urn:ietf:params:scim:event:prov:create:
notice</td> notice</td>
<td align="left">New Resource Event (notice only)</td> <td align="left">New Resource Event (notice only)</td>
<td align="left"> <td align="left">
<xref target="provCreate" format="default"/> of this document. <xref target="provCreate" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:create: <td align="left">urn:ietf:params:scim:event:prov:create:
full</td> full</td>
<td align="left">New Resource Event (full data)</td> <td align="left">New Resource Event (full data)</td>
<td align="left"> <td align="left">
<xref target="provCreate" format="default"/> of this document. <xref target="provCreate" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:patch: <td align="left">urn:ietf:params:scim:event:prov:patch:
notice</td> notice</td>
<td align="left">Resource Patch Event (notice only)</td> <td align="left">Resource Patch Event (notice only)</td>
<td align="left"> <td align="left">
<xref target="provPatch" format="default"/> of this document. <xref target="provPatch" format="default"/> of RFC 9 967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:patch: <td align="left">urn:ietf:params:scim:event:prov:patch:
full</td> full</td>
<td align="left">Resource Patch Event (full data)</td> <td align="left">Resource Patch Event (full data)</td>
<td align="left"> <td align="left">
<xref target="provPatch" format="default"/> of this document. <xref target="provPatch" format="default"/> of RFC 9 967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:put: <td align="left">urn:ietf:params:scim:event:prov:put:
notice</td> notice</td>
<td align="left">Resource Put Event (notice only)</td> <td align="left">Resource Put Event (notice only)</td>
<td align="left"> <td align="left">
<xref target="provPut" format="default"/> of this do cument. <xref target="provPut" format="default"/> of RFC 996 7
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:put:ful l</td> <td align="left">urn:ietf:params:scim:event:prov:put:ful l</td>
<td align="left">Resource Put Event (full data)</td> <td align="left">Resource Put Event (full data)</td>
<td align="left"> <td align="left">
<xref target="provPut" format="default"/> of this do cument. <xref target="provPut" format="default"/> of RFC 996 7
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:delete< /td> <td align="left">urn:ietf:params:scim:event:prov:delete< /td>
<td align="left">Resource Deleted Event</td> <td align="left">Resource Deleted Event</td>
<td align="left"> <td align="left">
<xref target="provDelete" format="default"/> of this document. <xref target="provDelete" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:activat e</td> <td align="left">urn:ietf:params:scim:event:prov:activat e</td>
<td align="left">Resource Activated Event</td> <td align="left">Resource Activated Event</td>
<td align="left"> <td align="left">
<xref target="provActivate" format="default"/> of th is document. <xref target="provActivate" format="default"/> of RF C 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:prov:deactiv ate</td> <td align="left">urn:ietf:params:scim:event:prov:deactiv ate</td>
<td align="left">Resource Deactivated Event</td> <td align="left">Resource Deactivated Event</td>
<td align="left"> <td align="left">
<xref target="provDeactivate" format="default"/> of this document. <xref target="provDeactivate" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">urn:ietf:params:scim:event:misc:asyncre sp</td> <td align="left">urn:ietf:params:scim:event:misc:asyncre sp</td>
<td align="left">Asynchronous Request Completion</td> <td align="left">Asynchronous Request Completion</td>
<td align="left"> <td align="left">
<xref target="asyncEvent" format="default"/> of this document. <xref target="asyncEvent" format="default"/> of RFC 9967
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.hunt-idevent-scim" to="SCIM-EVENT-EXT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <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/refere nce.BCP.0195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/refere nce.BCP.0195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7240.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7240.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7515.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7643.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7643.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7644.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7644.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8141.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8141.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8935.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8935.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8936.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8936.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8417.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8417.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9493.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9493.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/refere nce.I-D.draft-hunt-idevent-scim-00.xml"/>
<reference anchor="SSF"> <!-- [I-D.hunt-idevent-scim]
draft-hunt-idevent-scim-00
IESG State: Expired as of 4/3/26
-->
<reference anchor="I-D.hunt-idevent-scim" target="https://datatracker.ietf.org/d
oc/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" target="https://openid.net/specs/openid-
sharedsignals-framework-1_0.html">
<front> <front>
<title>Shared Signals Framework</title> <title>OpenID Shared Signals Framework Specification 1.0
<author><organization>OpenID Foundation</organization></ </title>
author> <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> </front>
<format target="https://openid.net/specs/openid-sharedsignal s-framework-1_0.html" type="HTML"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="modes" numbered="true" toc="default"> <section anchor="modes" numbered="true" toc="default">
<name>Use Cases</name> <name>Use Cases</name>
<t> <t>
SCIM Events may be used in a number of ways. The following non-n ormative sections describe some of SCIM Events may be used in a number of ways. The following non-n ormative sections describe some of
the expected uses. the expected uses.
</t> </t>
<section anchor="replication" toc="default" numbered="true"> <section anchor="replication" toc="default" numbered="true">
<name>Domain Based Replication</name> <name>Domain-Based Replication</name>
<t> <t>
The objective of "Domain Based Replication" events (DBR) is to synchronize resource changes between The objective of DBR events is to synchronize resource chang es between
SCIM Service Providers in a common administrative domain. In this mode, complete information about SCIM Service Providers in a common administrative domain. In this mode, complete information about
modified resources are shared between replicas for immediate processing. modified resources are shared between replicas for immediate processing.
</t> </t>
<!--[rfced] The SVG and ASCII artworks of Figure 20 are inconsistent
with each other. Please provide updated artwork for this figure.
(See https://www.rfc-editor.org/authors/rfc9967.html#figure-20)
For example, inconsistent labels exist in the html vs. txt outputs:
Client A vs. SCIM Client A
SCIM Service Provider vs. Service Provider
[4] Update local node vs. Update local node [4]
[Note that in the html output, this text appears outside
the box, but in the txt output, it appears inside the box.]
-->
<figure align="left" anchor="dbrSequence"> <figure align="left" anchor="dbrSequence">
<name>Domain Based Replication Sequence</name> <name>Domain-Based Replication Sequence</name>
<artset> <artset>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+----------------+ +----------------+
| SCIM Client A | | SCIM Client A |
+----------------+ +----------------+
| |
[1] SCIM Operation [1] SCIM Operation
| |
v v
+----------------+ +----------------+
skipping to change at line 1523 skipping to change at line 1793
<!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com --> <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->
</svg> </svg>
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
From a security perspective, it is assumed that servers shar ing DBR events are secured by a common From a security perspective, it is assumed that servers shar ing DBR events are secured by a common
access policy and all servers are required to be up-to-date. access policy and all servers are required to be up to date.
From a privacy perspective, because all servers are in the s ame administrative domain, the primary objective From a privacy perspective, because all servers are in the s ame administrative domain, the primary objective
is to keep individual Service Provider nodes or cluster sync hronized. is to keep individual Service Provider nodes or clusters syn chronized.
</t> </t>
</section> </section>
<section anchor="coordination" toc="default" numbered="true"> <section anchor="coordination" toc="default" numbered="true">
<name>Co-ordinated Provisioning</name> <name>Co-ordinated Provisioning</name>
<t> <t>
In "Co-ordinated Provisioning" (CP), SCIM resource change ev ents perform the function of change In CP, SCIM resource change events perform the function of c hange
notification without the need to provide raw data. In any Ev ent Publisher and Receiver notification without the need to provide raw data. In any Ev ent Publisher and Receiver
relationship, the set of SCIM Resources (e.g., Users) that a re linked or co-ordinated is managed relationship, the set of SCIM Resources (e.g., Users) that a re linked or co-ordinated is managed
within the context of an event feed and may be a subset of t he total set of resources on within the context of an event feed and may be a subset of t he total set of resources on
either side. For example, an event feed could be limited to users who have consented to the sharing 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 of information between domains. To support capability, "feed " specific events are defined to indicate
the addition and removal of SCIM Resources from a feed. For example, when a user consents to the addition and removal of SCIM 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 the sharing of information between domains, events about the User may be added to the feed
between the Event Publisher and Receiver. between the Event Publisher and Receiver.
</t> </t>
<figure align="left"><name>Co-Ordinated Provisioning Sequence</name>
<!--[rfced] The SVG and ASCII artwork for Figure 21 are inconsistent
with each other. Please provide updated artwork for this figure.
(See https://www.rfc-editor.org/authors/rfc9967.html#figure-21)
Examples:
a) Inconsistent labels and positioning of the terms in the html vs. txt outputs:
SCIM Client vs. SCIM Clnt (CA)
SCIM Service Provider vs. SCIM Service Provider (SP)
Client A Co-op Receiver vs. Client A Co-op Receiver (ER)
Co-op Action Endpoint vs. Co-op Action Endpoint(LEP)
[1] SCIM Operation vs. "SCIM Operation"
[2] SCIM Response vs. "SCIM Response"
[3] Event SCIM:prov:<op> id=xyz vs. "Event SCIM:prov:<op>, id=xyz"
[Note: There is a dotted line underneath this term in the html output
but no dotted line in the txt output.]
Receiver may accumulate events for periodic action. vs.
Note: Receiver may accumulate events for periodic action
[Note: This text appears in a box in the html output and without a
box in the txt output.]
[4] SCIM GET <id> vs. "SCIM GET <id>"
[Note: this term appears over the line in the html output but
next to the line in the txt output.]
[5] Filtered Resource Response vs. "Filtered Resource Resp."
[Note: This term appears over the line in the html output but
next to the line in the txt output.]
[6] Co-ordinated Action vs. "Co-ord Action"
[Note: This term appears over the line in the html output but
under the line in the txt output.]
b) "loop" (and the box it appears in) is present in the html output but is
missing in the txt output.
-->
<figure align="left"><name>Co-ordinated Provisioning Sequence</name>
<artset><artwork type="ascii-art" align="center"><![CDATA[ <artset><artwork type="ascii-art" align="center"><![CDATA[
+-----------+ +---------------+ +---------------+ +---------------+ +-----------+ +---------------+ +---------------+ +---------------+
| SCIM Clnt | | SCIM Service | | Client A Co-op| | Co-op Action | | SCIM Clnt | | SCIM Service | | Client A Co-op| | Co-op Action |
| (CA) | | Provider (SP) | | Receiver (ER) | | Endpoint(LEP) | | (CA) | | Provider (SP) | | Receiver (ER) | | Endpoint(LEP) |
+-----------+ +---------------+ +---------------+ +---------------+ +-----------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| "SCIM Operation" | | | | "SCIM Operation" | | |
+----------------->| | | +----------------->| | |
|<-----------------+ "SCIM Response" | | |<-----------------+ "SCIM Response" | |
| | | | | | | |
skipping to change at line 1684 skipping to change at line 1996
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
In CP mode, the receiver of an event must call back to the o riginating SCIM Service Provider In CP mode, the receiver of an event must call back to the o riginating SCIM Service Provider
(e.g., using a SCIM GET request) to reconcile the newly chan ged resource in (e.g., using a SCIM GET request) to reconcile the newly chan ged resource in
order to obtain the changes. order to obtain the changes.
</t> </t>
<t> <t>
Co-ordinated provisioning has the following benefits: CP has the following benefits:
</t> </t>
<ul> <ul>
<li> <li>
Differences in schema (e.g., attributes) between domains . For example, a receiving domain may 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 attr ibutes (e.g., role-based access data) to only be interested in or allowed to access to a few attr ibutes (e.g., role-based access data) to
enable access to an application. enable access to an application.
</li> </li>
<li> <li>
Different Event Receivers may have differing needs when accessing information and thus be assigned Different Event Receivers may have differing needs when accessing information and thus may be assigned
varying access rights. Minimal information events combin ed with callbacks for data allows varying access rights. Minimal information events combin ed with callbacks for data allows
data filtering to be applied. data filtering to be applied.
</li> </li>
<li> <li>
Receivers can take independent action. Such as deciding which attributes or resource lifecycle Receivers can take independent action such as deciding w hich attributes or resource life cycle
changes to accept. For example, in the case of a conflic t, a receiver can prioritize one domain changes to accept. For example, in the case of a conflic t, a receiver can prioritize one domain
source over another. source over another.
</li> </li>
<li> <li>
A receiver may throttle or buffer changes rather than ac t immediately on a notification. For A receiver may throttle or buffer changes rather than ac t immediately on a notification. For
example, for a frequently changing resource, the example, for a frequently changing resource, the
receiver may choose to make a scheduled SCIM GET for res ources that have been marked "dirty" by receiver may choose to make a scheduled SCIM GET for res ources that have been marked "dirty" by
events received in the last scheduled cycle. events received in the last scheduled cycle.
</li> </li>
</ul> </ul>
<t> <t>
A disadvantage of the CP approach is that it may be consider ed costly in the sense that each event A disadvantage of the CP approach is that it may be consider ed costly in the sense that each event
received might trigger a callback to the event issuer. This cost should be weighed against the cost 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 receiv er. Furthermore, a receiver is not required producing filtered information in each event for each receiv er. Furthermore, a receiver is not required
to make a callback on every provisioning event. to make a callback on every provisioning event.
</t> </t>
<t> <t>
It is assumed that an underlying relationship between domain s exists that permits the exchange of It is assumed that an underlying relationship between domain s exists that permits the exchange of
personal information and credentials. For example, in a cros s-domain scenario a SCIM Service Provider personal information and credentials. For example, in a cros s-domain scenario, a SCIM Service Provider
would have been previously authorized to perform SCIM provis ioning operations and publish change events. would have been previously authorized to perform SCIM provis ioning operations and publish change events.
As such, appropriate confidentiality and privacy agreements should be in place between the domains. As such, appropriate confidentiality and privacy agreements should be in place between the domains.
</t> </t>
<t> <t>
When sharing information between parties, CP Events minimize the information shared in each message and When sharing information between parties, CP Events minimize the information shared in each message and
require the Security Event Receiver to receive more informat ion from the Event Publisher as needed. require the Security Event Receiver to receive more informat ion from the Event Publisher as needed.
In this way, the Event Receiver is able to have regular acce ss to information through normal In this way, the Event Receiver is able to have regular acce ss to information through normal
SCIM protocol access restrictions. The Event Receiver and Pu blisher may agree to communicate these SCIM protocol access restrictions. The Event Receiver and Pu blisher may agree to communicate these
updates through a variety of transmission methods such as pu updates through a variety of transmission methods such as pu
sh and pull based HTTP like in <xref target="RFC8935"/>, sh- and pull-based HTTP <xref target="RFC8935"/>
<xref target="RFC8936"/>, or HTTP GET (see <xref target="asy <xref target="RFC8936"/> or HTTP GET (see <xref target="asyn
ncRequest"/>), streaming technologies cRequest"/>); streaming technologies
(e.g., Kafka or Kinesis), or via webhooks as in the <xref ta (e.g., Kafka or Kinesis); or webhooks such as in the <xref t
rget="SSF" format="default">Shared Signals Framework</xref>. arget="SSF" format="default">Shared Signals Framework</xref>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="include"> <section anchor="Acknowledgements" numbered="false" toc="include">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank the following contributors:</t> <t>The authors would like to thank the following contributors:</t>
<ul> <ul>
<li><t><contact fullname="Morteza Ansari"/> and <contact <li><t><contact fullname="Morteza Ansari"/> and <contact
fullname="William Denniss"/>, who contributed significantly to fullname="William Denniss"/>, who contributed significantly to
<xref target="I-D.hunt-idevent-scim"/>, upon which this <xref target="I-D.hunt-idevent-scim"/> upon which this
document is based.</t></li> document is based.</t></li>
<li>The participants of the SCIM working group and the <li>The participants of the SCIM Working Group and the
id-event list for their support of this specification.</li> IETF id-event mailing list for their support of this specificati
<li><t>Thanks to <contact fullname="Deb Cooley"/>, <contact on.</li>
<li><t><contact fullname="Deb Cooley"/>, <contact
fullname="Dean Saxe"/>, <contact fullname="Elliot Lear"/>, fullname="Dean Saxe"/>, <contact fullname="Elliot Lear"/>,
<contact fullname="Pamela Dingle"/>, <contact fullname="Mark <contact fullname="Pamela Dingle"/>, <contact fullname="Mark
Nottingham"/>, <contact fullname="R Gideon"/>, <contact Nottingham"/>, <contact fullname="R Gideon"/>, <contact
fullname="Paulo Jorge Correia"/>, <contact fullname="Shuping fullname="Paulo Jorge Correia"/>, <contact fullname="Shuping
Peng"/>, <contact fullname="Elwyn Davies"/>, <contact Peng"/>, <contact fullname="Elwyn Davies"/>, <contact
fullname="Luigi Lannone"/>, <contact fullname="Mohamed fullname="Luigi Lannone"/>, <contact fullname="Mohamed
Boucadair"/>, <contact fullname="Roman Danyliw"/>, <contact Boucadair"/>, <contact fullname="Roman Danyliw"/>, <contact
fullname="Ketan Talaulikar"/>, <contact fullname="Mahesh fullname="Ketan Talaulikar"/>, <contact fullname="Mahesh
Jethanandani"/>, and <contact fullname="Mike Bishop"/> for Jethanandani"/>, and <contact fullname="Mike Bishop"/> for
their write-ups and reviews</t></li> their write-ups and reviews.</t></li>
</ul> </ul>
</section> </section>
<!-- [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.
Note that we updated <artwork> to <sourcecode> in several sections. Please
confirm that this is correct.
In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Asynchronous SCIM Request vs. asynchronous SCIM request
(also Asynchronous SCIM Request capability)
Asynchronous Request completion vs.
asynchronous request completion vs.
Asynchronous Request Completion Event vs.
Asynchronous Request Completion event vs.
asynchronous request completion event vs.
Asynchronous Event completion event vs.
Asynchronous Completion event
Event Feed vs. event feed
Event Payload vs. event payload
[Note: RFC 8417 uses the lowercase forms for "event feed" and
"event payload". Please also consider if the case should be updated
for "Event Publisher", "Event Stream", and "Event Receiver".]
Event Receiver vs. receiver
[Note: Do any of the lowercase forms refer to an "Event Receiver"?]
b) How may we update these terms for consistency?
Event Feed (or event feed) vs. Feed Event vs. Feed Management event
HTTP Service Endpoint vs. HTTP endpoint
[Note: Also consider "Event Publisher endpoint".]
HTTP Status 202 (Accepted) vs.
HTTP Status 202 Accepted vs.
HTTP 202 Accepted
JSON Web Token vs. JSON token
c) We note that some terms that appear as uppercase (or a mix of
uppercase and lowercase) in this document appear as lowercase in the
referenced RFCs. Would you like to update the terms below to reflect
the forms on the right for consistency with the referenced RFCs, or
do you prefer for these terms to be uppercase throughout the document?
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)
d) FYI: We made the following updates for consistency. Please let us
know if any further updates are needed.
Bulk request -> bulk request (per RFC 7644)
Etag -> ETag (per RFC 7644)
HTTP Client -> HTTP client (per RFC 7644)
HTTP Header -> HTTP header (per RFCs 7240 and 7644)
SCIM event -> SCIM Event
e) For "Co-ordinated Provisioning", may we remove the hyphen
to match common spelling of "coordinated"?
Or, is there some special meaning when using the hyphen?
(Depending on your reply, we will update the various forms of
'coordination' in this document.)
f) We note the following variance:
Co-ordinated Provisioning (CP) vs. Co-operative Provisioning (CP)
May the 2 instances of "Co-operative Provisioning" be updated to
"Coordinated Provisioning" (note: "operative" to "ordinated")?
In other words, we suggest:
Section 2.3
This section defines events related to changes in the content of an
event feed such as SCIM Resources that are being added or removed
from an event feed or events used in Coordinated Provisioning
scenarios where only a subset of entities are shared across an Event
Feed.
Section 2.4
These events are used in both Domain-Based Replication (DBR) and
Coordinated Provisioning (CP) mode.
-->
<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and each
expansion in the document carefully to ensure correctness.
JSON Web Signature (JWS)
Globally Unique Identifier (GUID)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 190 change blocks. 
338 lines changed or deleted 777 lines changed or added

This html diff was produced by rfcdiff 1.48.