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

[Mario Loffredo]

Hi Scott,

please find my comments below.

Il 24/02/2022 15:24, Hollenbeck, Scott ha scritto:

-Original Message-
From: I-D-Announce  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

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

[Hollenbeck, Scott]

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

[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 
https://www.ietf.org/mailman/listinfo/regext 

[regext] regext - Requested session has been scheduled for IETF 113

["IETF Secretariat"]

Dear Antoin Verschuren,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


regext Session 1 (1:00 requested)
Tuesday, 22 March 2022, Afternoon session I 1300-1400
Room Name: Grand Klimt Hall 2 size: 165
-


iCalendar: https://datatracker.ietf.org/meeting/113/sessions/regext.ics

Request Information:


-
Working Group Name: Registration Protocols Extensions
Area Name: Applications and Real-Time Area
Session Requester: Antoin Verschuren


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 50
Conflicts to Avoid: 

   


People who must be present:
  Antoin Verschuren
  James Galvin
  Murray Kucherawy

Resources Requested:

Special Requests:
  
-


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext