Hi Elwyn, Sorry I missed this from the last update. Thanks for the catch!
I have placed the changes in draft 12 which is available in github for now (https://raw.githubusercontent.com/ietf-scim-wg/draft-ietf-scim-events/refs/heads/main/draft-ietf-scim-events-12.txt). I’ll submit the update pending any further comments. Phil [email protected] > On Sep 25, 2025, at 3:24 PM, Elwyn Davies <[email protected]> wrote: > > I forgot one item: > > s7.2: The reference [SSF] OpenID Foundation, "Shared Signals Framework" is > not really stable enough to be a reference in a RFC. the document "OpenID > Shared Signals Framework Specification 1.0" at > https://openid.net/specs/openid-sharedsignals-framework-1_0.html might be a > better bet., and in Appendix A (last sentence) s/like in the/as in the/ > please!!! > > Regards, > > Elwyn > > > > On 25/09/2025 22:28, Elwyn Davies via Datatracker wrote: >> Document: draft-ietf-scim-events >> Title: SCIM Profile for Security Event Tokens >> Reviewer: Elwyn Davies >> Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://wiki.ietf.org/en/group/gen/GenArtFAQ> >> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. >> >> Document: draft-ietf-scim-events-10 >> Reviewer: Elwyn Davies >> Review Date: 2025-09-25 >> IETF LC End Date: 2025-09-24 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: Almost Ready. Sorry to be a little late with this review. It took >> me >> rather longer than expected due to unfamiliarity with the plethora of >> documents >> in SCIM stable. Most of my comments are at the nit/editorial issue level but >> there are a number of places where concepts appear without either truly prior >> definition or pointers to such definition and there are some areas of >> interaction with the other specifications in the SCIM stable that appear to >> need clarifying or correcting. >> >> Major issues: >> >> Minor issues: >> (This almost rises to the level of a minor issue) >> s2.2, txn item: I observe that the definitions of the txn and jti claims in >> Section 2.2 of RFC 8417 reverse the mandatoriness of txn and jti (txn >> optional >> and jti mandatory in RFC 8417). If this is fully intended, I think it would >> be >> good to emphasise the reversal. To relieve my curiosity, is there a good >> reason why this has been done assuming this *is* what was intended please? >> Possibly to do with the advent of the Set-txn HTTP response header? >> >> Nits/editorial comments: >> >> Global: s/i.e. /i.e., / (1 instance in s1.3). s/e.g. /e.g., / (12 instances) >> >> Global: References to Sections in other RFCs are normally expressed in the >> form >> Section <n.m...> of [RFC xyzm] - this makes it clearer that they are pointers >> to other documents as opposed to a local cross-ref plus a RFC with a missing >> comma/ >> >> Abstract/s1: Expand SCIM on first use (it isn't in the RFC Editor well known >> category) and refer to RFC 7642 which is the base specification for the SCIM >> story. >> >> s1, 1st sentence: The SET spec specifies a format for the events. Suggest >> s/as >> specified by/in the format defined by/ >> >> s1, para 4: I think it would be helpful to introduce the concept of Event >> Streams/Event Feeds here. Currently they appear in s1.3 without any previous >> connection and the word 'quality' is used there which I found very confusing. >> >> OLD: >> Security Event Tokens [RFC8417] and SCIM Events offer the ability to >> exchange messages that act as triggers for receivers to monitor over >> time in an asynchronous approach. This enables greater scale and >> timeliness, where only changed information is exchanged between >> parties. >> >> NEW: >> Security Event Tokens [RFC8417] and SCIM Events offer the ability to >> exchange messages that act as triggers for receivers to monitor changes >> to resources over >> time in an asynchronous approach. This enables greater scale and >> timeliness, where only changed information is exchanged between >> parties. The messages would be exchanged over Event Feeds (also >> known as Event Streams) linking SCIM clients and SCIM service >> providers. >> >> s1, para 5: I found this phrase slightly confusing - I initially read it as >> the >> event being delivered to the SCIM Client: s/delivered asynchronously to the >> originating SCIM Client/delivered asynchronously relative to the event in the >> originating SCIM Client/ >> >> s1, para 5, last word: s/domain/domains/ >> >> s1, para 6: s/defined/that are defined/ (it is the extra attributes that are >> defined in s3, not ...ServiceProviderConfig). >> >> s1.3: The following text appears to have duplicate discussions of the common >> meaning of claims and attributes - it needs tidying up. >> >>> In JSON Web Tokens and Security Event Tokens, the term "claim" refers >>> to JSON attribute values in a JSON Web Token [RFC7519] structure. >>> The term "claim" in tokens is used to indicate that an attribute >>> value may not be verified and its accuracy can be questioned. In the >>> context of SCIM, claims are referred to as attributes. For the >>> purposes of this specification claims and attributes are inter- >>> changeable. For consistency, JWT and SET IANA registered attributes >>> will continue to be called claims, while event attributes (i.e. those >>> in an event payload) will be referred to as attributes. >>> >>> Additionally, the following terms are defined: >>> >>> 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. >> s1.3, CP discussion: I think this should mention 'notice mode' with a >> pointer >> to Section 2.4.1 where this mode is defined. >> >> s1.3, DBR discussion: Add a pointer to Section 2.4.1 where 'full mode' is >> defined. >> >> s1.3, Event Feed discussion: s/aka/equivalently/. I suggest the following >> alternative first sentence (I know what you mean by 'quality' but it takes >> some >> thinking about!): An Event Feed (equivalently Event Stream) is a logical >> connection between an Event Publisher and a client implementing the >> possibility >> that notification of resource state changes MAY be managed per receiving >> client. >> >> s1.3, SCIM Client discussion: Possibly add 'via one or more Event Feeds'? >> >> s2.1, uri item: A reference to Section 3.2 of RFC 7644 for the definition of >> resource type endpoint would help. >> >> s2.1, para 1, last sentence: Is this the 'Subject Identification' constraint >> in >> s3? Might be worth saying as there are several sub discussions in RFC 8417. >> >> s2.1, externalId and id items: Presumably these attributes share definitions >> with the same items in RFC 7463 Section 3.1. If so a reference would help. >> >> s2,1, "emails, username..." item: Are the allowed values here constrained to >> those defined in Section 4.1 of RFC 7463? Whether or not this is the case >> should be stated here. >> >> s2.2, data item: s/SCIM Bulk/the SCIM Bulk/ >> >> s2.2, txn item: s/is a SET defined claim/txn is a SET defined claim/ It may >> be >> worth mentioning that it has a STRING value. >> >> s2.2, txn item: I observe that the definitions of the txn and jti claims in >> Section 2.2 of RFC 8417 reverse the mandatoriness of txn and jti (txn >> optional >> and jti mandatory in RFC 8417). If this is fully intended, I think it would >> be >> good to emphasise the reversal. To relieve my curiosity, is there a good >> reason why this has been done assuming this *is* what was intended please? >> Possibly to do with the advent of the Set-txn HTTP response header? >> >> s2.2, 'attributes' item: I don't understand why the second sentence >> (starting >> "Values of...") is relevant (or correct here). The item appears to be an >> array >> of claim names. To clarify this s/array of attributes/array of names of >> attributes/ in any case. If the second sentence is in fact appropriate, then >> I >> think some explanation is needed and also s/path>/path/ - otherwise it should >> be deleted as the list of attribute names does not have any interest in the >> format of the individual claim values. >> >> s2.4.1, 3rd sentence: "final state" - Surely the set of values represents >> the >> 'current' set of values at the time the event occurred/was reported? Suggest >> s/final state/current state/ >> >> s2.4.1, 4th sentence: add '(see Figure 4)' for consistency with notice mode. >> >> s2.4.1, Figure 4 title: s/Example SCIM Create (Full)/Example SCIM Create >> Event >> (Full)/ (for consistency with Figure 5.) >> >> s2.4.1, last para: s/The event above/The example event shown in Figure 5/ >> (Both >> Figure 4 and Figure 5 are above). >> >> s2.4.3 and s2.4.4: It may be a bit nit picking but it would be good to >> indicate >> explicitly which figures are referred to in the introductory text of these >> two >> sections as in Section 2.4.2. >> >> s2.4.6, "minimal disclosure requirements": Firstly Section 2.4.5 says >> nothing >> explicitly about disclosure events. Secondly, what is meant by a disclosure >> event? There is no definition of this term. >> >> s2.5.1.1, para 2 and also in s3, None : For consistency with the title of >> Section 2.5.1 s/async SCIM request/asynchronous SCIM request/ >> >> s2.5.1.1, respond-async: This is defined in RFC 7240 (along with the Prefer >> header) and not RFC 9110. >> >> s2.5.1.1, respond-async: RFC 7240 provides the 'wait' preference allowing >> the >> server to decide whether to respond synchronously or asynchronously >> depending >> on expected response delay. Should this be honoured or MUST the server >> ignore the wait preference in SCIM cases as it is allowed to do? >> >> s2.5.1.1, Servicing of asynchronous requests by proxies: Does anything need >> to be said about this for the SCIM case? >> >> s2.5.1.1, Set-txn header (para after Figure 12): The specification needs an >> explicit definition of the Set-txn HTTP header. It appears here without any >> definition. This definition needs to be referenced in Section 6.1. >> >> s2.5.1.3, 2nd sentence: s/is the same a single/is the same as a single/ >> >> Appendix C: Should contain an RFC Editor note requesting the deletion of >> Appendix C before publication. >> >> Appendix D: Acknowledgements and authors addresses are normally sections in >> the >> body of the document. >> >> >> >> _______________________________________________ >> Gen-art mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
