Last Call Review of draft-ietf-regext-rdap-openid-24
review-ietf-regext-rdap-openid-24-artart-lc-smyslov-2023-08-29-00

I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document defines how the OpenID Connect protocol can be used to build a
federated authentication system for The Registration Data Access Protocol
(RDAP). The document is clear and detailed.

Nits:
1. Section 2 states: "Unless otherwise specified, all of the HTTP requests
described in
   this document that are sent from an RDAP client to an RDAP server use
   the HTTP GET method as specified in [RFC9110]." I failed to find in the
   document where other HHTP methods (e.g. POST) are mentioned. Perhaps, the
   introduction part of the sentence "Unless otherwise specified" can be
   trimmed?

2. In Section 3.1.1. "farv1_session/login" and "farv1_session/logout"
   are used without any explanation and reference (they are defined later in
   the document).

3. Sequence diagrams on Figures 1 and 2 are very helpful, but I believe that
they
   can be even more helpful if the order of parties participating in the
   protocol is the same on both figures (currently "RDAP Client" and "RDAP
   Server" are swapped on Figure 1 and 2).

4. Section 3.1.4.1: "An RDAP server/RP MUST support at least one of these
methods of OP
   discovery." I think that this requirement is too obvious to mention (it's
   clear that the OP must be known somehow for the whole mechanism to work, and
   the provided methods include manual configuration, as the last resort).

5. Section 3.1.4.2. - in sentence "The Hybrid Flow
   (described in Section 3.3 of the OpenID Connect Core protocol)
   combines elements of the Authorization and Implicit Flows by
   returning some tokens from the Authorization Endpoint and others from
   the Token Endpoint." I believe that "the Authorization and Implicit Flows"
   should be "the Authorization Code Flow and the Implicit Flow" instead.

6. Section 3.1.5.1. - in sentence "Value: the purpose string value being
registered.  Value strings can
   contain upper case characters from "A" to "Z", lower case ASCII
   characters from "a" to "z", and the underscore ("_") character.
   Value strings contain at least one character and no more than 64
   characters." please clarify "upper case ASCII characters".

7. I don't know how important it is, but there is no formal requirements
   for the language of the Description. Is it ok if the description
   is provided in, say, Russian :-) ?

8. Section 5.1.2. - "The "farv1_deviceInfo" data structure is an object that
contains
   three members:". In fact, there are four members in the following data
   structure.