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). 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. 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. 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? Happy to discuss any of the above. Thanks, Rick From: regext <regext-boun...@ietf.org> on behalf of Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> Date: Tuesday, February 8, 2022 at 1:57 PM To: regext@ietf.org <regext@ietf.org> 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 <i-d-announce-boun...@ietf.org> On Behalf Of > internet-dra...@ietf.org > Sent: Tuesday, February 8, 2022 1:53 PM > To: i-d-annou...@ietf.org > Cc: regext@ietf.org > 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext<https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
