SCIM Profile for Security Event Tokens
draft-ietf-scim-events-16

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-scim-events and RFC 9967, changed IESG state to RFC Published)

[Ballot discuss]
As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with changes here, but can be convinced otherwise.

# Inapplicable normative keywords

1030         *  LONG indicates the SCIM Service Provider MAY complete
1031             asynchronously at its discretion (e.g.  based on a max wait
1032             time);

1034         *  REQUEST indicates the request SHALL complete asynchronously
1035             when requested by the SCIM Client.

These normative keywords don't seem correct; it's not clear who is required to do what under which circumstances. Assuming that these are attributes that a server declares about itself, they probably don't need to use the keywords anyway. Would these be more accurate?

- LONG indicates that the SCIM Service Provider might complete long-running tasks asynchronously based on its own criteria
- REQUEST indicates that the SCIM Service Provider will complete requests asynchronously only when requested by the SCIM Client

1066   recovery requirements of both sides.  To address this, Event
1067   Publishers SHOULD consider storing events for receivers for longer

We can't normatively recommend "considering" an action — if we think that the right behavior is to store the events longer but there are circumstances where that might not be practicable, it's a SHOULD. We might list factors that the implementers could consider in deciding whether to follow the SHOULD, but that's distinct from the normative SHOULD consider.

[Ballot comment]
128   SCIM Events can be shared over an established Event Feed that can
129   allow receivers to monitor trigger independent asynchronous action.

If it doesn't allow that, is there still a point? If not, consider "can allow" => "allows"

136   originator of the change.  Unlike SCIM Protocol requests which convey
137   protocol commands, Security Events describe statements of fact about
138   changes by the SCIM Service Provider.  This approach allows the Event

Judging by RFC7644, SCIM requests can also retrieve resources which are presumably also statements of fact. I don't think that's the differentiator between these that you want to call out.

Perhaps this should read, "Unlike retrieval of complete or partial resources via SCIM, which represent state as of a single point in time, Security Events describe state changes at the SCIM Service Provider."

140   its own context.  For example, the receiver can reconcile schema and
141   resource type differences between domains.

I still do not understand what this example means. If it would be clear to anyone more familiar with SCIM, feel free to chalk it up to my ignorance and move on.

826   request.  The event payload contains the attributes defined in SCIM
827   Bulk Section 3.7 of [RFC7644] and is the same a single SCIM Bulk

There are words colliding with a reference. Please rearrange this to read more naturally, which may simply be removing the words "SCIM Bulk".

[Ballot comment]
Hi Phil, all,

Thanks for the follow-up and changes made since last time I reviewed the doc [1]. The changes at [2] are real improvements.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/scim/U-g98Db0uGT-7FdIjx5raWLg2u0/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-scim-events-10&url2=draft-ietf-scim-events-12&difftype=--html

[Ballot discuss]
As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with changes here, but can be convinced otherwise.

# HTTP Preferences Interaction

In Section 1, you reference RFC7240 for the "Async-response" preference, but this string doesn't appear in RFC7240. In Section 2.5.1.1, the "respond-async" preference described in RFC7240 is used, so I suspect this is a simple error in the introduction.

In what way is this a "profile" of Prefer: respond-async? This appears to simply be using this preference as an element of a new exchange in SCIM.

# Relationship of SCIM and HTTP

117   In a typical HTTP client-server relationship, a SCIM Protocol Client
118   issues commands to a SCIM Service Provider using HTTP methods such as
119   POST, PATCH, and DELETE [RFC7644] that cause a state change to a SCIM

A "typical HTTP client-server relationship" doesn't involve SCIM clients at all. RFC7644 doesn't define those HTTP methods, so it's not an appropriate reference as phrased.

I think you want something more like "SCIM [RFC7644] is an HTTP-based protocol [RFC9110]. A SCIM Protocol Client makes HTTP requests to a SCIM Service Provider using well-known endpoints and request methods, such as..."

# Distinction of PUT and PATCH events

I'd like to see more discussion of the rationale for making these separate events. They make sense to be distinct on the SCIM side, since a client might want to declare the desired new state (PUT) or declare the specific changes to be made (PATCH). But the observer doesn't care *how* the change was communicated to the server, they care what net change was ultimately made. So if a PUT was used, but differed from the old state on only one field, they want to know about that field. Conversely, if a PATCH changed the value of many fields simultaneously, the observer needs to know that all those fields changed.

Thus, I'd think it might make more sense to collapse these into a single "update" event.

I note that the examples lend themselves to the operations somewhat naturally, with one adding a member to what might be a large set and the other fully restating a relatively compact object. Is the goal here actually to have a midway state between transferring the full new state and merely providing notice, by being able to provide a diff of a small change to a large object?

# Bulk Request Operation Numbers and Normative Examples

807   The "txn" claim MUST be set to the value originally returned to the
808   requesting SCIM Client (see Section 2.5.1.1) appended with a colon
809   (":") followed by the request operation number.  For example, if the
810   "txn" claim value was "2d80e537a3f64622b0347b641ebc8f44", then the
811   first Asynchronous Response Event Token representing the first
812   operation SHALL have a "txn" claim value of
813   "2d80e537a3f64622b0347b641ebc8f44:1", the second operation SHALL have
814   a value of "2d80e537a3f64622b0347b641ebc8f44:2", and so on.

What does it mean to have a normative requirement (SHALL) inside an example? Either it's a non-normative example or it's a required behavior.

The example suggests that transactions are sequential and indexed starting at 1. Is this spelled out anywhere? Could a server choose to zero-index the operations? How would the client know which the server is using?

(I would have thought it more intuitive to use the "bulkId" value to identify each operation from the batch rather than generating a new identifier, except that bulkId is optional for the client to include.)

# Inapplicable normative keywords

1030         *  LONG indicates the SCIM Service Provider MAY complete
1031             asynchronously at its discretion (e.g.  based on a max wait
1032             time);

1034         *  REQUEST indicates the request SHALL complete asynchronously
1035             when requested by the SCIM Client.

These normative keywords don't seem correct; it's not clear who is required to do what under which circumstances. Assuming that these are attributes that a server declares about itself, they probably don't need to use the keywords anyway. Would these be more accurate?

- LONG indicates that the SCIM Service Provider might complete long-running tasks asynchronously based on its own criteria
- REQUEST indicates that the SCIM Service Provider will complete requests asynchronously only when requested by the SCIM Client

1046   As this specification is based upon the Security Event Tokens
1047   specification and the associated delivery specifications the
1048   following Security Considerations SHALL be applied:

1126   As this specification is based upon the Security Event Tokens and the
1127   associated delivery specifications the following Privacy
1128   Considerations SHALL be applied:

It's not clear who does what from these SHALLs. This might be as simple as changing the statement to, "As this specification is based upon the Security Event Tokens specification and the associated delivery specifications, the (Security|Privacy) Considerations of [RFC8417], [RFC8935], and [RFC8936] are also applicable to this mechanism."

1066   recovery requirements of both sides.  To address this, Event
1067   Publishers SHOULD consider storing events for receivers for longer

SHOULD CONSIDER is an RFC 6919 keyword; see https://www.rfc-editor.org/rfc/rfc6919#section-2. Do you mean that they SHOULD store events for longer periods?

[Ballot comment]
128   SCIM Events can be shared over an established Event Feed that can
129   allow receivers to monitor trigger independent asynchronous action.

If it doesn't allow that, is there still a point? If not, don't express it as a possibility.

As written, it's also difficult to parse which of these are which parts of speech.

Consider "that allows receivers to monitor trigger-independent state changes as asynchronous actions execute."

136   originator of the change.  Unlike SCIM Protocol requests which convey
137   protocol commands, Security Events describe statements of fact about
138   changes by the SCIM Service Provider.  This approach allows the Event

Judging by RFC7644, SCIM requests can also retrieve resources which are presumably also statements of fact. I don't think that's the differentiator between these that you want to call out.

Perhaps this should read, "Unlike retrieval of complete or partial resources via SCIM, which represent state as of a single point in time, Security Events describe state changes at the SCIM Service Provider."

140   its own context.  For example, the receiver can reconcile schema and
141   resource type differences between domains.

I do not understand what this example means.

153   For purposes of readability examples are not URL encoded.
154   Implementers MUST percent encode URLs as described in Section 2.1 of
155   [RFC3986].

I think SCIM uses "URI" throughout rather than "URL". On a cursory search, I don't see any examples that contain restricted characters that would be percent-encoded in real usage. Is this note even needed? (Though yes, I see this note is copied verbatim from RFC7644.)

In Section 1.3, rather than defining terms as "Abbreviation for...", define the full term with the abbreviation in parentheses, e.g. "Co-ordinated Provisioning (CP):".

274   resource state change for a single resource or subject.  Finally, as
275   recommended in Section 3 of [RFC8417] the JWT "sub" claim SHALL NOT
276   be used to prevent confusion with JWT authorization tokens.

I suggest reordering this sentence in order to avoid confusion over whether the claim SHALL NOT be used for that purpose or, because of that risk, the claim SHALL NOT be used at all.

323   emails,username, ...
324       A SCIM attribute that is unique to both the Event Publisher and
325       Receiver.  Alternative attributes that are unique such as email or

First, given that there are a variety of possible attributes here, I'd avoid putting them in the definition list. Rather, following the list, something like "The sub_id object MAY contain additional attributes for use in situations where...." Second, "unique to both the Event Publisher and Receiver" could be misinterpreted as being about the identification of those parties, rather than the subject of the event. Perhaps "Such attributes should allow the Event Publisher and Receiver to uniquely identify a subject. Possible identifiers might include `email`, `username`, etc."

347       In contrast to jti claims which uniquely identifies a token, the
348       txn remains the same when one or more SETs are generated for

Please provide an informative reference to where such claims are defined, since this is the only place they're mentioned in the text.

419   This event has minimal disclosure.

What does that mean?

755   *  A location URI where the completion token MAY be retrieved using
756       HTTP GET

I'm unclear what a "completion token" is in this context, and it doesn't appear to be defined in the document or in RFC7644.

800   SCIM Protocol Section 3.7 of [RFC7644] provides the ability to submit
801   multiple SCIM operations in a single request.  When an asynchronous

826   request.  The event payload contains the attributes defined in SCIM
827   Bulk Section 3.7 of [RFC7644] and is the same a single SCIM Bulk

In both these instances, there are words colliding with a reference. Please rearrange these to read more naturally, which may simply be removing the words "SCIM Protocol" and "SCIM Bulk".

1173   Specification Document:
1174       See Sections Section 3 and Section 2.5.1.1 of this document.

This should at least be "Sections 2.5.1.1 and 3", but also, Section 3 contains the definition of this header field and a reference to Section 2.5.1.1. I'd make Section 3 the reference here and trust readers to follow links.

1176   Comments:
1177       See also Section 2.2 of [RFC8417] Security Event Tokens.

Is this comment actually going to be usable by someone looking at the registry? Consider dropping this entirely.

1179 7.2.  Registering Event Capability with Scim Service Provider Config

1181   For the SCIM Schema Registry Section 10.4 of [RFC7643], under Service
1182   Provider Configuration Schema
1183   (urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig), add
1184   Section 3 of this document to the Reference column.

Section 3 defines the HTTP header field. Should this be Section 4? Consider using xrefs so that renumbered sections in your document update automatically.

1241       Initial values to be added to the SCIM Events Registry
1242       Section 7.4.

This is missing some words. Perhaps "Initial values to be added to the SCIM Events Registry are listed in Section 7.4."?

1492   In CP mode, the receiver of an event must callback to the originating

"callback" is a noun, "call back" is a verb. This should probably be "call back".

===NITS FOLLOW===

Section 2.2:
  - "SET defined" => "SET-defined"
  - "`jti` claims which uniquely identifies" => "`jti` claims, which uniquely identify" or "a `jti` claim, which uniquely identifies"
  - "jit values an a" => "jti values and a"
Section 2.5.1.1, no need for quotation marks around "asynchronous"
Section 2.5.1.3, "same a single" => "same as a single"
Section 3, "client's" => "clients"; "For example a" => "For example, a"
Section 7.1, "Section 16.3.1 [RFC9110]" => "Section 16.3.1 of [RFC9110]"
Appendix A.2, "role based access data" => "role-based access to data" or "role-based data access"?

[Ballot comment]
Section 1.3, paragraph 6
>    Attributes and Claims
>      The JWT specification [RFC7519] upon which SET is based uses the
>      term "claims" to refer to attributes in a JSON token.  SCIM in
>      contrast uses the term "attributes" to refer to JSON attributes.
>      For the purposes of this draft, the terms "attributes" and
>      "claims" are equivalent.

Is this not a duplicate of what is mentioned above?

Section 1.3, paragraph 7
>    DBR
>      Abbreviation for "Domain Based Replication" as defined in
>      Appendix A.1.  In this mode because there is an administrative
>      relationship spanning multiple operational domains, data shared in
>      Events typically uses the full mode variation of change events
>      including the data payload attribute (see Section 2.4).  This
>      eliminates the need for a callback to retrieve additional data.

What is "full mode variation of change events"? Can this be described or defined?

Section 5, paragraph 0
> 5.  Security Considerations

This document covers Security Considerations, Privacy Considerations, and IANA Considerations, but not Operational or Management Considerations as Med has pointed out. I would imagine that there are considerations in how SCIM events are logged or errors reported that might be useful for an operator.

"A.1.", paragraph 3
>                      +----------------+
>                      |  SCIM Client A |
>                      +----------------+
>                              |
>                    [1] SCIM Operation
>                              |
>                              v
>                      +----------------+
>                      | Service        |
>                      | Provider      |
>                      +----------------+
>                              ^
>                    [2] SCIM Response
>                              |
>                              |
>                              v
>                      +------------------------+
>                      | Service Provider      |
>                      | Replica                |
>                      +------------------------+
>                              |
>              [3] Event SCIM:prov: id=xyz
>                              |
>                              v
>                      +----------------+
>                      | Update local  |
>                      | node [4]      |
>                      +----------------+
>
>                Figure 20: Domain Based Replication Sequence

This figure and the next does not render itself in the html version of the document.

No reference entries found for these items, which were mentioned in the text:
[draft-hunt-idevent-scim-00].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1 and every other place in the document.
> RFC7644] that cause a state change to a SCIM Resource. When multiple indepen
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.1, paragraph 5
> de, the receiver of an event must callback to the originating SCIM Service P
>                                  ^^^^^^^^
The word "callback" is a noun. The verb is spelled with a space.

[Ballot discuss]
** Section 7.3
  IANA will add a new registry called “SCIM Event URIs” to the “System
  for Cross-domain Identity Management (SCIM) Schema URIs” registry
  group initiated by Section 10.1 of [RFC7643] at
  https://www.iana.org/assignments/scim.

  Unless otherwise stated, the procedures and definitions for this sub-
  registry are inherited from the parent registry.

-- What does the inheritance guidance mean?  The registry group (“System for Cross-domain Identity Management (SCIM) Schema URIs”) doesn’t have guidance on procedures or definitions.  It is a “group”.

-- What is the registration policy for this new registry?

** Section 7.3 contains RFC2119 keywords.  See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/.  Please move these definitions of the registry columns elsewhere is RFC2119 keywords are needed.

[Ballot comment]
Thank you to Elwyn Davies for the GENART review.

** Abstract
  This draft updates Section 5, of RFC7643 defining additional
  attributes for
  urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig schema.
  This draft updates RFC7644 with the optional new Asynchronous SCIM
  Request capability.

It would be worth repeating this summary of how this document updates the others in the body of the document

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I have some minor comments/suggestions to improve the document.

Abstract:
The use of RFC references isn't necessary and is affecting readability. How about?

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.

The following sentence with the section reference is better placed in the Introduction and instead suggest using the following in its place in the Abstract:

This draft updates RFC7643 by defining additional attributes for urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig schema and it updates RFC7644 with the optional new Asynchronous SCIM Request capability.

Section 1.2:

s/percent encode/percent-encode

[Ballot comment]
Thank you for the work to develop this document.

I did not note any transport-related concerns. I saw some issues around the use of normative language, but I see Med discovered more. I therefore support his recommendations to review the use of RFC 2119 keywords.

Gorry

[Ballot discuss]
Hi Phillip, Nancy, Mike, and Jen,

Thank you for the effort put into this specification.

Thanks to Luigi Iannone for the OPSDIR review. I trust the authors will engage and follow-up to that review.

# Lack of operational considerations

The spec is straightforward, but the document does not discuss any operational considerations related to the use of the events specified in the document (logging, backward compatibility, manageability considerations, etc.).

This is even exacerbated as we don’t have a data model to normatively define the structure of the various message bodies. I appreciated there are many examples provided in the text, though.

# The use of normative language is problematic

## This starts with the conventions section:

CURRENT:
  Throughout this document all figures MAY contain spaces and extra
  line-wrapping for readability and space limitations. 

Which this is clearly about “may”

## Then, same issue with many entries in the introduction, where we have

CURRENT:
  Event Feed / Event Stream
      This describes the quality that a feed (aka stream) MAY be managed
      per receiving client.  A SET transfer (see [RFC8935] [RFC8936])
      Service Provider MAY offer to allow Event Receivers to "subscribe"
      to specific event types or events about specific resources (see
      Feed Management events Section 2.3).

Which should be updated to:

  Event Feed / Event Stream
      This describes the quality that a feed (aka stream) may be managed
      per receiving client.  A SET transfer (see [RFC8935] [RFC8936])
      Service Provider may offer to allow Event Receivers to "subscribe"
      to specific event types or events about specific resources (see
      Feed Management events Section 2.3).

And idem for

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

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

## also, in the main document for statements such as:

CURRENT:
  Note that because the
  event MAY be used for replication, the id attribute that was assigned

# Appendix non-normative

CURRENT:
  SCIM Events may be used in a number of ways.  The following non-
  normative sections describe some of the expected uses.

However, that appendix includes statements such as

CURRENT:
  In any Event Publisher and Receiver relationship,
  the set of SCIM Resources (e.g. Users) that are linked or co-
  ordinated is managed within the context of an event feed and MAY be a
  subset of the total set of resources on either side. 

…

  For example, when a user
  consents to the sharing of information between domains, events about
  the User MAY be added to the feed between the Event Publisher and
  Receiver.

…

  *  Different Event Receivers MAY have differing needs when

..
  *  A receiver MAY throttle or buffer changes rather than act
      immediately on a notification.  For example, for a frequently
      changing resource, the receiver MAY choose to make a scheduled
      SCIM GET for resources that have been marked "dirty" by events
      received in the last scheduled cycle.

I think most of these MAYs (has the same issue as the previous point).

# Do we need to indicate a max length for the string elements?

Unless I missed where this was discussed in the spec, but there is no guidance on the max length for string elements. Having string elements with unbounded length may be problematic for interoperability but can also misused. Can we include some guidance to follow here (or simply point to where this was discussed for similar matters)? Thanks

# Interoperability

CURRENT:
  emails,username, ...
      A SCIM attribute that is unique to both the Event Publisher and
      Receiver.  Typically, attributes like email or usernames are used
      in situations where normal SCIM identifiers (id and externalId)
      are insufficient to identify a common resource between an Event
      Publisher and Event Receiver.

This is an open list of items that might be included as sub_ids. However, who to make sure that an attribute will be understood by both parties? Are these cases that we can provided to illustrate when “normal” SCIM identifiers are insufficient?

# Both RFC8935 and RFC8936 should be listed as normative

These are normally cited in the document such as in:

CURRENT:
  As this specification is based upon the Security Event Tokens
  specification and the associated delivery specifications the
  following Security Considerations SHALL be applied:

  *  Section 5 of [RFC8417] (Security Event Token)

  *  Section 5 of [RFC8935] (Push-based Delivery Using HTTP)

  *  Section 4 of [RFC8936] (Poll-Based Delivery Using HTTP)

[Ballot comment]
# (nit) Abstract

OLD: Security Event Token Specification RFC 8417 to enable the

NEW: Security Event Token Specification (RFC 8417) to enable the


# Introduction

(1) nit

OLD:
  This specification defines Security Events for SCIM Service Providers       
  and receivers as specified by the Security Event Tokens (SET)
                    ^^^^^^^^^^^^
  [RFC8417] specification
            ^^^^^^^^^^^^^^

NEW:
  This specification defines Security Events for SCIM Service Providers
  and receivers as specified by the Security Event Tokens (SET)
  [RFC8417]

(2) I don’t parse this sentence (especially the marked part)

CURRENT;
  For example, the
  receiver can reconcile intentional schema and population differences
  between the domain.
  ^^^^^^^^^^^^^^^^^^

(3) nit

OLD:  [RFC7644] through the addition the Asynchronous SCIM Request option

NEW: [RFC7644] through the addition of the Asynchronous SCIM Request option

# Section 1.2: nit

OLD: URI’s contained within examples, have been shortened for space and

NEW: URIs contained within examples, have been shortened for space and

# Section 2.1

Can we please followed the same order listed in the narrative text and the example depicted in Figure 1?

CURRENT:
  Instead of "sub", the top-level claim "sub_id" SHALL be used.
  "sub_id" contains the subclaim attribute "format" set to scim to
  indicate the attributes present in the "sub_id" object are SCIM
  attributes.  The following "sub_id" attributes are defined:

# Section 2.5.1: Missing CR LF in this example

CURRNET:
  PUT /Users/2819c223-7f76-453a-919d-413861904646
  Host: scim.example.com
  Prefer: respond-async
  Content-Type: application/scim+json
  Authorization: Bearer h480djs93hd8
  {
    "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id":"2819c223-7f76-453a-919d-413861904646",
    "userName":"bjensen",
    "externalId":"bjensen",
    "name":{
      "formatted":"Ms. Barbara J Jensen III"
    },
    "roles":[],
    "emails":[
      {
          "value":"bjensen@example.com"
      }
    ]
  }

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-scim-events-09. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

a single new registration is to be made as follows:

Field Name: Set-txn
Status: Permanent
Structured Type:
Reference: [ RFC-to-be; Section 2.2, Section 2.5.1.1 ]
Comments: See also Section 2.2 [RFC8417] Security Event Tokens.

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the SCIM Event URIs registry. The new registry will be located in the System for Cross-domain Identity Management (SCIM) Schema URIs registry group located at:

https://www.iana.org/assignments/scim

The registration policy [RFC8126] for the new registry will be Expert Review. There are initial registrations in the new registry as follows:

Event URI Name Reference
urn:ietf:params:SCIM:event:feed:add Resource added to Feed Event [ RFC-to-be; Section 2.3.1]
urn:ietf:params:SCIM:event:feed:remove Remove resource From Feed Event [ RFC-to-be; Section 2.3.2]
urn:ietf:params:SCIM:event:prov:create:notice New Resource Event (notice only) [ RFC-to-be; Section 2.4.1]
urn:ietf:params:SCIM:event:prov:create:full New Resource Event (full data) [ RFC-to-be; Section 2.4.1]
urn:ietf:params:SCIM:event:prov:patch:notice Resource Patch Event (notice only) [ RFC-to-be; Section 2.4.2]
urn:ietf:params:SCIM:event:prov:patch:full Resource Patch Event (full data) [ RFC-to-be; Section 2.4.2]
urn:ietf:params:SCIM:event:prov:put:notice Resource Put Event (notice only) [ RFC-to-be; Section 2.4.3]
urn:ietf:params:SCIM:event:prov:put:full Resource Put Event (full data) [ RFC-to-be; Section 2.4.3]
urn:ietf:params:SCIM:event:prov:delete Resource Deleted Event [ RFC-to-be; Section 2.4.4]
urn:ietf:params:SCIM:event:prov:activate Resource Activated Event [ RFC-to-be; Section 2.4.5]
urn:ietf:params:SCIM:event:prov:deactivate Resource Deactivated Event [ RFC-to-be; Section 2.4.6]
urn:ietf:params:SCIM:event:misc:asyncResp Async Request Completion [ RFC-to-be; Section 2.5.1]

IANA Question --> IANA understands that space characters in the URNs in section 6.3 are the result of formatting issues in the generation of the current draft and should be removed in the initial registrations. Is this correct?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by ARTART Completed: Ready with Nits. Reviewer: Shuping Peng. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-09-24):

From: The IESG
To: IETF-Announce
CC: aaron@parecki.com, debcooley1@gmail.com, draft-ietf-scim-events@ietf.org, lear@cisco.com, scim-chairs@ietf.org, scim@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SCIM Profile for Security Event Tokens) to Proposed Standard


The IESG has received a request from the System for Cross-domain Identity
Management WG (scim) to consider the following document: - 'SCIM Profile for
Security Event Tokens'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-09-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a set of SCIM Security Events using the
  Security Event Token Specification RFC8417 to enable the asynchronous
  exchange of messages between SCIM Service Providers and receivers.
  SCIM Security Events are typically used for: asynchronous request
  completion, resource replication, and provisioning co-ordination.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-scim-events/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This work received 3-4 reviews out of a relatively small group.  There were no
objections to the work's publication.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has made any such threats, nor has indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are two OSS implementations and a third on the way.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.


This draft provides an extension to RFC 8417, which is quite internal to SCIM. 
To my knowledge no area reviews have taken place.  I would recommend an Ops Area and
Security Area review as part of the last call process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

While SCIM uses its own schema, this document is schema neutral.  No media types,
YANG models, MIBs or new URI schema are defined.  The working group has reviewed
the event URI sub-registry.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

n/a

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I've recommended small changes to the authors that they should address prior to AD review.

Specifically:

* Is there a reason Appendix A is an Appendix and not in the body?  It's a little odd to normatively
  reference appendices, and for appendices to have 2119/8174 language.
* Personal preference: I prefer security considerations that begin each paragraph with "The attacker could",
  and then provide a remediation.

I will note that the second one is just a preference.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This is a specification that has gone through working group processes
seeking broad adoption.  The intended document status in the data tracker is not set properly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Aaron confirmed with the authors all IPR checks.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?

Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

n/a

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The remaining errors are related to artwork, and appear to be spurious.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are no normative references that should be informative.  There are two
informative references that might be normative.  However, all are published RFCs,
and so there is no risk of a specification not being available.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

n/a

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.


No changes to other docs.  This document benefits from the use of existing IETF
standards which are documented as normative dependencies.  The introduction lays out
the relationship to those standards.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).


A new Set-txn http field header is requested, and will require expert review
for assignment.  A SCIM subregistry URI is created.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The subregistry should make use of the same designated experts as the
parent, as a matter of course.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This work received 3-4 reviews out of a relatively small group.  There were no
objections to the work's publication.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has made any such threats, nor has indicated extreme discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are two OSS implementations and a third on the way.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.


This draft provides an extension to RFC 8417, which is quite internal to SCIM. 
To my knowledge no area reviews have taken place.  I would recommend an Ops Area and
Security Area review as part of the last call process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

While SCIM uses its own schema, this document is schema neutral.  No media types,
YANG models, MIBs or new URI schema are defined.  The working group has reviewed
the event URI sub-registry.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

n/a

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I've recommended small changes to the authors that they should address prior to AD review.

Specifically:

* Is there a reason Appendix A is an Appendix and not in the body?  It's a little odd to normatively
  reference appendices, and for appendices to have 2119/8174 language.
* Personal preference: I prefer security considerations that begin each paragraph with "The attacker could",
  and then provide a remediation.

I will note that the second one is just a preference.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This is a specification that has gone through working group processes
seeking broad adoption.  The intended document status in the data tracker is not set properly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Aaron confirmed with the authors all IPR checks.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?

Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

n/a

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The remaining errors are related to artwork, and appear to be spurious.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are no normative references that should be informative.  There are two
informative references that might be normative.  However, all are published RFCs,
and so there is no risk of a specification not being available.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

n/a

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.


No changes to other docs.  This document benefits from the use of existing IETF
standards which are documented as normative dependencies.  The introduction lays out
the relationship to those standards.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).


A new Set-txn http field header is requested, and will require expert review
for assignment.  A SCIM subregistry URI is created.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The subregistry should make use of the same designated experts as the
parent, as a matter of course.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/