Thanks for the feedback, Rick! More below.
From: Rick Wilhelm <[email protected]> Sent: Wednesday, February 9, 2022 10:12 AM To: Hollenbeck, Scott <[email protected]>; [email protected] Subject: [EXTERNAL] Re: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Scott, Overall, I think that the modifications move the I-D in a good direction. Thanks for your work on this. I don't have running code so this is more of a document review, rather than comments from an implementer perspective. Pls see the below. 3.1.2: NIT: 3.1.2 #2 uses the term ' "login" request'; while 4.1 uses term ' "login" query' (line 1). [SAH] It should be "query" consistently. 3.1.2: EDITORIAL: 3.1.2 #2 (in sentence 2) includes a MUST condition ("MUST include an "id" query parameter) for a server with only a remote Authorization Server. However, in 4.1, the MUST condition is more involved (has two options of delivery, not just the one mechanism described n 3.1.2) and is described as an "End-User identifier". Perhaps the text in sentence 2 of 3.1.2 can be aligned more closely to the text in 4.1 OR just reference 4.1 directly. [SAH] I'll remove the text from 3.1.2 and refer to 4.1. 3.1.2.1: EDITORIAL: ", but that protocol is not widely implemented and can be unreliable." The text is not clear if the reliability issues are due to the lack of wide implementation or due to inherent reliability issues. Suggest that "is not widely implemented" is sufficient for this use-case and the text "and can be unreliable" be struck. [SAH] I'll strike "and can be unreliable". 6. RDAP Conformance EDITORIAL: Last sentence of 4.1 para 1 says: "Clients can use either of these methods. Servers MUST support both methods." (Referring to local and remote client authentication.). However, Section 6, para 1, says "Both values MAY be present if a server supports both local and remote OpenID Authorization Servers." Thus, Section 6 implies that it's possible that a server might not support both local and remote authentication. Perhaps the solution would be to switch from "MAY" to "would" in section 6? [SAH] The "both methods" text refers to the client's options to send the client identifier as either a query parameter OR in an authorization header. It's not directly related to the text in Section 6, except to note that the identifier is OPTIONAL and might not be present at all. I'll change the text in Section 6 from "MAY" to "can", and will adjust both sections to make the distinction clearer. Happy to discuss any of the above. Thanks, Rick From: regext <[email protected] <mailto:[email protected]> > on behalf of Hollenbeck, Scott <[email protected] <mailto:[email protected]> > Date: Tuesday, February 8, 2022 at 1:57 PM To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt CAUTION: This email came from outside your organization. Don?t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. > -----Original Message----- > From: I-D-Announce <[email protected] <mailto:[email protected]> > On Behalf Of > [email protected] <mailto:[email protected]> > Sent: Tuesday, February 8, 2022 1:53 PM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> > Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-10.txt > > Caution: This email originated from outside the organization. Do not click links > or open attachments unless you recognize the sender and know the content > is safe. > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Registration Protocols Extensions WG of the > IETF. > > Title : Federated Authentication for the Registration Data Access > Protocol (RDAP) using OpenID Connect > Author : Scott Hollenbeck > Filename : draft-ietf-regext-rdap-openid-10.txt > Pages : 27 > Date : 2022-02-08 > > Abstract: > The Registration Data Access Protocol (RDAP) provides "RESTful" web > services to retrieve registration metadata from domain name and > regional internet registries. RDAP allows a server to make access > control decisions based on client identity, and as such it includes > support for client identification features provided by the Hypertext > Transfer Protocol (HTTP). Identification methods that require > clients to obtain and manage credentials from every RDAP server > operator present management challenges for both clients and servers, > whereas a federated authentication system would make it easier to > operate and use RDAP without the need to maintain server-specific > client credentials. This document describes a federated > authentication system for RDAP based on OpenID Connect. [SAH] Please review this, folks. It's been significantly modified since version -09, replacing the token management queries with simpler login, logout, and session queries. This puts the draft in a much better position with respect to RDAP behaving like a web service, and it simplifies client processing, too. Scott _______________________________________________ regext mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/regext <https://secure-web.cisco.com/1JIxbOCMKQqXhfEiMgDTkDXixRGPaaQXTB7s7ED0banKPz W9_e8PCvuZoSoExzMdIytk_BEEmfutPZ9LGTr0PLi5v230tO6NHDSJ71XuWYHlRai17-FlwwSPyn RH2Ux2Yx3jSOaT54uopzx3hjBedfeoraZEprj6lbIHkl3P-ZhsMCIiXnI-a1Jtt_bMSreDxTkzHG qeMKix6SMpyD_QLzH8RXXMoV-W6tQE--1mh3mSZ5uGre7XhxlYNR-Z53I_E/https%3A%2F%2Fww w.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
