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

Brian Campbell <bcampbell@pingidentity.com> Mon, 15 May 2023 18:40 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7965C1DF991 for <auth48archive@ietfa.amsl.com>; Mon, 15 May 2023 11:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN-miBVT45KW for <auth48archive@ietfa.amsl.com>; Mon, 15 May 2023 11:40:50 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489D4C1DF98F for <auth48archive@rfc-editor.org>; Mon, 15 May 2023 11:40:50 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-64a9335a8e7so23088849b3a.0 for <auth48archive@rfc-editor.org>; Mon, 15 May 2023 11:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1684176050; x=1686768050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IvqTjuG/eqAeaQCkCV+HgRc7yYEBFUwg6i3nLOGjN5w=; b=bwbD9VxhXmwK58dU23wfNvR8QivxqW9mPykR3gebs/V90J4d4cNOtr+PabArd8eV7j ThbL7j/rNB/AY62FXo+SdVC5gKSx1ktvTLEHbqsoouxFBSwU3b4zGPJGCBYIXRRMVWWu hMTwnyRKmNetnce0qJ/Ag+my9Bxr2pQnvU/wvOwocA0hQ2M38CaBDRScFCJksFMBi16G 4tkcpn5Wu+AR1hE+L604uaTMrQ7KcwcTAGQECrBnyUd0ihxn7Ku8oO1Cl4GTkIrcjSy8 qcYUGMFxPhB4LNpYn1YjzuhLw7+ALqUBREPne2tLdwUeg01wRImVgNTuxNzSPse+NFpt o68A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684176050; x=1686768050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IvqTjuG/eqAeaQCkCV+HgRc7yYEBFUwg6i3nLOGjN5w=; b=NdGGhY0DuYg0TlxfN7JGQ52Wb9fbFEQ7bX6OZ4KrMagKwfeZ6NpIxBFUwtdmy/vRNa 6/c1eRErMMsBFzNqZNyl3tDL1uXnoVuLfWZM/XSERk19LWGJmWJwBxHX9dIp5VyWZacA JbG2DZDWJ0/tLLzFAeWEDKhpIQgvS9oRdMRwIcl11tmf0Ml3B/jEe3VyftcEfCMSrGBU 5Mjx8sIpjqFwUCseLF+QXAQUihuuIUy1gRqEd7cgVrPoDqoxswDgXxrLDvRPNF0xRVyo MCpt/Spfi3czVeUr6pQLQLIMlSqnQit/CmQc7cmphKjU+tc/3fdNZse/y2HwITafENr6 AS/w==
X-Gm-Message-State: AC+VfDy3HHBEHZ8TPBq2v/0UqxoTsYP+Nq7TWuFP+6EnR7TEA4GupCVT rk1xDDaWHc0r+WbXlYR4EtDzZhlY4L99TszlS/bYd+FUbliiQ/4bekwEL8vwYGewnY4gNfgkTk1 JQO9rLRZfHUsiS63zqNyO0VjTLjufMRCI
X-Google-Smtp-Source: ACHHUZ5pP0EDd32syUpwsX/ertVT/g47GbQOujStwrviQBqXklikMycIS2BA+0NsvssWg12TE/ojmqiWeCpOth03DBQ=
X-Received: by 2002:a17:90a:2f05:b0:250:3652:55bd with SMTP id s5-20020a17090a2f0500b00250365255bdmr40082606pjd.14.1684176049456; Mon, 15 May 2023 11:40:49 -0700 (PDT)
MIME-Version: 1.0
References: <20230506051337.614C44C922@rfcpa.amsl.com> <CA+k3eCRQE=ZJhczZ0uxBVDKVwoApmOcWKzOxvtsAFQcqOTdOGQ@mail.gmail.com> <8D98A3CD-79F4-4120-A1F6-ED75E4E27836@amsl.com> <CA+k3eCQaNeypkk9nujT3hG06rS1ztumVbOCeZj_bFAHwvjXiJg@mail.gmail.com> <89913652-779B-4294-9823-1090AB577103@amsl.com> <CA+k3eCR7Q_4OqKMZD1jGf8J7UkJxXJcCrS_kqEoq4zWo3Pbeog@mail.gmail.com> <F86862E3-900D-4F7F-9E38-0F7EE1E9E85E@amsl.com>
In-Reply-To: <F86862E3-900D-4F7F-9E38-0F7EE1E9E85E@amsl.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 15 May 2023 12:40:23 -0600
Message-ID: <CA+k3eCSzOKqqSyy071jAgz2nxbQuap=6K6QFARdfpbfmSYpC1g@mail.gmail.com>
To: Alice Russo <arusso@amsl.com>
Cc: torsten@lodderstedt.net, ietf@justin.richer.org, oauth-ads@ietf.org, oauth-chairs@ietf.org, hannes.tschofenig@arm.com, "Roman D. Danyliw" <rdd@cert.org>, auth48archive@rfc-editor.org, rfc-editor@rfc-editor.org
Content-Type: multipart/alternative; boundary="0000000000002b286f05fbbfcba9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/NTB-MtbdWsZt9oQj55Q6XggnaRg>
Subject: Re: [auth48] AUTH48: RFC-to-be 9396 <draft-ietf-oauth-rar-23> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2023 18:40:55 -0000

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 <arusso@amsl.com> 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=40pingidentity.com@dmarc.ietf.org> 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 <arusso@amsl.com> 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=
>> 40pingidentity.com@dmarc.ietf.org> wrote:
>> >
>> > Thanks Alice, replies are inline below this time...
>> >
>> > On Tue, May 9, 2023 at 4:57 PM Alice Russo <arusso@amsl.com> 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=
>> 40pingidentity.com@dmarc.ietf.org> 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 <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 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, rfc-editor@rfc-editor.org 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
>> > >
>> > >   *  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-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,
>> > >        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
>> > > — 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._