Return-Path: X-Original-To: auth48archive@mail2.ietf.org Delivered-To: auth48archive@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DE938E98FF6B for ; Tue, 5 May 2026 16:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778023953; bh=JnObNcW1D5EOft6MNdWRLjMHr9F0Kx02uYFpcnOSNP0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=WST0S4Zl0VU5+6oMBa1tyKgr79UE8M81Zl4ZfFisy2NLGDJb/XWd4HpwM0LDC6gcO a4yZs2UTUZwOakm8LUFY6sbaQgeHyiu5pD7MlGi5ZNWCZoSH35ms0PA7TTeATjHQXb 2t/1H0ZmpKsaUnOk5S0ZxyDHleVw4a2Lq/JjziNg= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=independentid.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CROzG1xdTtMg for ; Tue, 5 May 2026 16:32:29 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2EF5AE98FD64 for ; Tue, 5 May 2026 16:31:01 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-c6e2355739dso2249895a12.2 for ; Tue, 05 May 2026 16:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid.com; s=google; t=1778023854; x=1778628654; darn=rfc-editor.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=Bp+NkTqns6bh5+MOOLbiiCFPtzC+m3acQuuRIhul/Cs=; b=SfCX5fI7Km4brwQ7m9K01QWxeylcJ0cjFwmJn04un06h0xTeSt45h4k/PvSd77lApC dDeADcN1VwsESlg60kuQJgiLM8zy2SF8//CQOFHbvRAEFJa+/npCwY5kKDg976V/wyPd 7KrqNOYw507WbCKlsqHsbog0PV3ybc7PG40H5JPdnI3AT7rroIBvBUcsfkPWoXYLhFfO 9t2SyhRls8IYRNH/NLkTkAgsgCJGao+RnQ3j9+gQKxm/XrLu6Y9DUQbdalPeqbT/qeex JM8S5lpCL9U/uCvU/aHfvueu5st0/mUfHJv/5LF3FnQNpgqleHpOIz+M1V2GTMwzVYFT Jkkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778023854; x=1778628654; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bp+NkTqns6bh5+MOOLbiiCFPtzC+m3acQuuRIhul/Cs=; b=JzYhL4LLGUWjaxe11b1zuIjg9fcNpl1jdTAEPa/7mWv4CuVXifCaepl5+0XTxMRa+o J/uXe0YgeeZZu5ZhIb8nF8mqEc7HFR7cWzAOy2Yx1Hi+311sv52OksteBQ287gjzIkhR b0WE51eKPFO5C9ZrxFnxkxAWpilKp7mlTCesGVqxm59IvO++CZt66Mdh3JSc9Gp3+tiM UCVX1sZziDJbp8T4WbWRT/VHGblYXm3LbVRWPFuCHvbPk5KNeAka4djDKtFqknzf4ngz HAlGLEZ/eTuuZMb1vTKPvqtcnYEOm5kUMv97VfV+qb5kzg2wnTJbzQxoNZ24TeqM9AUl tBzQ== X-Forwarded-Encrypted: i=1; AFNElJ9Ud81McD7C/SsbCNKButnVZjoRv1iTBjSwTbBAfPfQezOxsV5ZGGJ7F3yWmz3otpRoQbuZ6mxlrV8m5UNj@rfc-editor.org X-Gm-Message-State: AOJu0YxfjT3VugMe1II6SP+2ppLN45YzMtCL1NhO3R91Cl8loW/Y1uJN xD5zv7fy1aBP/PhtkImzPwUFZYif5z7HeCUHmwv79jfC6vA/14Br81ZThRctcMkpnJE= X-Gm-Gg: AeBDieuCkKPxiEYGpEZ7JS5pG3/kG7nrFOuy4HE1hT3dbVe2Sf6fXJLx0SDOkpeK5UY OnA04BrumUW3P1yeJVPStaPeqh/nDUJAFtDE7X6ct5kFh1u7kzqE2oaZJnKKK76265nphU/UwRq iu1TH6dLd6veV0YNHiE32cPYnpQKGAnDCjibP9u8qoHyV7FMwj9pdg+8+ymWhuzHXGHQJB+eMLf Sd9BGYTNs/5R78fwIpaK+ExnNUfZHtnaD45HmGQQu8hJhnMyBWPMoTl9/JiB9EIXGQW1kjj37mV H8Fpj+VPY1dB3DhJmZEp9bfSczhXdFdCV2oNUR9OtLroAKukzuNCtzSdaFChUzPIQMP+cr930XQ WTJdV3KVzrBkMxlb9s7fMEfal9gSQ1QzTnTsGz6GyV36SN1ZmxeOsYS+gACBQqv4WuFfNzxgAih SQ0DJwSa/0r4XBwHHoVULN1MytyDSpq9AI6jhHgjLWMvfmfpQQLkhvSt6RXIECy+95TBbwCHFUz x8= X-Received: by 2002:a05:6a20:7fa9:b0:39c:787:f196 with SMTP id adf61e73a8af0-3aa5a99f496mr871376637.16.1778023854203; Tue, 05 May 2026 16:30:54 -0700 (PDT) Received: from smtpclient.apple ([2001:569:7a96:bb00:5d15:8e23:ad88:2581]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-839682a4bffsm3168360b3a.56.2026.05.05.16.30.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2026 16:30:53 -0700 (PDT) From: Phillip Hunt Message-Id: <81B3B427-5545-4AC0-8520-DAB5DBB2621A@independentid.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DDFEB228-29CC-496C-982E-6F977D8AD44D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Date: Tue, 5 May 2026 16:30:42 -0700 In-Reply-To: To: Karen Moore , jennifer.winer=40workday.com@dmarc.ietf.org References: <20260501221703.8FD79315D02@rfcpa.rfc-editor.org> X-Mailer: Apple Mail (2.3864.500.181) Message-ID-Hash: 7W4X55W25XCXJNDGQWIR6JOD6WUGKICT X-Message-ID-Hash: 7W4X55W25XCXJNDGQWIR6JOD6WUGKICT X-MailFrom: phil.hunt@independentid.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: mike.kiser@sailpoint.com, Nancy Cam-Winget , jennifer.winer@workday.com, rfc-editor@rfc-editor.org, scim-ads@ietf.org, scim-chairs@ietf.org, lear@cisco.com, debcooley1@gmail.com, auth48archive@rfc-editor.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_questions_-_Re=3A_AUTH48=3A_RFC-to-be_9967_=3Cd?= =?utf-8?q?raft-ietf-scim-events-16=3E_for_your_review?= List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_DDFEB228-29CC-496C-982E-6F977D8AD44D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We also might want to change Jennifer=E2=80=99s email as it is bouncing.=20= Phil phil.hunt@independentid.com > On May 5, 2026, at 1:49=E2=80=AFPM, Karen Moore = wrote: >=20 > Hi Phil, >=20 > Thank you for your reply. We have updated our files accordingly. Note = that we have some additional questions. >=20 > 1) Please clarify if the column header in Table 1 (Section 7.4) = should be "Event URI=E2=80=9D, "Schema URI=E2=80=9D, or other. If you = feel that further explanation is needed, you can add text to the = Definitions section as you suggest or a note under Table 1. >=20 >> >=20 > 2) We have not made any updates yet to the case of the terminology in = question. We suggest going with lowercase to match RFCs 7643 and 7644; = however, this is author preference. Please discuss with your coauthors = and confirm if you would like to go with uppercase or lowercase and we = will make the updates. >=20 > 3) Thank you for providing the updated SVG figures. Regarding Figure = 21, we note that the SVG version in the html file contains a loop but = the ascii-art version in the txt file does not. Is this variance okay, = or should it be described in the running text or noted under the figure? >=20 > Also, in the box in the upper right corner, should "Co-op Action = Endpoint=E2=80=9D be =E2=80=9CCoord. Action Endpoint=E2=80=9D? >=20 > =E2=80=94Files=E2=80=94=20 >=20 > Note that it may be necessary for you to refresh your browser to view = the most recent version. Please review the document carefully to ensure = satisfaction as we do not make changes once it has been published as an = RFC. >=20 > Please contact us with any further updates or with your approval of = the document in its current form. We will await approvals from each = author prior to moving forward in the publication process. >=20 > Updated XML file: > https://www.rfc-editor.org/authors/rfc9967.xml >=20 > Updated output files: > https://www.rfc-editor.org/authors/rfc9967.txt > https://www.rfc-editor.org/authors/rfc9967.pdf > https://www.rfc-editor.org/authors/rfc9967.html >=20 > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9967-auth48diff.html > https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html (side by = side) >=20 > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9967-diff.html > https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by side) >=20 > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9967 >=20 > Best regards, >=20 > Karen Moore > RFC Production Center >=20 >=20 >> On May 3, 2026, at 1:25=E2=80=AFPM, Phillip Hunt = wrote: >>=20 >>=20 >> Thank you very much for the feedback! >>=20 >> My answers are included below. As I agree with only some subtle = changes, I will let you update the rfc editor version rather than = producing draft 17. >>=20 >> Please find attached 4 files for the 2 figures. I have attempted to = make them align. The contents should be paste-able directly in the = document xml >>=20 >> Let me know if there is anything else. >>=20 >> =E2=80=94> co-authors, please check as well per the instructions in = the previous email. >>=20 >> Phil >> phil.hunt@independentid.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On May 1, 2026, at 3:17=E2=80=AFPM, rfc-editor@rfc-editor.org wrote: >>>=20 >>> Authors, >>>=20 >>> While reviewing this document during AUTH48, please resolve (as = necessary) the following questions, which are also in the source file. >>>=20 >>> 1) =20 >>>=20 >> oik >>>=20 >>> 2) >>=20 >> No opinions. I thought RFC numbers not allowed in abstracts. = :) >>>=20 >>>=20 >>> 3) >> ok >>>=20 >>>=20 >>> 5) >>>=20 >> ok >>>=20 >>>=20 >>> 6) >> no objection >>>=20 >>>=20 >>> 7) >> ok >>>=20 >>>=20 >>> 8) >>=20 >> attributes in JWT and SCIM are case insensitive. But the case = as was written was consistent with RFC7643 (which is userName). I have = no objections either way. >>>=20 >>>=20 >>> 9) >>>=20 >>>=20 >> thanks. correct. >>=20 >>> 10) >>=20 >> Proposed: >>=20 >> If providing the exact date of each membership change is not = critical, consider >> using a PATCH to aggregate multiple membership changes into a single = event. >> >>>=20 >>>=20 >>> 13) =20 >> >> These are actually different uses. EventURIs are used in JWT not in = SCIM protocol itself. SCIM =E2=80=9CSchemas=E2=80=9D do appear in some = SCIM Events (e.g. urn:ietf:params:scim:event:prov:create:full has a = =E2=80=9Cdata=E2=80=9D element that contains schemas. (See Figure 4) >>=20 >> Not sure if we need better explanation somewhere such as definitions? >>=20 >>>=20 >>>=20 >>> 14) >>=20 >>>=20 >>>=20 >>> 16) >>>=20 >> I have made changes as follows: >> Figure 20: = = = = = = =20 >> - In-doc ASCII: replaced flow-chart style with sequence-diagram = version from figure20.txt (max 70 chars, all under 72) >> - In-doc SVG: "Client A" =E2=86=92 "SCIM Client A" to match the = standalone SVG and ASCII = = = = = =20 >> - Now all four sources (standalone SVG, standalone TXT, in-doc SVG, = in-doc ASCII) use identical participant names and the same = sequence-diagram visual style = = = = =20 >> = = = = = = Figure 21 (from previous turn): = = = = = = =20 >> - All four sources use "SCIM Client" / "SCIM Service Provider" / = "Event Receiver" / "Co-op Action Endpoint" in matching sequence-diagram = style =20 >>=20 >> For you edit see the files attached and replace in the XML sections = as appropriate. =EF=BF=BC=EF=BF=BC=EF=BF=BC=EF=BF=BC >>>=20 >>>=20 >>> 17) >>=20 >> ok >>>=20 >>>=20 >>> 19) >>=20 >> I am not aware of any issues according to the examples in the = links provided. >>>=20 >>>=20 >>> Thank you. >>>=20 >>> Karen Moore and Alice Russo >>> RFC Production Center >>>=20 >>>=20 >>> On May 1, 2026, rfc-editor@rfc-editor.org wrote: >>>=20 >>> *****IMPORTANT***** >>>=20 >>> Updated 2026/05/01 >>>=20 >>> RFC Author(s): >>> -------------- >>>=20 >>> Instructions for Completing AUTH48 >>>=20 >>> Your document has now entered AUTH48. Once it has been reviewed and=20= >>> approved by you and all coauthors, it will be published as an RFC. =20= >>> If an author is no longer available, there are several remedies=20 >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>=20 >>> You and you coauthors are responsible for engaging other parties=20 >>> (e.g., Contributors or Working Group) as necessary before providing=20= >>> your approval. >>>=20 >>> Planning your review=20 >>> --------------------- >>>=20 >>> Please review the following aspects of your document: >>>=20 >>> * RFC Editor questions >>>=20 >>> Please review and resolve any questions raised by the RFC Editor=20 >>> that have been included in the XML file as comments marked as=20 >>> follows: >>>=20 >>> >>>=20 >>> These questions will also be sent in a subsequent email. >>>=20 >>> * Changes submitted by coauthors=20 >>>=20 >>> Please ensure that you review any changes submitted by your=20 >>> coauthors. We assume that if you do not speak up that you=20 >>> agree to changes submitted by your coauthors. >>>=20 >>> * Content=20 >>>=20 >>> Please review the full content of the document, as this cannot=20 >>> change once the RFC is published. Please pay particular attention = to: >>> - IANA considerations updates (if applicable) >>> - contact information >>> - references >>>=20 >>> * Copyright notices and legends >>>=20 >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions=20 >>> (TLP =E2=80=93 https://trustee.ietf.org/license-info). >>>=20 >>> * Semantic markup >>>=20 >>> Please review the markup in the XML file to ensure that elements of =20= >>> content are correctly tagged. For example, ensure that =20= >>> and are set correctly. See details at=20 >>> . >>>=20 >>> * Formatted output >>>=20 >>> Please review the PDF, HTML, and TXT files to ensure that the=20 >>> formatted output, as generated from the markup in the XML file, is=20= >>> reasonable. Please note that the TXT will have formatting=20 >>> limitations compared to the PDF and HTML. >>>=20 >>>=20 >>> Submitting changes >>> ------------------ >>>=20 >>> To submit changes, please reply to this email using =E2=80=98REPLY = ALL=E2=80=99 as all=20 >>> the parties CCed on this message need to see your changes. The = parties=20 >>> include: >>>=20 >>> * your coauthors >>>=20 >>> * rfc-editor@rfc-editor.org (the RPC team) >>>=20 >>> * other document participants, depending on the stream (e.g.,=20 >>> IETF Stream participants are your working group chairs, the=20 >>> responsible ADs, and the document shepherd). >>>=20 >>> * auth48archive@rfc-editor.org, which is a new archival mailing = list=20 >>> to preserve AUTH48 conversations; it is not an active discussion=20= >>> list: >>>=20 >>> * More info: >>> = https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P= 8O4Zc >>>=20 >>> * The archive itself: >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>=20 >>> * Note: If only absolutely necessary, you may temporarily opt out=20= >>> of the archiving of messages (e.g., to discuss a sensitive = matter). >>> If needed, please add a note at the top of the message that you=20= >>> have dropped the address. When the discussion is concluded,=20 >>> auth48archive@rfc-editor.org will be re-added to the CC list = and=20 >>> its addition will be noted at the top of the message.=20 >>>=20 >>> You may submit your changes in one of two ways: >>>=20 >>> An update to the provided XML file >>> =E2=80=94 OR =E2=80=94 >>> An explicit list of changes in this format >>>=20 >>> Section # (or indicate Global) >>>=20 >>> OLD: >>> old text >>>=20 >>> NEW: >>> new text >>>=20 >>> You do not need to reply with both an updated XML file and an = explicit=20 >>> list of changes, as either form is sufficient. >>>=20 >>> We will ask a stream manager to review and approve any changes that = seem >>> beyond editorial in nature, e.g., addition of new text, deletion of = text,=20 >>> and technical changes. Information about stream managers can be = found in=20 >>> the FAQ. Editorial changes do not require approval from a stream = manager. >>>=20 >>>=20 >>> Approving for publication >>> -------------------------- >>>=20 >>> To approve your RFC for publication, please reply to this email = stating >>> that you approve this RFC for publication. Please use =E2=80=98REPLY = ALL=E2=80=99, >>> as all the parties CCed on this message need to see your approval. >>>=20 >>>=20 >>> Files=20 >>> ----- >>>=20 >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9967.xml >>> https://www.rfc-editor.org/authors/rfc9967.html >>> https://www.rfc-editor.org/authors/rfc9967.pdf >>> https://www.rfc-editor.org/authors/rfc9967.txt >>>=20 >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9967-diff.html >>> https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by = side) >>>=20 >>> Diff of the XML:=20 >>> https://www.rfc-editor.org/authors/rfc9967-xmldiff1.html >>>=20 >>>=20 >>> Tracking progress >>> ----------------- >>>=20 >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9967 >>>=20 >>> Please let us know if you have any questions. =20 >>>=20 >>> Thank you for your cooperation, >>>=20 >>> RFC Editor >>>=20 >>> -------------------------------------- >>> RFC9967 (draft-ietf-scim-events-16) >>>=20 >>> Title : SCIM Profile for Security Event Tokens >>> Author(s) : P. Hunt, Ed., N. Cam-Winget, M. Kiser, J. = Schreiber >>> WG Chair(s) : Nancy Cam-Winget >>> Area Director(s) : Deb Cooley, Christopher Inacio >>>=20 >>=20 >=20 --Apple-Mail=_DDFEB228-29CC-496C-982E-6F977D8AD44D Content-Type: multipart/mixed; boundary="Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D" --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We also might want to change = Jennifer=E2=80=99s email as it is bouncing. 

Phil
phil.hunt@independentid.com
<= div>





On May 5, 2026, at 1:49=E2=80=AFPM= , Karen Moore <kmoore@staff.rfc-editor.org> wrote:

Hi Phil,

Thank you = for your reply.  We have updated our files accordingly. Note that = we have some additional questions.

1)  Please clarify if the = column header in Table 1 (Section 7.4) should be "Event URI=E2=80=9D, = "Schema URI=E2=80=9D, or other.  If you feel that further = explanation is needed, you can add text to the Definitions section as = you suggest or a note under Table 1.

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

<PH> These are actually = different uses. EventURIs are used in JWT not
in SCIM protocol = itself.  SCIM =E2=80=9CSchemas=E2=80=9D do appear in some SCIM = Events
(e.g. urn:ietf:params:scim:event:prov:create:full has a = =E2=80=9Cdata=E2=80=9D element
that contains schemas.  (See = Figure 4)

Not sure if we need better explanation somewhere such = as definitions?
-->

2) We have not made any = updates yet to the case of the terminology in question. We suggest going = with lowercase to match RFCs 7643 and 7644; however, this is author = preference. Please discuss with your coauthors and confirm if you would = like to go with uppercase or lowercase and we will make the = updates.

3) Thank you for providing the updated SVG figures. = Regarding Figure 21, we note that the SVG version in the html file = contains a loop but the ascii-art version in the txt file does not. Is = this variance okay, or should it be described in the running text or = noted under the figure?

Also, in the box in the upper right = corner, should "Co-op Action Endpoint=E2=80=9D be =E2=80=9CCoord. Action = Endpoint=E2=80=9D?

=E2=80=94Files=E2=80=94

Note that it = may be necessary for you to refresh your browser to view the most recent = version. Please review the document carefully to ensure satisfaction as = we do not make changes once it has been published as an = RFC.

Please contact us with any further updates or with your = approval of the document in its current form.  We will await = approvals from each author prior to moving forward in the publication = process.

Updated XML file:
= https://www.rfc-editor.org/authors/rfc9967.xml

Updated output = files:
https://www.rfc-editor.org/authors/rfc9967.txt
= https://www.rfc-editor.org/authors/rfc9967.pdf
= https://www.rfc-editor.org/authors/rfc9967.html

Diff files = showing all changes made during AUTH48:
= https://www.rfc-editor.org/authors/rfc9967-auth48diff.html
= https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html (side by = side)

Diff files showing all changes:
= https://www.rfc-editor.org/authors/rfc9967-diff.html
= https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by = side)

For the AUTH48 status of this document, please see:
= https://www.rfc-editor.org/auth48/rfc9967

Best = regards,

Karen Moore
RFC Production = Center


On May 3, 2026, at = 1:25=E2=80=AFPM, Phillip Hunt <phil.hunt@independentid.com> = wrote:


Thank you very much for the feedback!

My = answers are included below.  As I agree with only some subtle = changes, I will let you update the rfc editor version rather than = producing draft 17.

Please find attached 4 files for the 2 = figures.  I have attempted to make them align.  The contents = should be paste-able directly in the document xml

Let me know if = there is anything else.

=E2=80=94> co-authors, please check as = well per the instructions in the previous = email.

Phil
phil.hunt@independentid.com





<= br>
On May 1, 2026, at 3:17=E2=80=AFPM, = rfc-editor@rfc-editor.org wrote:

Authors,

While reviewing = this document during AUTH48, please resolve (as necessary) the following = questions, which are also in the source file.

1) <!--[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
-->   

<PH> = oik

2) <!--[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.
-->

<PH>  No opinions. =  I thought RFC numbers not allowed in abstracts. =  :)


3) <!--[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...
=E2=80=94>

<PH> = ok

4) <!-- [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.
-->
<PH> ok


5) <!--[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].
-->

<PH> ok


6) <!--[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" = ...
-->
<PH> no objection


7) <!--[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.
-->
<PH> ok


8) <!-- [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"]
-->

<= PH>  attributes in JWT and SCIM are case insensitive. But the = case as was written was consistent with RFC7643 (which is userName). =   I have no objections either way.


9) <!--[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"].
-->


<PH> thanks. correct.

10) = <!--[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" =  
=E2=80=94

<PH> Just an example, = doesn=E2=80=99t matter.  The example in Figure 2 of RFC7643 has no = period.

11) <!--[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.
=E2=80=94>

<PH> How about "Async = SCIM Request With Prefer Header"

12) = <!--[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.
-->

<PH> = Proposed:

If providing the exact date of each membership change = is not critical, consider
using a PATCH to aggregate multiple = membership changes into a single event.
</PH>


13) <!-- [rfced] In Section 7.4, the header of = the first column in
Table 1 is "Event URI", but it is "Schema URI" in = the
"SCIM Event URIs" registry = <https://www.iana.org/assignments/scim/>.
Do you prefer to use = "Event URI" or "Schema URI"?  Note that we
will communicate any = changes to the registry to IANA.
--> =  
<PH>
These are actually different uses. = EventURIs are used in JWT not in SCIM protocol itself.  SCIM = =E2=80=9CSchemas=E2=80=9D do appear in some SCIM Events (e.g. = urn:ietf:params:scim:event:prov:create:full has a =E2=80=9Cdata=E2=80=9D = element that contains schemas.  (See Figure 4)

Not sure if = we need better explanation somewhere such as = definitions?



14) <!-- = [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. =
=E2=80=94>

<PH>  RFC8141 says = ASCII so this change ok

15) = <!--[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
vs. = https://www.rfc-editor.org/authors/rfc9967.txt)

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.]
-->



16) = <!--[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
vs. = https://www.rfc-editor.org/authors/rfc9967.txt)

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=3Dxyz vs. "Event SCIM:prov:<op>, id=3Dxyz"
=    [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.
-->

<PH>  I have made = changes as follows:
 Figure 20: =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;        
 - In-doc = ASCII: replaced flow-chart style with sequence-diagram version from = figure20.txt (max 70 chars, all under 72)
 - In-doc SVG: = "Client A" =E2=86=92 "SCIM Client A" to match the standalone SVG and = ASCII =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;
 - Now all four sources (standalone SVG, standalone TXT, = in-doc SVG, in-doc ASCII) use identical participant names and the same = sequence-diagram visual style =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;        
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;          Figure 21 = (from previous turn): =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =
 - All four sources use "SCIM Client" / "SCIM Service = Provider" / "Event Receiver" / "Co-op Action Endpoint" in matching = sequence-diagram style      

For you = edit see the files attached and replace in the XML sections as = appropriate.
= --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Disposition: inline; filename=figure21.svg Content-Type: image/svg+xml; x-unix-mode=0644; name="figure21.svg" Content-Transfer-Encoding: 7bit SCIM Client SCIM Service Provider Event Receiver ConCo-op Action Endpoint loop [1] SCIM Operation [2] SCIM Response [3] Event SCIM:prov:<op> id:xyz [4] SCIM GET <id> [5] Filtered Resource Response [6] Co-ordinated Action Receiver may accumulate events for periodic action. --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Disposition: attachment; filename=figure21.txt Content-Type: text/plain; x-unix-mode=0644; name="figure21.txt" Content-Transfer-Encoding: 7bit +-----------+ +---------------+ +-----------------+ +---------------+ |SCIM Client| | SCIM Service | | Event Receiver | | Co-op Action | | | | Provider | | | | Endpoint | +-----------+ +---------------+ +-----------------+ +---------------+ | | | | | [1] SCIM | | | | Operation | | | |--------------->| | | | | | | | [2] SCIM | | | | Response | | | |<---------------| | | | | | | | | [3] Event | | | | SCIM:prov: | | | | id:xyz | | | |- - - - - - - - - >| | | | | | | | | Note: Receiver | | | | may accumulate | | | | events for | | | | periodic action. | | | | | | | [4] SCIM GET | | | |<------------------| | | | | | | | [5] Filtered | | | | Resource | | | | Response | | | |------------------>| | | | | | | | | [6] Co-ordinated | | | | Action | | | |------------------>| | | | | v v v v --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Disposition: attachment; filename=figure20.txt Content-Type: text/plain; x-unix-mode=0644; name="figure20.txt" Content-Transfer-Encoding: 7bit +-------------+ +---------------------+ +------------------------+ |SCIM Client A| |SCIM Service Provider| |Service Provider Replica| +-------------+ +---------------------+ +------------------------+ | | | | [1] SCIM Operation | | |-------------------->| | | [2] SCIM Response | | |<--------------------| | | | | | | [3] Event SCIM:prov: | | | id:xyz | | |- - - - - - - - - - - - - >| | | | | | [4] Update local node |--+ | | | | | | |<-+ | | | v v v --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Disposition: inline; filename=figure20.svg Content-Type: image/svg+xml; x-unix-mode=0644; name="figure20.svg" Content-Transfer-Encoding: 7bit SCIM Client A SCIM Service Provider Service Provider Replica [1] SCIM Operation [2] SCIM Response [3] Event SCIM:prov:<op> id:xyz [4] Update local node --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


17) <!-- [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.
=E2=80=94>

<PH> =   

All of the figures with JSON in them should be = changed to <sourcecode type=3D=E2=80=9Cjson=E2=80=9D>
- Figures = 1 through 19

Figure 20 and 21 are artwork = AFAIK.


18) <!-- [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=E2=80=9D?]

<PH>  Thanks. Good = catch.  I was attempting to follow the practice of terminology e.g. = SHOULD vs should.

Lower case is appropriate when using it in = general langauge.  When referring to the defined thing or in = heading I believe proper case is appropriate.  

E.g. The = Event Feed vs passing events to an event feed.

Thoughts?  I = am ok proper casing everything if you prefer.

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=E2=80=9D.]

<PH> Drop service and just = use HTTP endpoint

HTTP Status 202 = (Accepted) vs.
HTTP Status 202 Accepted vs.
HTTP 202 = Accepted
  Note: Perhaps (to match usage in RFC 7644):
=     HTTP status code 202 = (Accepted)

<PH> Please = match

JSON Web Token vs. JSON = token

<PH> Use JSON Web = 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)

<PH> I believe this is an artificat of = changing IETF styles over time. During the writing of 7644 they didn=E2=80= =99t want capitalization.

Similar to above (regarding is it a = term or plain language).  I am ok with going either with proper = case =E2=80=9Cthings=E2=80=9D or the =E2=80=9CSCIM client=E2=80=9D = approach defpending on your current style guide.
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

ok


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.)


yes

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.
-->

<PH> ok


19) <!-- [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)
=E2=80=94>

<PH> = thanks

20) <!-- [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.
-->

<PH> I am not aware of any = issues according to the examples in the links provided.


Thank you.

Karen Moore and Alice = Russo
RFC Production Center


On May 1, 2026, = rfc-editor@rfc-editor.org = wrote:

*****IMPORTANT*****

Updated 2026/05/01

RFC = Author(s):
--------------

Instructions for Completing = AUTH48

Your document has now entered AUTH48.  Once it has = been reviewed and
approved by you and all coauthors, it will be = published as an RFC.  
If an author is no longer available, = there are several remedies
available as listed in the FAQ = (https://www.rfc-editor.org/faq/).

You and you coauthors are = responsible for engaging other parties
(e.g., Contributors or = Working Group) as necessary before providing
your = approval.

Planning your review =
---------------------

Please review the following aspects of = your document:

*  RFC Editor questions

Please review = and resolve any questions raised by the RFC Editor
that have been = included in the XML file as comments marked as
follows:

= <!-- [rfced] ... -->

These questions will also be sent in = a subsequent email.

*  Changes submitted by coauthors =

Please ensure that you review any changes submitted by your =
coauthors.  We assume that if you do not speak up that you =
agree to changes submitted by your coauthors.

* =  Content

Please review the full content of the document, = as this cannot
change once the RFC is published.  Please pay = particular attention to:
- IANA considerations updates (if = applicable)
- contact information
- references

* =  Copyright notices and legends

Please review the copyright = notice and legends as defined in
RFC 5378 and the Trust Legal = Provisions
(TLP =E2=80=93 = https://trustee.ietf.org/license-info).

*  Semantic = markup

Please review the markup in the XML file to ensure that = elements of  
content are correctly tagged.  For example, = ensure that <sourcecode>
and <artwork> are set = correctly.  See details at
= <https://authors.ietf.org/rfcxml-vocabulary>.

* =  Formatted output

Please review the PDF, HTML, and TXT = files to ensure that the
formatted output, as generated from the = markup in the XML file, is
reasonable.  Please note that the = TXT will have formatting
limitations compared to the PDF and = HTML.


Submitting changes
------------------

To = submit changes, please reply to this email using =E2=80=98REPLY ALL=E2=80=99= as all
the parties CCed on this message need to see your changes. = The parties
include:

*  your coauthors

* =  rfc-editor@rfc-editor.org (the RPC team)

*  other = document participants, depending on the stream (e.g.,
=    IETF Stream participants are your working group = chairs, the
   responsible ADs, and the document = shepherd).

*  auth48archive@rfc-editor.org, which is a new = archival mailing list
   to preserve AUTH48 = conversations; it is not an active discussion
=    list:

  *  More info:
=      https://mailarchive.ietf.org/arch/msg/ietf-a= nnounce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

  *  The = archive itself:
=      https://mailarchive.ietf.org/arch/browse/aut= h48archive/

  *  Note: If only absolutely = necessary, you may temporarily opt out
=      of the archiving of messages (e.g., to = discuss a sensitive matter).
     If = needed, please add a note at the top of the message that you
=      have dropped the address. When the = discussion is concluded,
=      auth48archive@rfc-editor.org will be = re-added to the CC list and
     its = addition will be noted at the top of the message.

You may submit = your changes in one of two ways:

An update to the provided XML = file
=E2=80=94 OR =E2=80=94
An explicit list of changes in this = format

Section # (or indicate Global)

OLD:
old = text

NEW:
new text

You do not need to reply with both = an updated XML file and an explicit
list of changes, as either form = is sufficient.

We will ask a stream manager to review and approve = any changes that seem
beyond editorial in nature, e.g., addition of = new text, deletion of text,
and technical changes.  Information = about stream managers can be found in
the FAQ.  Editorial = changes do not require approval from a stream = manager.


Approving for = publication
--------------------------

To approve your RFC for = publication, please reply to this email stating
that you approve this = RFC for publication.  Please use =E2=80=98REPLY ALL=E2=80=99,
as = all the parties CCed on this message need to see your = approval.


Files
-----

The files are available = here:
https://www.rfc-editor.org/authors/rfc9967.xml
= https://www.rfc-editor.org/authors/rfc9967.html
= https://www.rfc-editor.org/authors/rfc9967.pdf
= https://www.rfc-editor.org/authors/rfc9967.txt

Diff file of the = text:
https://www.rfc-editor.org/authors/rfc9967-diff.html
= https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by = side)

Diff of the XML:
= https://www.rfc-editor.org/authors/rfc9967-xmldiff1.html


Tracki= ng progress
-----------------

The details of the AUTH48 status = of your document are here:
= https://www.rfc-editor.org/auth48/rfc9967

Please let us know if = you have any questions.  

Thank you for your = cooperation,

RFC = Editor

--------------------------------------
RFC9967 = (draft-ietf-scim-events-16)

Title =            : SCIM = Profile for Security Event Tokens
Author(s) =        : P. Hunt, Ed., N. Cam-Winget, = M. Kiser, J. Schreiber
WG Chair(s)      : = Nancy Cam-Winget
Area Director(s) : Deb Cooley, Christopher = Inacio



<= /div>
= --Apple-Mail=_E48053AB-34EB-44A7-9C83-47F892455B1D-- --Apple-Mail=_DDFEB228-29CC-496C-982E-6F977D8AD44D--