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.