Scott (and the WG), My apologies for not taking the time to do a more read of this document earlier. Overall, I believe it to be good. And I believe it to cover the range of features I have seen discussed in the various RDAP circles. Below you will find my comments.
Section 3.1.2 could benefit from a sequence or ladder diagram. In Sections 4.1.1 and Sections 4.1.2, there are TTLs for the session and device. These are expressed in relative seconds, but from reading this I cannot determine the relation. Could or should these be absolute time values? In Section 4.2.1, is there a reason both forms of signaling the end user identifier must be used? Can we just pick one? Or make one MANDATORY to support? From a security standpoint, it might be best to use the Authentication header. In Section 4.2.3, a notice MUST be supplied with login successes and failures. I think the notice should be a MAY and not a MUST as the client will know the success/failure based on the farv1_session. Furthermore, the draft should probably give examples of what might be in those notices. Such as when login success, the notice may indicate any limited scope of use, etc... and for failure, a more descriptive reason for the failure. I have a similar concept for Section 4.2.4.1 as with Section 4.2.3. Furthermore, is it possible to signal a failure with a farv1_deviceInfo structure? Otherwise, the client is left to determine the failure on the notice structure, making the text a formal signaling mechanism. If the failure is indicated by a lack of farv1_deviceInfo structure, that needs to be explicitly stated. For the Do Not Track feature in Section 4.3.2, it is unclear to me what a server should respond with if the user requests farv1_dnt=true but the policy does not allow it for that user. The draft says return a 501 Not Implemented, but a 401 or 403 seems more appropriate. Section 4.4, 4.5, and 4.6, same comment about notices as section 4.2.3. I guess I am a bit uneasy with free form text being used to signal success/failure. In Section 4.7, the server responds to unrecognized identification with a 501. I think this should be 400, unless the server is required by policy to understand the information. -andy On Mon, Oct 3, 2022 at 8:39 AM James Galvin <[email protected]> wrote: > > REMINDER: > > This document is in WGLC and has only received support from its Editor and > its Document Shepherd. > > To advance this document we need expressions of support from others to > advance this document to the IESG to be considered for publication as a > Proposed Standard. > > WGLC remains open through Monday, 10 October. This document can not advance > without support. > > Thanks, > > Antoin and Jim > WG Co-Chairs > > > On 26 Sep 2022, at 10:03, James Galvin wrote: > > > The document editors have indicated that the following document is ready > > for submission to the IESG to be considered for publication as a Proposed > > Standard: > > > > Federated Authentication for the Registration Data Access Protocol (RDAP) > > using OpenID Connect > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/17/ > > > > Please indicate your support or no objection for the publication of this > > document by replying to this message on list (a simple “+1” is sufficient). > > > > If any working group member has questions regarding the the publication of > > this document please respond on the list with your concerns by close of > > business everywhere, Monday, 10 October 2022. If there are no objections > > the document will be submitted to the IESG. > > > > The Document Shepherd for this document is Zaid Al Banna. > > > > Thanks, > > > > Antoin and Jim > > WG Co-Chairs > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
