Hi Scott,
please find my comments below.
Il 24/02/2022 15:24, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: I-D-Announce<i-d-announce-boun...@ietf.org> On Behalf Of
internet-dra...@ietf.org
Sent: Thursday, February 24, 2022 9:19 AM
To:i-d-annou...@ietf.org
Cc: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?
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
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.
3) Should the value of the "expires_in" member in Figure 2 be 1300
(integer) instead of "1300" (string) ?
I'm a bit doubtful about other contents. I'll be much more certain once
I have made some tests ;-)
Best,
Mario
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
