Reviewer: Valery Smyslov
Review result: Ready with Nits
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
