Hi Scott,
please find my comments below.
Il 26/01/2023 20:10, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Sent: Tuesday, January 24, 2023 9:57 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>; jbern...@cofomo.com;
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-
20.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,
Il 18/01/2023 17:17, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Julien Bernard<jbern...@cofomo.com>
Sent: Wednesday, January 18, 2023 11:05 AM
To: Hollenbeck, Scott<shollenb...@verisign.com>;regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action:
draft-ietf-regext-rdap-openid- 20.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.
Thanks Scott. My answers inline.
On 18/01/2023 09:24, Hollenbeck, Scott wrote:
Thanks for the feedback and questions, Julien. More below.
-----Original Message-----
From: Julien Bernard<jbern...@cofomo.com>
Sent: Monday, January 16, 2023 2:33 PM
To: Hollenbeck, Scott<shollenb...@verisign.com>;regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action:
draft-ietf-regext-rdap-openid- 20.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,
I read the full draft recently and I have a couple of comments
related to -20 and older versions as well. Sorry if those have
already been discussed previously on the mailing list.
- section 3.1.2: "Servers MUST support both types of client."
Is there a reason for this to be a MUST? I think it could prevent
people from implementing the spec (or a part of it) as this is a
pretty huge requirement.
[SAH] That requirement is based on the robustness principle, aka
Postel's
Law:
https://secure-
web.cisco.com/1yZtJRmWuxFVBrupACQRNwf8lBoBQmKUYJblANZa5
l4nfFT5tunPDMNc_16e-
HlegBKEm8trlSL4AKVwCxCO4SZrVe72jG3K7LQdJNqUYz26IeO
mrvO9R7GRjXYPt3dt1YcHaOOh1Zr2KLsQR8Ipvbd4wJk5bUnoVMfPiSdsLgFyYR_n
X27RT
H1dD8Rdum_8IdUgRq9qth2BaNaC-
5Z88xNaMiC5ubpC_IqCMNDmmet4ZaDX_D_uwwFRBcR
NfQlwDNXaYTNLeGBrK4KlcTO4aDHObX23xxSGHXaWNBvLGB0-
eioedCMH6-
oQHO1dXVyJX
/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRobustness_principle
Yes, it's more work for servers, but it makes things easier for clients.
[JB] I agree that the server development should follow Postel's law
but why not adding this as a capability in the
farv1_openidcConfiguration structure, so what is implemented would be
clear and won't break the principle.
This concern is based on feedback I got from developers, including
people maintaining RDAP servers. I think we may end up with partial
implementations without a way to be aware that only one client type is
supported.
[SAH] I'd really like to hear what others have to say about this. A server
that
only supports one type of client won't be accessible to some number of end
users. That doesn't sound like a good thing.
[ML] I support Julien's proposal.
The token-based approach will be implemented with little to no effort while
the
session-based approach will take much more time.
IMO, separating the implementation of the two approaches would enable
implementers to easily comply with the spec.
In addition, the token-based approach might be the only one practicable due
to
the server policy of accepting the authenticated requests from trusted
clients
only.
[SAH] Thanks for the feedback, Mario. I still don't think this is a good idea,
but if mine is a minority opinion I'll update the text to remove the MUST and
include config info so a server can describe the type(s) of clients it
supports. Please folks, share an opinion now if you have one. Should a server
be able to support one type of client only?
As an aside note, it doesn't look clear to me which RDAP features defined
for
the session-based approach are still valid in the token-based approach. I
mean,
the farv1_* endpoints seem meaningless to me while farv1_dnt and farv1_qp
parameters are still relevant.
[SAH] The text was restructured in -20 in an attempt to make that clear. The
query parameters are described in the "Common Protocol Features" section, so
yes, they're common to both. The different endpoints are described in sections
titled "Protocol Features for Session-Oriented Clients" and "Protocol Features
for Token-Oriented Clients". Did I miss something such that the distinction
remains unclear?
[ML] Section 7 looks a bit misleading to me as it includes text
(starting with "A client can end .." and ending with " in .. RFC 6265")
regarding only the session-based approach.
In addition, I wonder if the concept of "RDAP session" should be
clarified as it has a different meaning according to the approach used.
In the session-based approach, the RDAP session is a typical HTTP
session starting with a farv1_session/login request and ending either
with a farv1_session/logout or due to timeout.
In the token-based approach, the RDAP session corresponds to the bearer
token lifespan.
Best,
Mario
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. 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
