Skip to main content

Last Call Review of draft-ietf-regext-rdap-openid-24

Request Review of draft-ietf-regext-rdap-openid
Requested revision No specific revision (document currently at 27)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-09-01
Requested 2023-08-18
Authors Scott Hollenbeck
I-D last updated 2023-08-29
Completed reviews Artart Last Call review of -24 by Valery Smyslov (diff)
Genart Last Call review of -24 by Meral Shirazipour (diff)
Intdir Last Call review of -25 by Dirk Von Hugo (diff)
Assignment Reviewer Valery Smyslov
State Completed
Request Last Call review on draft-ietf-regext-rdap-openid by ART Area Review Team Assigned
Posted at
Reviewed revision 24 (document currently at 27)
Result Ready w/nits
Completed 2023-08-29
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

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.

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

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
   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 "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 - 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 - 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
   three members:". In fact, there are four members in the following data