Re: [auth48] AUTH48: RFC-to-be 9396 <draft-ietf-oauth-rar-23> for your review

[Justin Richer <[e-mail]>]

The changes look good to me.  I approve this RFC for publication.

Thank you, Brian, for spearheading the effort of these last few changes, and thanks to the RFC Editor team for the clean-up and polish!

 — Justin

> On May 15, 2023, at 5:32 PM, Alice Russo <[e-mail]> wrote:
> 
> Brian,
> 
> Yes, correct. We've recorded your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9396) and await word from your coauthors.
> 
> RFC Editor/ar
> 
>> On May 15, 2023, at 11:44 AM, Brian Campbell <[e-mail]> wrote:
>> 
>> You needed that explicit "I approve this RFC for publication," right? And also need it from the other authors? 
>> 
>> On Mon, May 15, 2023 at 12:40 PM Brian Campbell <[e-mail]> wrote:
>> Thanks Alice,
>> 
>> It all looks good to me now. I approve this RFC for publication. 
>> 
>> 
>> On Mon, May 15, 2023 at 12:32 PM Alice Russo <[e-mail]> wrote:
>> Brian,
>> 
>> Indeed; my mistake. Updated; the files are in the same locations as below (please refresh).
>> 
>> RFC Editor/ar
>> 
>>> On May 15, 2023, at 11:26 AM, Brian Campbell <bcampbell=[e-mail]> wrote:
>>> 
>>> Thanks Alice,
>>> 
>>> I notice that the hyphen that you'd removed and I mistakenly put back is still in the document - "only previously-approved locations" at https://www.rfc-editor.org/authors/rfc9396.html#section-6.1-8.3 - should that be changed to "only previously approved locations? Sorry to bring up a minor thing but it was an RFC Editor suggestion that I undid. 
>>> 
>>> 
>>> 
>>> On Fri, May 12, 2023 at 3:11 PM Alice Russo <[e-mail]> wrote:
>>> Brian,
>>> 
>>> Thank you for your reply. One update was made per your reply to #3; the revised files are here (please refresh):
>>>  https://www.rfc-editor.org/authors/rfc9396.html
>>>  https://www.rfc-editor.org/authors/rfc9396.txt
>>>  https://www.rfc-editor.org/authors/rfc9396.pdf
>>>  https://www.rfc-editor.org/authors/rfc9396.xml
>>> 
>>> This diff file shows all changes from the approved I-D:
>>>  https://www.rfc-editor.org/authors/rfc9396-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9396-rfcdiff.html (side by side)
>>> 
>>> This diff file shows the changes made during AUTH48 thus far:
>>>  https://www.rfc-editor.org/authors/rfc9396-auth48diff.html
>>>  https://www.rfc-editor.org/authors/rfc9396-auth48rfcdiff.html (side by side)
>>> 
>>> This diff file shows only the most recent change:
>>>  https://www.rfc-editor.org/authors/rfc9396-lastrfcdiff.html (side by side)
>>> 
>>> Re: #1 (handling of authorization_details)
>>>> Yes, that's an accurate summary. I'd happily go with other changes or approaches, if you believe it could be improved. But that does capture what I tried to do to be more consistent with treatment of the term. 
>>> 
>>> Ack; it seems fine to proceed with the current approach. 
>>> 
>>> We will wait to hear from you again and from your coauthors
>>> before continuing the publication process. This page shows 
>>> the AUTH48 status of your document:
>>>  https://www.rfc-editor.org/auth48/rfc9396
>>> 
>>> Thank you.
>>> RFC Editor/ar
>>> 
>>>> On May 10, 2023, at 7:47 AM, Brian Campbell <bcampbell=[e-mail]> wrote:
>>>> 
>>>> Thanks Alice, replies are inline below this time... 
>>>> 
>>>> On Tue, May 9, 2023 at 4:57 PM Alice Russo <[e-mail]> wrote:
>>>> Brian,
>>>> 
>>>> Thank you for your reply and for providing the updated XML file. Please see the followups below. The revised files are here (please refresh):
>>>>  https://www.rfc-editor.org/authors/rfc9396.html
>>>>  https://www.rfc-editor.org/authors/rfc9396.txt
>>>>  https://www.rfc-editor.org/authors/rfc9396.pdf
>>>>  https://www.rfc-editor.org/authors/rfc9396.xml
>>>> 
>>>> This diff file shows all changes from the approved I-D:
>>>>  https://www.rfc-editor.org/authors/rfc9396-diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9396-rfcdiff.html (side by side)
>>>> 
>>>> This diff file shows the changes made during AUTH48 thus far:
>>>>  https://www.rfc-editor.org/authors/rfc9396-auth48diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9396-auth48rfcdiff.html (side by side)
>>>> 
>>>> 1) Re: #13a (handing of authorization_details), to confirm - is this an accurate summary of your decisions?
>>>> - In running text, use <tt>, e.g., <tt>authorization_details</tt> 
>>>> - In figure titles, use quotation marks only, e.g., "authorization_details"
>>>> - When the term appears without an underscore, no <tt> and no quotation marks. (see the titles of Figures 22 and 23, Sections 2.1, 6.1, 7.1, and 11.1)
>>>> 
>>>> Yes, that's an accurate summary. I'd happily go with other changes or approaches, if you believe it could be improved. But that does capture what I tried to do to be more consistent with treatment of the term. 
>>>> 
>>>> 
>>>> 
>>>> 2) Section 6.1: FYI, we removed the hyphen in "previously-approved" because it is unnecessary. More info from The Chicago Manual of Style (CMOS) is pasted below.
>>>> 
>>>> Sorry about that, I got somewhat mixed up between the original and suggested text and mistakenly re-added that hyphen when making other changes to that line. 
>>>> 
>>>> 
>>>> 
>>>> 3) Section 6.1: May the term "actions value" be used for both instances within this sentence?
>>>> 
>>>> Current:
>>>>   For example, the value of an actions could subsume
>>>>   the rights associated with another actions value.
>>>> 
>>>> Perhaps:
>>>>   For example, an actions value could subsume
>>>>   the rights associated with another actions value.
>>>> 
>>>> Yes, please make that change. Sorry, my edits attempting to fix singular/plural variances in a few terms in <tt>s went a little astray there. 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> We will wait to hear from you again and from your coauthors
>>>> before continuing the publication process. This page shows 
>>>> the AUTH48 status of your document:
>>>>  https://www.rfc-editor.org/auth48/rfc9396
>>>> 
>>>> Thank you.
>>>> RFC Editor/ar
>>>> --
>>>> 
>>>>> From CMOS (17th edition):
>>>> 
>>>> 7.86: Adverbs ending in “ly”
>>>> 
>>>> Compounds formed by an adverb ending in ly plus an adjective or participle (such as largely irrelevant or smartly dressed) are not hyphenated either before or after a noun, since ambiguity is virtually impossible. (The ly ending with adverbs signals to the reader that the next word will be another modifier, not a noun.)
>>>> 
>>>>> On May 9, 2023, at 7:54 AM, Brian Campbell <bcampbell=[e-mail]> wrote:
>>>>> 
>>>>> Thanks RFC Editor(s), 
>>>>> 
>>>>> The attached XML file is an update to the provided XML in the AUTH48 email. I've endeavored to address the questions/comments/suggestions (as necessary and as best I could) with editorial updates and removal of the associated <!-- [rfced] ... --> comment elements.  
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, May 5, 2023 at 11:13 PM <[e-mail]> wrote:
>>>>> Authors,
>>>>> 
>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>> 
>>>>> 1) <!-- [rfced] For clarity and to avoid subject/verb confusion, may this
>>>>> sentence be rephrased as follows?
>>>>> 
>>>>> Original:
>>>>>   Interpretation of the value of the type parameter, and the object
>>>>>   fields that the type parameter allows, is under the control of the
>>>>>   AS.
>>>>> 
>>>>> Perhaps:
>>>>>   The AS controls the interpretation of the value of the type parameter 
>>>>>   as well as the object fields that the type parameter allows.
>>>>> 
>>>>> Or:
>>>>>   The AS controls the interpretation of a) the value of the type 
>>>>>   parameter and b) the object fields that the type parameter allows.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 2) <!-- [rfced] To match subsequent text, may we update "reading 
>>>>> the photos and writing the contacts" as follows?
>>>>> 
>>>>> Original:
>>>>>   If this request is granted, the client
>>>>>   would assume it would be able to use any combination of rights
>>>>>   defined by the API, such as reading the photos and writing the
>>>>>   contacts.
>>>>> 
>>>>> Perhaps:
>>>>>   If this request is granted, the client
>>>>>   would assume it would be able to use any combination of rights
>>>>>   defined by the API, such as read access to the photos and write 
>>>>>   access to the contacts.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 3) <!-- [rfced] There are two instances in this document where a list is
>>>>> introduced with "the following steps". Should the steps be numbered?
>>>>> 
>>>>> Original (Section 6.1):
>>>>> 
>>>>>   To make a comparison in this instance, the AS
>>>>>   would perform the following steps:
>>>>> 
>>>>>   *  compare that the authorization code issued in the previous step
>>>>>      contains an authorization details object of type
>>>>>      account_information
>>>>>   *  compare whether the approved list of actions contains
>>>>>      list_account, and
>>>>>   *  whether the locations value includes only previously-approved
>>>>>      locations.
>>>>> 
>>>>> Original (Section 11.1):
>>>>>   Using authorization details in a certain deployment will require the
>>>>>   following steps:
>>>>> 
>>>>>   *  Define authorization details types
>>>>>   *  Publish authorization details types in the OAuth server metadata
>>>>>   *  Determine how authorization details are shown to the user in the
>>>>>      user consent prompt
>>>>>   *  (if needed) Enrich authorization details in the user consent
>>>>>      process (e.g. add selected accounts or set expirations)
>>>>>   *  (if needed) Determine how authorization details are reflected in
>>>>>      access token content or introspection responses
>>>>>   *  Determine how the resource server(s) process(s) the authorization
>>>>>      details or token data derived from authorization details
>>>>>   *  (if needed) Entitle clients to use certain authorization details
>>>>>      types
>>>>> -->
>>>>> 
>>>>> 
>>>>> 4) <!-- [rfced] Please review if "compare" should be replaced with "verify" 
>>>>> in this list, as "compare" typically indicates that two items are being
>>>>> compared to each other. Also, to make this list parallel, what verb may
>>>>> be added for the last bullet point (e.g., verify)?
>>>>> 
>>>>> Original:
>>>>>   To make a comparison in this instance, the AS
>>>>>   would perform the following steps:
>>>>> 
>>>>>   *  compare that the authorization code issued in the previous step
>>>>>      contains an authorization details object of type
>>>>>      account_information
>>>>>   *  compare whether the approved list of actions contains
>>>>>      list_account, and
>>>>>   *  whether the locations value includes only previously-approved
>>>>>      locations.
>>>>> 
>>>>> Perhaps:
>>>>>   To make a comparison in this instance, the AS
>>>>>   would perform the following steps:
>>>>> 
>>>>>   *  verify that the authorization code issued in the previous step
>>>>>      contains an authorization details object of type,
>>>>>      account_information
>>>>>   *  verify whether the approved list of actions contains
>>>>>      list_account, and
>>>>>   *  verify whether the locations value includes only previously approved
>>>>>      locations.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 5) <!-- [rfced] Please clarify the sentence fragment ("If that client 
>>>>> is then granted such admin privileges to the API"), which is 
>>>>> the lead-in text for Figure 13. (The preceding sentence is 
>>>>> included for context.)
>>>>> 
>>>>> Original:
>>>>>   This same API could be designed with a possible value for privileges
>>>>>   of admin, used in this example to denote that the resulting token is
>>>>>   allowed to perform any functions on the resources.  If that client is
>>>>>   then granted such admin privileges to the API:
>>>>> 
>>>>> Perhaps:
>>>>>   [...] If that client is granted such admin privileges to the API,
>>>>>   a request for admin access would be as follows:
>>>>> -->
>>>>> 
>>>>> 
>>>>> 6) <!--[rfced] FYI, the spelling has been corrected here; please let us know
>>>>> if this is not correct.
>>>>> 
>>>>> Original: payment_iniation
>>>>> Current:  payment_initiation
>>>>> -->
>>>>> 
>>>>> 
>>>>> 7) <!-- [rfced] Please review the "type" attribute of each sourcecode element 
>>>>> in the XML file to ensure correctness. If the current list of preferred
>>>>> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
>>>>> does not contain an applicable type, then feel free to let us know.  
>>>>> Also, it is acceptable to leave the "type" attribute not set.  
>>>>> (e.g., for Figures 15 and 17, would type="http-message" be accurate?)
>>>>> 
>>>>> In addition, review each artwork element. Specifically,
>>>>> should any artwork element be tagged as sourcecode or another
>>>>> element? 
>>>>> -->
>>>>> 
>>>>> 
>>>>> 8) <!--[rfced] Should "authorization detail parameter" (one instance within
>>>>> this document) be "authorization_details parameter" to match other usage
>>>>> within this document?
>>>>> 
>>>>> Original:
>>>>>   In that example, the requested authorization detail parameter might
>>>>>   look like the following. 
>>>>> -->
>>>>> 
>>>>> 
>>>>> 9) <!-- [rfced] For clarity, may we update the definition as follows?
>>>>> 
>>>>> Original:
>>>>>   *  sub: conveys the user on which behalf the client is asking for
>>>>>      payment initiation
>>>>> 
>>>>> Perhaps:
>>>>>   sub: indicates the user for which the client is asking for 
>>>>>      payment initiation.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 10) <!-- [rfced] FYI, this use of the subjunctive may trip up readers; we have
>>>>> rephrased as follows.  Please review and let us know if you prefer otherwise.
>>>>> 
>>>>> Original:
>>>>>   This specification
>>>>>   makes no assumption that a type value point to a machine-readable
>>>>>   schema format, or that any party in the system (such as the client,
>>>>>   AS, or RS) dereference or process the contents of the type field in
>>>>>   any specific way.
>>>>> 
>>>>> Current:
>>>>>   This specification 
>>>>>   makes no assumption that a type value would point to a machine-readable 
>>>>>   schema format or that any party in the system (such as the client, 
>>>>>   AS, or RS) would dereference or process the contents of the type 
>>>>>   field in any specific way.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 11) <!-- [rfced] The provided URL redirects to
>>>>> https://cloudsignatureconsortium.org/. May we update to the URL below?
>>>>> Note: "2019/07" is changed to "2020/01".
>>>>> 
>>>>> Original:
>>>>>   [CSC]      Consortium, C. S., "Architectures and protocols for remote
>>>>>              signature applications", 1 June 2019,
>>>>>              <https://cloudsignatureconsortium.org/wp-
>>>>>              content/uploads/2019/07/CSC_API_V1_1.0.4.0.pdf>.
>>>>> 
>>>>> Perhaps:
>>>>>   [CSC]      Cloud Signature Consortium, "Architectures and protocols for 
>>>>>              remote signature applications", June 2019,
>>>>>              <https://cloudsignatureconsortium.org/wp-
>>>>>              content/uploads/2020/01/CSC_API_V1_1.0.4.0.pdf>.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 12) <!--[rfced] Will "sign doc endpoint" be clear to the reader?
>>>>> Does it mean "signature document endpoint"?
>>>>> 
>>>>> Original:
>>>>>   The client
>>>>>   uses the access token issued as a result of the process to call the
>>>>>   sign doc endpoint at the respective signing service to actually
>>>>>   create the signature. 
>>>>> -->
>>>>> 
>>>>> 
>>>>> 13) <!-- [rfced] Please review uses of quotation marks throughout the document
>>>>> with the following in mind.  If you prefer to make these changes to the
>>>>> XML file yourself instead of describing them via email, please use this
>>>>> file: https://www.rfc-editor.org/authors/rfc9396.xml
>>>>> 
>>>>> a) The text rendering of the <tt> element was changed in Sept. 2021 (xml2rfc
>>>>> release 3.10.0). <tt> no longer yields quotation marks in the text rendering.
>>>>> This change is especially problematic for figure, table, and section titles
>>>>> where the terms in <tt> appear in lowercase while the rest of the title will
>>>>> appear using initial capitalization.  For example:
>>>>> 
>>>>> Original:
>>>>>       Figure 12: Example for authorization_details requesting "read"
>>>>>                             access to an API.
>>>>> Current:
>>>>>       Figure 12: Example of authorization_details Requesting "read"
>>>>>                             Access to an API
>>>>> Perhaps:
>>>>>       Figure 12: Example of "authorization_details" Requesting "read"
>>>>>                             Access to an API
>>>>> 
>>>>> Some of the terms that appear in <tt> also appear in the text using quotes in
>>>>> other places.  We suggest reviewing terms in <tt> or quotes and ensuring that
>>>>> their use is helpful to the reader and is consistent throughout the document.
>>>>> 
>>>>> b) We noticed that some of the terms in <tt> have variances in
>>>>> singular/plural.  Please review and let us know if any updates are necessary.
>>>>> 
>>>>> action vs. actions
>>>>> datatype vs. datatypes
>>>>> -->
>>>>> 
>>>>> 
>>>>> 14) <!-- [rfced] Terminology
>>>>> 
>>>>> a) Please review usage of authorization_details vs. authorization details
>>>>> and let us know any updates. Are they used as you intended?
>>>>> 
>>>>> We also see this term associated with several different concepts (parameter
>>>>> vs. request parameter vs. type vs. array vs. authorization request parameter
>>>>> vs. structure vs. type value vs. token request parameter vs. request
>>>>> vs. object vs. information vs. member). Will it be clear to readers how 
>>>>> this term is being used? How may usage of this term be more consistent 
>>>>> throughout the document?
>>>>> 
>>>>> For example, regarding usage in the figure titles:
>>>>> "authorization_details" (with underscore) is used in most figure titles,
>>>>> except Figures 22 and 23, which use "authorization details" (no underscore).
>>>>> Is this intentional?
>>>>> 
>>>>> b) Similarly, please review usage of these terms, which seem to 
>>>>> appear inconsistently in the document.
>>>>> 
>>>>>   authorization code vs. authorization_code
>>>>>   authorization details object vs. authorization_details object
>>>>>   read access vs. "read" Access
>>>>>   write access vs. "write" Access
>>>>>   scope parameter vs. "scope" Parameter (Section 3.1)
>>>>>   resource parameter vs. "resource" Parameter (Section 3.2)
>>>>>   Token Introspection responses vs. token introspection responses
>>>>> 
>>>>> 
>>>>> c) What does "RP" stand for here? 
>>>>> 
>>>>> Original:
>>>>>   Note: locations specifies the location of the userinfo endpoint since
>>>>>   this is the only place where an access token is used by a client (RP)
>>>>>   in OpenID Connect to obtain claims.
>>>>> 
>>>>> 
>>>>> d) For the acronyms AS and RS, sometimes the acronym is used and sometimes
>>>>> the expansion is used throughout the document. May we only expand the
>>>>> acronyms on first usage and use the acronym in all subsequent instances?
>>>>> 
>>>>> 
>>>>> e) May we capitalize "ID" in this term (two instances)?
>>>>> 
>>>>>   user id
>>>>> -->
>>>>> 
>>>>> 
>>>>> 15) <!-- [rfced] Please review whether any of the notes in this document
>>>>> should be in the <aside> element. It is defined as "a container for 
>>>>> content that is semantically less important or tangential to the 
>>>>> content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>>> -->
>>>>> 
>>>>> 
>>>>> 16) <!-- [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.
>>>>> 
>>>>> Note that our script did not flag any words in particular, but this should 
>>>>> still be reviewed as a best practice.
>>>>> -->
>>>>> 
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor/st/ar
>>>>> 
>>>>> 
>>>>> On May 5, 2023, [e-mail] wrote:
>>>>> 
>>>>> *****IMPORTANT*****
>>>>> 
>>>>> Updated 2023/05/05
>>>>> 
>>>>> 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 – 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 ‘REPLY ALL’ as all 
>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>> include:
>>>>> 
>>>>>  *  your coauthors
>>>>> 
>>>>>  *  [e-mail] (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).
>>>>> 
>>>>>  *  [e-mail], 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-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>> 
>>>>>    *  The archive itself:
>>>>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>> 
>>>>>    *  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, 
>>>>>       [e-mail] 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
>>>>> — OR —
>>>>> 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 ‘REPLY ALL’,
>>>>> 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/rfc9396.xml
>>>>>  https://www.rfc-editor.org/authors/rfc9396.html
>>>>>  https://www.rfc-editor.org/authors/rfc9396.pdf
>>>>>  https://www.rfc-editor.org/authors/rfc9396.txt
>>>>> 
>>>>> Diff file of the text:
>>>>>  https://www.rfc-editor.org/authors/rfc9396-diff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9396-rfcdiff.html (side by side)
>>>>> 
>>>>> Diff of the XML: 
>>>>>  https://www.rfc-editor.org/authors/rfc9396-xmldiff1.html
>>>>> 
>>>>> 
>>>>> Tracking progress
>>>>> -----------------
>>>>> 
>>>>> The details of the AUTH48 status of your document are here:
>>>>>  https://www.rfc-editor.org/auth48/rfc9396
>>>>> 
>>>>> Please let us know if you have any questions.  
>>>>> 
>>>>> Thank you for your cooperation,
>>>>> 
>>>>> RFC Editor
>>>>> 
>>>>> --------------------------------------
>>>>> RFC9396 (draft-ietf-oauth-rar-23)
>>>>> 
>>>>> Title            : OAuth 2.0 Rich Authorization Requests
>>>>> Author(s)        : T. Lodderstedt, J. Richer, B. Campbell
>>>>> WG Chair(s)      : Hannes Tschofenig, Rifaat Shekh-Yusef
>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
>>>>> 
>>>>> 
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<rfc9396.xml>
>>>> 
>>>> 
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>>> 
>>> 
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>> 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>