From: Mario Loffredo <mario.loffr...@iit.cnr.it> Sent: Friday, February 25, 2022 4:16 AM To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-11.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. Hi Scott, please find my comments below. Il 24/02/2022 15:24, Hollenbeck, Scott ha scritto: -----Original Message----- From: I-D-Announce <mailto:i-d-announce-boun...@ietf.org> <i-d-announce-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent: Thursday, February 24, 2022 9:19 AM To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> Cc: regext@ietf.org <mailto:regext@ietf.org> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-11.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-11.txt Pages : 31 Date : 2022-02-24 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] This version addresses the most recent feedback. Significantly, it includes path segment changes such that all requests are of the form "session/*". I've personally tested the specification using a functionally limited RDAP server that I wrote myself, web browser and Unix command line clients, and the OpenID services provided by Google Gmail and Yahoo mail. Feedback is requested and welcome as always. Scott Here in the following a first feedback after a quick review: 1. It seems to me that the set of claims included in Figure 1 corresponds to setting the scope value to "profile email rdap". Correct? [SAH] Yes, correct, though the Google/Gmail OP doesn’t support the ”rdap” scope. That’s something I had to simulate in the response. If so, should the document state what is the minimum set of claims returned to the End-User by the RDAP server ? Otherwise, if every RDAP server was free to request the set of claims as it sees fit to make its access control decisions, would it be better to change the following sentence? OLD A "userClaims" array that contains the set of claims associated with the End-User's identity NEW A "userClaims" object that contains the set of claims associated with the End-User's identity and used/requested by the RDAP server to make access control decisions [SAH] OK, that’s reasonable. I don’t want to specify the scopes because that’s something for the RDAP server to decide. 2) The definition of "userClaims", "sessionInfo" and "deviceInfo" data structures as array is not compliant with the definition of JSON array in RFC 7159: An array structure is represented as square brackets surrounding zero or more values (or elements). I would opt for using "object" and "members" instead of "array" and "name-value pairs", respectively. [SAH] Thanks for catching that. I used arrays to represent those data structures in my PHP code, but apparently PHP’s json_encode() function doesn’t necessarily map a PHP array to a JSON array. I’ll fix that as you suggested. 3) Should the value of the "expires_in" member in Figure 2 be 1300 (integer) instead of "1300" (string) ? [SAH] Yes, that should be an integer value. I’ll fix the example. I'm a bit doubtful about other contents. I'll be much more certain once I have made some tests ;-) [SAH] Please do! I’ll gladly add mention of any implementation work you do to the “Implementation Status” section, too. Best, Mario _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext <https://secure-web.cisco.com/1VEnnEhVonnelPfAGQtpUX_Dl7wh_HndVQAqI9MUUKP0uVV2nzoYKq-OEneO3GOWUNPlL6Tub6qbHeJYxSnycZrXg3O6AYXi4n3OLnBBRS144iygPoY4iePaDN3lMEt2FtJLtfkhZwFjDwRZ-5xcALuUNcz4K69ZWjC0uOkw8K6WmC8xuAt0wPg228luX4gWI3xIY522qvkX10dubhknNWA_pxs_M7yKBx_k6wwn6hcnCOqMTDcuNZp01Nl0CQcDb/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> -- Dr. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo <http://secure-web.cisco.com/1BTsqkA2-PawN0oFLQS_WaRVo7n66m_rBwZIr5WueYXDm1rdhBxvPdPVPoa8uE9awamfSsiXEjWi8Tx8m-rZnC0UimbG0gAtmD_08SijPNgX5g1p5uqxJwzO0Yo8TebfgYLan8N9_p3swf2HebmDBN1UaBPk5vq0r6l-EMdZUk6b4MejweAHobL4LRNnodjGg8TjJCDJPPvtvHIXqDloC30oy_M1Pl9ttgNimVBNZwnUOpE-zKunHzw0zLcY9XQXA/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
