Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-openid-27> for your review

[Sarah Tarrant <[e-mail]>]

Hi Scott,

Thank you for your reply. We have updated the document accordingly. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. 

We have one followup request:

1) Regarding:
>> 7) <!-- [rfced] Should the following lines also appear within the <artwork>
>> element to match the examples in Sections 5.2.1 and 5.2.2?
>> 
>> Section 4.2.1:
>>   https://example.com/rdap/domain/example.com?farv1_qp=legalActions
>> 
>> 
>> Section 4.2.2
>>   https://example.com/rdap/domain/example.com?farv1_dnt=true
>> 
>> Section 5.2.1:
>> https://example.com/rdap/farv1_session/login
>>   ...
>>   https://example.com/rdap/farv1_session/login
>> 
>> Section 5.3:
>>   https://example.com/rdap/farv1_session/status
>> 
>> Section 5.4:
>>   https://example.com/rdap/farv1_session/refresh
>> 
>> Section 5.5:
>>   https://example.com/rdap/farv1_session/logout
>> -->
> 
> [SAH] I'd like to trust your judgment for each of these. They're all examples, and if it's preferable to mark them as artwork for display/font consistency purposes, that's fine with me.

Please review our formatting of these lines as we updated them to artwork elements.


The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9560.txt
https://www.rfc-editor.org/authors/rfc9560.pdf
https://www.rfc-editor.org/authors/rfc9560.html
https://www.rfc-editor.org/authors/rfc9560.xml

The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9560-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9560-auth48diff.html (AUTH48 changes only)

Note that it may be necessary for you to refresh your browser to view the most recent version. 

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

Thank you,
RFC Editor/st


> On Apr 8, 2024, at 11:00 AM, Hollenbeck, Scott <shollenbeck=[e-mail]> wrote:
> 
> Thanks for your suggestions and questions. I've added my replies below.
> 
> Scott
> 
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Friday, April 5, 2024 5:54 PM
>> To: Hollenbeck, Scott <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> AlBanna, Zaid <[e-mail]>; [e-mail];
>> [e-mail]
>> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-
>> openid-27> for your review
>> 
>> Caution: This email originated from outside the organization. Do not click links
>> or open attachments unless you recognize the sender and know the content is
>> safe.
>> 
>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve (as necessary)
>> the following questions, which are also in the XML file.
>> 
>> 1) <!-- [rfced] To improve readability, would you like these sentences to be
>> formatted more like a list?
>> 
>> Original:
>>   This document uses the terms "client" and "server" as defined by RDAP
>>   [RFC7480].
>> 
>>   This document uses the terms "Access Token", "Authorization Code",
>>   "Authorization Endpoint", "Authorization Grant", "Client
>>   Authentication", "Client Identifier", "Protected Resource", "Refresh
>>   Token", "Resource Owner", "Resource Server", and "Token Endpoint"
>>   defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim
>>   Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT)
>>   [RFC7519]; the terms "ID Token" and "UserInfo Endpoint" defined by
>>   OpenID Connect Core 1.0 [OIDCC]; and the term "JWT Access Token"
>>   defined by RFC 9068 [RFC9068].
>> 
>> Perhaps:
>>   This document uses the following terminology.
>> 
>>   Terms defined by [RFC7480]:
>> 
>>     *  client
>>     *  server
>> 
>>   Terms defined by [RFC6749]:
>> 
>>     *  Access Token
>>     *  Authorization Code
>>     *  Authorization Endpoint
>>     *  Authorization Grant
>>     *  Client Authentication
>>     *  Client Identifier
>>     *  Protected Resource
>>     *  Refresh Token
>>     *  Resource Owner
>>     *  Resource Server
>>     *  Token Endpoint
>> 
>>   Terms defined by [RFC7519]:
>> 
>>     *  Claim Name
>>     *  Claim Value
>>     *  JSON Web Token (JWT)
>> 
>>   Terms defined by [OIDCC]:
>> 
>>     *  ID Token
>>     *  UserInfo Endpoint
>> 
>>   Term defined by [RFC9068]:
>> 
>>     *  JWT Access Token
>> -->
> 
> [SAH] This is fine.
> 
>> 2) <!--[rfced] As "capabilities" is plural, should "type" also be made plural?
>> Note that this sentence occurs twice in Section 3.1.3.
>> 
>> Original:
>>   An RDAP client sends an RDAP "help" query to an RDAP server to
>>   determine the type and capabilities of the OpenID Providers that
>>   are used by the RDAP server.
>> 
>> Perhaps:
>>   An RDAP client sends an RDAP "help" query to an RDAP server to
>>   determine the types and capabilities of the OpenID Providers that
>>   are used by the RDAP server.
>> -->
> 
> [SAH] Yes, plural "types".
> 
>> 3) <!-- [rfced] We suggest updating Sections 4.1 and 5.1.1 to use definition
>> lists <dl> instead of ordered lists <ol> because each item is in the form of term
>> and definition. Please let us know if this is acceptable.
>> -->
> 
> [SAH] Yes, that's acceptable.
> 
>> 4) <!-- [rfced] Please review each artwork element in the xml file. Specifically,
>> should any artwork element be tagged as sourcecode or another element?
> 
> [SAH] The artwork element was used to display sequence diagrams. It's not source code, so I think the artwork elements can be left as-is.
> 
>> Additionally, please review the "type" attribute for the sourcecode elements in
>> the XML file and let us know if any further changes are needed. If the current
>> list of preferred values for "type" (https://secure-
>> web.cisco.com/1SmMZVHCsNzI2WXHLS9Cl7LwVjGvHr397vUhaBYl4EvM_QK
>> 31oZNnJi85unYFsxF5vDlTwJVWMwZO5wdAeZlpbunA3g3AKgkMPAEVZRr4-
>> aDUNSNvxerzmhLQP85lhU1iyz84mRwWnhVHwLyk5cluKlOoi9U6G-
>> JzwQCyhTowXr_21b8f-nDKh1oOY1XOVFTp6Y-
>> EqOytCw1309r8HQE3i2_edpt6vTYcw6cTVps0jQKdUtPKrrPB8BuuULaI4GL8iB
>> k65o-vL-oFCWpZ49HbCP96r-
>> KJD2fax0vo4j4Coxk/https%3A%2F%2Fwww.rfc-
>> editor.org%2Fmaterials%2Fsourcecode-types.txt) does not contain an
>> applicable type, then feel free to suggest a new one.  Also, it is acceptable to
>> leave the "type" attribute not set.
>> -->
> 
> [SAH] I didn't see any sourcecode elements in the XML file. "sourcecode" appears three times, and only in the comment above.
> 
>> 5) <!-- [rfced] FYI - In Section 5.1, we updated the following paragraph to a
>> definition list, which matches the definition list in Section 4.2. Please let us
>> know if there are any objections.
>> 
>> Original:
>>   This specification describes two new data structures that are used to
>>   return information to a session-oriented client: a "farv1_session"
>>   data structure that contains information that describes an
>>   established session, and a "farv1_deviceInfo" data structure that
>>   contains information that describes an active attempt to establish a
>>   session on a UI-constrained device.
>> 
>> Current:
>>   This specification describes two new data structures that are used to
>>   return information to a session-oriented client:
>> 
>>   "farv1_session":  A data structure that contains information that
>>      describes an established session.
>>   "farv1_deviceInfo":  A data structure that contains information that
>>      describes an active attempt to establish a session on a UI-
>>      constrained device.
>> -->
> 
> [SAH] That's fine.
> 
>> 6) <!-- [rfced] FYI - In Sections 5.2.1, 5.2.2, 5.2.4.1, and 5.2.4.2, we moved
>> the instances of "NOTE:" regarding line wrapping into the artwork to match
>> RFC 8792.
>> -->
> 
> [SAH] That's fine.
> 
>> 7) <!-- [rfced] Should the following lines also appear within the <artwork>
>> element to match the examples in Sections 5.2.1 and 5.2.2?
>> 
>> Section 4.2.1:
>>   https://secure-
>> web.cisco.com/1113pv331Ww1amx2sItr3suMCpJjoCeuz8QoSI9TMwdy5a2u
>> eIqRp6-96pfn0Eq0ef6w7_ow74OFRt1p8dOcO7xXXjY62vZdecKS0SAAvNlI-
>> U21me5RwjymI3V3qOr35uuqMINvYIJ3WFExWOfqcV9p986DFcEVHDrSQ7z
>> wMX2iVPUYaN6Q_vvpPD2jAJqh-
>> D8orkzmpv9xlUDoAL8XTewfXPqi4cIDWCL_BXcwEd5V7Y7-
>> k4q226I7HKJT8ZDCHYMc4zgsxG8RnGkHRTLSv4t6-
>> q8I3FBYRahIi9WQJx84/https%3A%2F%2Fexample.com%2Frdap%2Fdomain
>> %2Fexample.com%3Ffarv1_qp%3DlegalActions
>> 
>> Section 4.2.2
>>   https://secure-
>> web.cisco.com/1om323DtiaAEw0xP6n0YKzj5yKRrtGVVXUxwWGJu6biNEmCi
>> zN1z2r2wtzk6ydH_v4415xqWURujVBZHRtizKO2PkXX5FQJ8AVumdHEUb6KR
>> Uj_LWDrJayjgKuL4p6UXOy9-5Trrk92t4z3Y1rpe-
>> lCHWQfAQpqGvxkxFMtCArr7yvcKSoWnG-
>> wLvqzl0tQjdWQJRVIV35a6_Pz_EaG15Y6qS9hAu5EeWJNswmBEUTnWUI4wR
>> Lk6284oeL1MQNNQb8WlGqgQ9lkiCVHo44Sx0NGB3gq-
>> 4Roo7EHukBUw1660/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%
>> 2Fexample.com%3Ffarv1_dnt%3Dtrue
>> 
>> Section 5.2.1:
>>   https://secure-
>> web.cisco.com/16yAuvu8AN84mbw625w2O7XKgdR19Ll3JMnguOYzR2vuq
>> M7U4NlGgYMFDAKZt6-wsysBluRAUpDsOxbJsyZIUKpPTm-
>> 9xmG9h5AtAmrJ0zSxf17DFu0EkOiaajGHo6S5nf4zZBmQBPEudUcRsbgewqaX
>> KHpeZFIDLe0w2Br-9sVeNKk_Snwn9iBjQXSl-
>> 4MmRDTtoHd7AgKOfltzU8JFBqfWiC3urDgN8FwzzH94epvB0shpZPsS21DkLR
>> phxEc4Rb_OU5BGam9as228MtiF1e5Z8sVm-PHMcg-
>> lXa4tgrXw/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogi
>> n
>>   ...
>>   https://secure-
>> web.cisco.com/16yAuvu8AN84mbw625w2O7XKgdR19Ll3JMnguOYzR2vuq
>> M7U4NlGgYMFDAKZt6-wsysBluRAUpDsOxbJsyZIUKpPTm-
>> 9xmG9h5AtAmrJ0zSxf17DFu0EkOiaajGHo6S5nf4zZBmQBPEudUcRsbgewqaX
>> KHpeZFIDLe0w2Br-9sVeNKk_Snwn9iBjQXSl-
>> 4MmRDTtoHd7AgKOfltzU8JFBqfWiC3urDgN8FwzzH94epvB0shpZPsS21DkLR
>> phxEc4Rb_OU5BGam9as228MtiF1e5Z8sVm-PHMcg-
>> lXa4tgrXw/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogi
>> n
>> 
>> Section 5.3:
>>   https://secure-
>> web.cisco.com/1dPdCKMspJLQEXvDjPdeIkRgQ4p8WZ7plWPdzNKvMs_e_h8E
>> RMx4I0Cl5lue4S8zTgDLF1Xa1DUTVDECImGjjIMEzD8TSNn4jOUv9d_5I4K1O-
>> b6IPLoKXXb509PA5iP8oSHUwS3kNWVXgDkVklyDq4pP14EC4R1NEELiWLhV7
>> rw_poNoDQxlZ5UqXjMP803uaaNFyRFXRJN_kQtUG8hnWndImN7tjh6VoMV
>> ei--b1-KxfqdRV62peojx2xEv-m-hr-cMwBYygIwOj20E2K4Ng-
>> rMQcFO59eDa6V96f09Wg8/https%3A%2F%2Fexample.com%2Frdap%2Ffar
>> v1_session%2Fstatus
>> 
>> Section 5.4:
>>   https://secure-web.cisco.com/1idPQJA-
>> Hy84EM4kSnQM_1dONZ_mOkQimBuSiYQ2s3PoNPsmxYBD4RJUZoDGID1DB
>> dMxJBDkOF-
>> y2NgMWCpwVddWQNKLSGrGkkpocXefnA2ZfSadyUwD_I96dVqNBn2EGs1b
>> QnAp8BkrMsG_jU7ZWhTGRZ-
>> gEJe8_GbCJCwEK2kTXCQCHvhcBG7AQ2QtditgZxBhQSXLO6U1UaHrgL7Q_JKX
>> -
>> BnMevtzc8IpZ8bJbASKT2BUpML9P47IjqvL2xz4l_UG8rM9Q02jjcl9BeRL7HDN
>> 7DcB3FQqwr-
>> mNLoW8Bbs/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Fr
>> efresh
>> 
>> Section 5.5:
>>   https://secure-
>> web.cisco.com/1j6nbaaJZIgxAdoev_dQn3krOPFky3QfwGCvFXCspP3Aphwab
>> 1utQli7fGIFtx54QZMD4tMBC09rnDaUjMc-
>> 5aLxkbr6stKPYkhhPLC7EhCaKOka3b1oW9c-
>> SWOfnveEROZ1PZLhADbUEdNL2HGhb-
>> EdkMNFg8LRGy12zsOhxxCjqUJkfpI7u1hpoxdbCpRgaGDB3-
>> 8KI6Q3km7jy4YZbiqwzs96nrNjlVNiU5Tsiw69nMD0a8SopdQjzK-Pv_-
>> 24JhgRdGnaxvaDE_HhnPcqfL6aGYV8FXPpiAc-
>> _JzkEks/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogout
>> -->
> 
> [SAH] I'd like to trust your judgment for each of these. They're all examples, and if it's preferable to mark them as artwork for display/font consistency purposes, that's fine with me.
> 
>> 8) <!-- [rfced] To match common usage, would you like to update "smart
>> telephone"
>> to "smartphone"?
>> 
>> Original:
>>   This method requires an End-User to use a
>>   second device (such as a smart telephone) that has access to a web
>>   browser for entry of a code sequence that is presented on the UI-
>>   constrained device.
>> -->
> 
> [SAH] Sure, that's fine.
> 
>> 9) <!--[rfced] Would using a list improve the readability of this text?
>> 
>> Original:
>>   The requests described in this document are typically performed in a
>>   specific sequence: "farv1_session/login" (or the related
>>   "farv1_session/device" and "farv1_session/devicepoll" requests) to
>>   start a session, "farv1_session/status" and/or "farv1_session/
>>   refresh" to manage a session, and "farv1_session/logout" to end a
>>   session.
>> 
>> Perhaps:
>>   The requests described in this document are typically performed in a
>>   specific sequence:
>> 
>>   1.  "farv1_session/login" (or the related "farv1_session/device" and
>>       "farv1_session/devicepoll" requests) to start a session,
>> 
>>   2. "farv1_session/status" and/or "farv1_session/refresh" to manage a
>>      session, and
>> 
>>   3. "farv1_session/logout" to end a session.
>> -->
> 
> [SAH] Yes, that works.
> 
>> 10) <!--[rfced] IANA Considerations
>> 
>> A) Since the Value and Description columns are defined in Section 9.3 for the
>> "Registration Data Access Protocol (RDAP) Query Purpose Values"
>> registry, should a definition for the Reference column also be included? And
>> should "Reference: RFC 9560" be added to each entry to match the registry?
> 
> [SAH] Yes, please.
> 
>> B) To make the Description of domainNameControl more concise, may we
>> update it as follows?
>> 
>> Original:
>>   Value: domainNameControl
>> 
>>   Description: Tasks within the scope of this purpose include
>>   creating and managing and monitoring a registrant's own domain
>>   name, including creating the domain name, updating information
>>   about the domain name, transferring the domain name, renewing the
>>   domain name, deleting the domain name, maintaining a domain name
>>   portfolio, and detecting fraudulent use of the Registrant's own
>>   contact information.
>> 
>> Perhaps:
>>   Value: domainNameControl
>> 
>>   Description: Tasks within the scope of this purpose include, for a
>>   registrant's own domain name, creating the domain name, updating
>>   information about the domain name, transferring the domain name,
>>   renewing the domain name, deleting the domain name, maintaining a
>>   domain name portfolio, and detecting fraudulent use of the
>>   registrant's own contact information.
> 
> [SAH] Sure, that works. It differs from the definition found in the EWG report, though. Perhaps we should also change the text that describes the source of the values, changing "taken from" to "derived from" or "based on".
> 
> OLD:
> The set of initial values used to populate the registry as described below are taken from the final report produced by the Expert Working Group on gTLD Directory Services chartered by the Internet Corporation for Assigned Names and Numbers (ICANN)
> 
> NEW:
> The set of initial values used to populate the registry as described below are derived from the final report produced by the Expert Working Group on gTLD Directory Services chartered by the Internet Corporation for Assigned Names and Numbers (ICANN)
> 
>> C) To reflect the verbiage of other Descriptions in the "Registration Data Access
>> Protocol (RDAP) Query Purpose Values" registry, may we update the
>> Description of regulatoryAndContractEnforcement as follows?
>> 
>> Original:
>>   Value: regulatoryAndContractEnforcement
>> 
>>   Description: Tasks within the scope of this purpose include tax
>>   authority investigation of businesses with online presence,
>>   Uniform Dispute Resolution Policy (UDRP) investigation,
>>   contractual compliance investigation, and registration data escrow
>>   audits.
>> 
>> Perhaps:
>>   Value: regulatoryAndContractEnforcement
>> 
>>   Description: Tasks within the scope of this purpose include
>>   investigating the tax authority of businesses with online presences,
>>   investigating Uniform Domain-Name Dispute-Resolution Policy (UDRP),
>>   investigating contractual compliance, and registering data escrow
>>   audits.
>> -->
> 
> [SAH] Yes, as noted above.
> 
>> 11) <!--[rfced] Instead of using a link, may we update this sentence to use a
>> citation and add a reference entry to the Informative References section?
>> 
>> Original:
>>   The set of initial values used to populate the registry as described
>>   here are taken from the final report
>>   (https://secure-
>> web.cisco.com/15_7KMQ1muuBMyg88fsOKiXbzC1YP0hULXYkxdtakqMbgIjJ
>> p-YA6ZzpDn0Y0fone3lxH1jpKNAi7Bm89CSebT8Jz-
>> v40hlEM_g4HqMaL3IoGvBF87KO9ZTJsamgc-
>> HwF6_muMSplS_8Vc8Yhhr2CGdwTn02HJ_YO-pk-
>> hfFsQgOgazEiNGMBCxM0J6uuiCFEZTuFH4p52UpSIJ_BUshQtU36TNqKsFumv
>> iilZuS3lKLfmhqrcmsxTWOQ3k7QUdTkETfUKreIn9FMGKkEuq3G_qF5hxHo1dQ
>> ybhpCs5NVdCw/https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles
>> %2Ffiles%2Ffinal-report-
>>   06jun14-en.pdf) produced by the Expert Working Group on gTLD
>>   Directory Services chartered by the Internet Corporation for Assigned
>>   Names and Numbers (ICANN).
>> 
>> Perhaps:
>>   The set of initial values used to populate the registry as described
>>   below are taken from the final report produced by the Expert Working
>>   Group on gTLD Directory Services chartered by the Internet Corporation
>>   for Assigned Names and Numbers (ICANN) [gTLD].
>>   ...
>>   [gTLD]    Expert Working Group on gTLD Directory Services (EWG), "Final
>>             Report from the Expert Working Group on gTLD Directory Services:
>>      A Next-Generation Registration Directory Service (RDS)", June
>>      2014, <https://secure-
>> web.cisco.com/15_7KMQ1muuBMyg88fsOKiXbzC1YP0hULXYkxdtakqMbgIjJ
>> p-YA6ZzpDn0Y0fone3lxH1jpKNAi7Bm89CSebT8Jz-
>> v40hlEM_g4HqMaL3IoGvBF87KO9ZTJsamgc-
>> HwF6_muMSplS_8Vc8Yhhr2CGdwTn02HJ_YO-pk-
>> hfFsQgOgazEiNGMBCxM0J6uuiCFEZTuFH4p52UpSIJ_BUshQtU36TNqKsFumv
>> iilZuS3lKLfmhqrcmsxTWOQ3k7QUdTkETfUKreIn9FMGKkEuq3G_qF5hxHo1dQ
>> ybhpCs5NVdCw/https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles
>> %2Ffiles%2Ffinal-report-
>>      06jun14-en.pdf>.
>> -->
> 
> [SAH] Yes, as noted above.
> 
>> 12) <!-- [rfced] References
>> 
>> A) The following OpenID Connect references appear to have been superseded
>> by 2023 versions. As we were unable to find URLs to the previous versions,
>> we have updated them to reflect the most current versions.
>> 
>> Original:
>>   [OIDCC]    OpenID Foundation, "OpenID Connect Core incorporating
>>              errata set 1", November 2014,
>>              <https://secure-
>> web.cisco.com/1j1jAbYtrpDW_cjsb8d1REltF3dUV0S_aPF06IbjmRFMNGz7hg
>> hkBv2QkTL8zV1G3II8Y7rYmy8vkHLcbI-
>> KrHg_tban0mgoD3ArBeeS8a_q8R5ldrcL26F8EAJ794eePy26-
>> e2SOSdGC5NNljmWcUZVGj8CbxEV4le3b5b7RQwVObka76oLaDp9PdQjpECV
>> _tlOA2T-
>> ZxlGosrCpbgKbCmd70XoJZPDvFeMJl55WSpU8Vt_6_I_zhyssET6RwGvoo0ligZ
>> R9v-
>> SWpD5xko6ME1KpCtbwLyLijtv_VuJiBzI/https%3A%2F%2Fopenid.net%2Fspe
>> cs%2Fopenid-connect-core-1_0.html>.
>> 
>> Current:
>>   [OIDCC]    Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
>>              C. Mortimore, "OpenID Connect Core 1.0 incorporating
>>              errata set 2", December 2023,
>>              <https://secure-
>> web.cisco.com/1j1jAbYtrpDW_cjsb8d1REltF3dUV0S_aPF06IbjmRFMNGz7hg
>> hkBv2QkTL8zV1G3II8Y7rYmy8vkHLcbI-
>> KrHg_tban0mgoD3ArBeeS8a_q8R5ldrcL26F8EAJ794eePy26-
>> e2SOSdGC5NNljmWcUZVGj8CbxEV4le3b5b7RQwVObka76oLaDp9PdQjpECV
>> _tlOA2T-
>> ZxlGosrCpbgKbCmd70XoJZPDvFeMJl55WSpU8Vt_6_I_zhyssET6RwGvoo0ligZ
>> R9v-
>> SWpD5xko6ME1KpCtbwLyLijtv_VuJiBzI/https%3A%2F%2Fopenid.net%2Fspe
>> cs%2Fopenid-connect-core-1_0.html>.
>> ...
>> Original:
>>   [OIDCD]    OpenID Foundation, "OpenID Connect Discovery 1.0
>>              incorporating errata set 1", November 2014,
>>              <https://secure-
>> web.cisco.com/1mwliIUdewEEDtBi9G_tscxkHtmPkQFm6nBHjgd3ixXC-
>> TBalT57OQDT-
>> 9ydSvkU1S_DxFmPA1BnpsQtxZFhrirWQ7ObZ5JRamqUBvDxQ6HrXcF0wZ_fQ
>> Gc3W8ZC0q3nGWXcTed4EYwF_F7-
>> AWqhRMHki2BYYwK_z9zrrjKI57bWnO2oPCXa7n5pUXPGxCXaezNjnoTf7TE_l
>> XpAbCf276zLQxHyW6Mm5FbkD_Q0VNlMBi6SxzFXuo-
>> I5zAn6WwEEzw6N20B1bTWswXrb80xMZgfLOTDd3IJMLRrsFIKl6iM/https%3
>> A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-discovery-
>>              1_0.html>.
>> 
>> Current:
>>   [OIDCD]    Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
>>              Connect Discovery 1.0 incorporating errata set 2",
>>              December 2023, <https://secure-
>> web.cisco.com/1foVjwVGURxqOSSouI6iMZEbTCbAlkZLskB1ero3uM0FkjBJ8T
>> BLMauKA4YYOGSLfGI5ZJ6rnxKCxaALugf6wk5f9wUvwCZU5A3Zc15BUsdDAO
>> XPkh5E4ZU5yTNVerJM0sX8UmF_hQG5sp7FHPoFX3iRp2bBlEfOtoElKcZ3y-
>> jGh7fBDFPjI5NyhMzji201YgzzrplEYQ5UPTWkhfPZFGP1ro1yxy24aOz6AAFI76
>> 0XPpRT__Muu4XLI7gE6pNPaoeblQ_a0VzgwLdMVjcLZUWtQKs1BM8LXl8DYY
>> AeiIDo/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
>>              discovery-1_0.html>.
>> ...
>> Original:
>>   [OIDCR]    OpenID Foundation, "OpenID Connect Dynamic Client
>>              Registration 1.0 incorporating errata set 1", November
>>              2014, <https://secure-
>> web.cisco.com/1foVjwVGURxqOSSouI6iMZEbTCbAlkZLskB1ero3uM0FkjBJ8T
>> BLMauKA4YYOGSLfGI5ZJ6rnxKCxaALugf6wk5f9wUvwCZU5A3Zc15BUsdDAO
>> XPkh5E4ZU5yTNVerJM0sX8UmF_hQG5sp7FHPoFX3iRp2bBlEfOtoElKcZ3y-
>> jGh7fBDFPjI5NyhMzji201YgzzrplEYQ5UPTWkhfPZFGP1ro1yxy24aOz6AAFI76
>> 0XPpRT__Muu4XLI7gE6pNPaoeblQ_a0VzgwLdMVjcLZUWtQKs1BM8LXl8DYY
>> AeiIDo/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
>>              registration-1_0.html>.
>> 
>> Current:
>>   [OIDCR]    Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
>>              Dynamic Client Registration 1.0 incorporating errata set
>>              2", December 2023, <https://secure-
>> web.cisco.com/1BgqlLr8mYHntx0CQL-
>> 548Z19ntEk4GaRDvAThFUaCouk9Cdn6X1FlvhG0ApA15HoOJLinkyEXeaZXSCd
>> XxWv-FSHNlzZGxtJhaynNGk-kuUrNG_Kin4ndHeLggDE4fsZryl5-
>> jhBITg06zWfekW9kf-
>> ZVskfDMGL8tRUOuZwDLyYdLVOW119aVIlw3BcRd9uRazoilk-
>> jtiIz0pdZNKFmJG-Q-
>> GY092waBpjU448s8nnRBUD3FarrAlUivIWjjmZPmcsalqDbniZmayJoZouefWK
>> aAK65akwm7YXIzc-2G4/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-
>>              connect-registration-1_0.html>.
> 
> [SAH] Those are all fine. Those updates were published after the document was reviewed by the IESG.
> 
>> B) As the "application/x-www-form-urlencoded" section is mentioned within
>> the body of the document when [HTMLURL] is cited, we have updated the
>> URL of this reference to link to the whole document rather than the specific
>> section.
>> 
>> Original:
>>   [HTMLURL]  Web Hypertext Application Technology Working Group
>>              (WHATWG), "URL (Living Standard)", September 2023,
>>              <https://secure-
>> web.cisco.com/1fcFtvLynBykC28ML19oHed0Q593AEcIVLh4z2t08TFyNPA2C
>> 7Uya4REl4Wib4PSiaJ3ieNBO1q4QCDfKZt0tAqJrqcztRWZo4EX_CXfHOVhNEK
>> Vdqm45GP6oQAhUp_wmIvmH3kQ0PpFyK4djtn0VffCjObOeqoxcp3D4fuvbt
>> w738FJC97VwmOZMN4WjkX1BhmPFW0WAB0O00GuLSSJ4Gw9fnI5bA8gtL
>> eHWIs58_TcLRRMJQReJBHbqmnkA-
>> jaks4PYICHJc3zG58LbF9YErMJWhWDPejZVTSBfX_WnBbo/https%3A%2F%2F
>> url.spec.whatwg.org%2F%23application%2Fx-www-form-
>>              urlencoded>.
>> 
>> Current:
>> 
>>   [HTMLURL]  WHATWG, "URL (Living Standard)", March 2024,
>>              <https://secure-
>> web.cisco.com/1FIyZHErwYvQfB9GqHd7V9igs79n9795A_gO6-
>> V5pHiO21vHJ-
>> Qb6k4FaFhmQOUGOoJQvIlGKeCaHI9pn7R_DyTWZsOtz0CxgDz4c7k6323DCS
>> gLuflXZIRI9ytdUYnrt26tbKNSSEnMcNR7bg88hvwMie47brh4RKH1rzJcW4L40
>> R1OJeqb3EpLAxoXQUicUEy5ZuE-pmEYtZ5RvGzq4bN-
>> qfH61l419cyXPTwRrZHzKNgoZaaPDEYpxubZ1tCn0j8ACdKb0qIOZf3DCBfll8vx
>> hiCYvxmkoCqjoVxFRXXM/https%3A%2F%2Furl.spec.whatwg.org%2F>.
>> -->
> 
> [SAH] That's fine.
> 
>> 13) <!-- [rfced] Throughout the text, when citing non-RFC section numbers,
>> the formats somewhat vary. For simplicity, would you like to update all
>> instances to the following format to match how RFCs are referenced? Note
>> that we haven't included every example below.
>> 
>> Current:
>>   the "application/x-www-form-urlencoded" section of
>>   WHATWG URL Standard [HTMLURL]
>>   ...
>>   Section 5 of the OpenID Connect Core protocol [OIDCC]
>> 
>> Perhaps:
>>   Section "application/x-www-form-urlencoded" of
>>   [HTMLURL]
>>   ...
>>   Section 5 of [OIDCC]
>> -->
> 
> [SAH] Yes, that's fine.
> 
>> 14) <!-- [rfced] Terminology
>> 
>> A) The following terms are capitalized in the text but are lowercase in the
>> corresponding cited RFCs. Should these be made lowercase to match the
>> corresponding RFCs?
>> 
>> Lowercase in RFC 6749:
>>   Access Token
>>   Authorization Code
>>   Authorization Code Flow
>>   Authorization Endpoint
>>   Authorization Grant
>>   Token Endpoint
>>   Token Request
>>   Token Response
>> 
>> Lowercase in RFC 6750:
>>   "Bearer" authentication scheme
>> 
>> Lowercase in RFC 8628 and only hyphenated when in attributive position (i.e.,
>> when followed by a noun):
>>  End User
>> 
>> Lowercase in RFC 9068:
>>   JWT Access Token
>> 
>> Additionally, should "Authorization Request" also be made lowercase to
>> parallel usage in other previously published RFCs?
> 
> [SAH] Yes, please be consistent with other RFCs.
> 
>> B) The following terms appear to be used inconsistently throughout the
>> document. Should they be made lowercase for consistency and to match
>> the corresponding cited RFCs?
>> 
>> Lowercase in RFC 6749:
>>   Client Authentication vs. client authentication
>>   Client Identifier vs. client identifier
>>   Protected Resource vs. protected resource
>>   Refresh Token vs. refresh token
>>   Resource Owner vs. resource owner
>>   Resource Server vs. resource server
>> 
>> Lowercase in RFC 6750:
>>   "Authorization" header vs. authorization header
>> 
>> Not consistently capitalized in RFC 7519:
>>   Claim Value vs. claim value
> 
> [SAH] Yes, please be consistent.
> 
>> C) Throughout the text, the following terminology appears to be used
>> inconsistently. May we update to the version on the right to match more
>> common usage?
>> 
>>   Identity Provider > identity provider
>>   issuer identifier > Issuer Identifier
>>   RDAP Client > RDAP client
>>   RDAP Server > RDAP server
>>   End-User Identifier > end-user identifier
> 
> [SAH] Yes, please match common use.
> 
>> D) Might it be helpful to the reader to clarify the slash in cases like
>> the following (i.e., does it stand for "and", "or", or "and/or")? Note that
>> this appears in several places; the following is just an example.
>> 
>> Original:
>>   An RDAP server/RP needs to be able to map an End-User's identifier to
>>   an OP.
>> 
>> Perhaps:
>>   An RDAP server or RP needs to be able to map an End-User's identifier
>>   to an OP.
> 
> [SAH] That’s fine.
> 
>> E) We see "farv1" expanded two different ways. May we update both
>> instances to
>> the following to be consistent?
>> 
>> Current:
>>   Federated Authentication for RDAP version 1
>>   ...
>>   version 1 of a federated authentication method for RDAP
>> 
>> Perhaps:
>>   federated authentication method for RDAP version 1
> 
> [SAH] Yes, that's fine.
> 
>> F) FYI - To match the OpenID Connect Core 1.0 reference, we updated one
>> instance of "ID token" to "ID Token". Please let us know if there is any
>> objection.
>> -->
> 
> [SAH] No objection.
> 
>> 15) <!--[rfced] Acronyms
>> 
>> A) FYI - We have added expansions for abbreviations upon first use
>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>> expansion in the document carefully to ensure correctness.
>> 
>> Representational State Transfer (RESTful)
> 
> [SAH] That's fine.
> 
>> B) For the term "OpenID Provider", may we update the first instance to be
>> "OpenID Provider (OP)" and all subsequent instance to "OP"?
>> -->
> 
> [SAH] Yes, that's fine.
> 
>> 16) <!--[rfced] Please review the "Inclusive Language" portion of the online
>> Style Guide <https://secure-
>> web.cisco.com/1VMcTDIlJnnotcZuv_P4j8x8ITPnfdvnF4etNChbQ9ZDF1J4p7
>> W2Jod45sBwOz5vqggmjCYV4a49lwGilAzD9Dam6rx6fXsBgMzYjDi56HJbIs-
>> 7DQb1DRBAC1vd-
>> 4LKGwKv3zO0Plpborkr4losGEF4zjRLBrLO9B71PCTpcwfgmBvTP4Zuk6D-
>> oBoYJtVoTDmNBd2YLJBFv7RUuTk7v8wgS_8wjoBcy6AWjSGmztXSTEQQJzPdA
>> B50nGoFZe3rPRBZ5d3MBPRVF0iJMMTzSmpXHYySQ8ByFZvBqAP4F1lc/https
>> %3A%2F%2Fwww.rfc-
>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_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.
>> -->
> 
> [SAH] I didn't see anything that required change.
> 
> I didn't see anything else in my review of the RFC. Thanks again!
> 
> Scott