Subject: [regext] I-D Action: draft-ietf-regext-rdap-openid-11.txt

From: [email-masked]
Date: Thu, 24 Feb 2022 06:18:40 -0800

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-openid-11

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 24 Feb 2022 14:24:25 +0000

> -----Original Message-----
> From: I-D-Announce <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, February 24, 2022 9:19 AM
> To: [email-masked]
> Cc: [email-masked]
> 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.
>

[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

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 25 Feb 2022 10:16:01 +0100

Hi Scott,

please find my comments below.

Il 24/02/2022 15:24, Hollenbeck, Scott ha scritto:
>> From: I-D-Announce<[email-masked]>  On Behalf Of
>> [email-masked]
>> To:[email-masked]
>> Cc:[email-masked]

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
> [email-masked]
> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 25 Feb 2022 15:47:03 +0000

From: Mario Loffredo <[email-masked]>
Sent: Friday, February 25, 2022 4:16 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
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,

-----Original Message-----
From: I-D-Announce  <mailto:[email-masked]> 
<[email-masked]> On Behalf Of
[email-masked] <mailto:[email-masked]>
Sent: Thursday, February 24, 2022 9:19 AM
To: [email-masked] <mailto:[email-masked]>
Cc: [email-masked] <mailto:[email-masked]>
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:

[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

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

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:

[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
[email-masked] <mailto:[email-masked]>
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>