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.
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.
Best,
Mario
- section 3.1.4.2
OAuth 2.0 implicit flow is deprecated and the specification
recommends using authorization code with PKCE instead.
[SAH] Yes, I can note that it's been deprecated. I haven't found a
formal specification that deprecates the flow, though. Do you have a
reference?
[JB] You will find it in draft-ietf-oauth-security-topics, section 2.1.2:
https://secure-web.cisco.com/1DYHBiq2kf8RE-
PmiDP6jWVcszxoebl1GsQ1EORzNCjN16DCQIwI_meELarNDtZh38p1Uv675ZBFfk
uVWi_2IunAEdo1ayTqvT_RNh9vglBn41dYJYLBihqOwVBt8XRzftXqE77o_Uq3Xkvs
ywcHMq1X3W8xxJgmAfLzq_oqjt6Ja_8a29i_XHJXsXd3YBzWVlX4J8mdwBFcvyxfV
Q5tVTcgUnk2J3jiiCWRCoLJ2G3eSi-2tPZTdfK1cqFgx9S_RyE2O5iQOp7ptY0-
lgLgNH8KrBMWmgd_j6vG15K7537RsKcr2P6A5noNLxavOluaO/https%3A%2F%2
Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-security-topics-
21.html%23name-implicit-grant
The draft for Oauth 2.1 also omits it:
https://secure-web.cisco.com/11Q8G_yBPN3h0EPe77Z2UmxzupXeYvyi_u3wlA-
OB7kB5oGIs9kNLtBu4Rwl6XFKXSeNJtcNCDwxisQeekuI4jeW11ooo1fGx3x0uBxkV
ghQdEiDkXF-cWGTzA82TEKgVx6LeSC-
GuLJLhZSKVjaOIx8DSHUxAQ5tNw3t7A7VyELTdTCnLwh4c1EMdfPJ9UMFc8ZJhKR
r1HAAEt5hpyacw-
C5i4zAq0IA5Q5yPCgiaVQ_SP4nvRY5ZlkpXcJAwJ2XhHRbiNNSBwOmBafCGudI6rR
1Vet412xTbcaEh-
QpbIhsvXfxZSt8Ql4voQwoeqic/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid
%2Fdraft-ietf-oauth-v2-1-07.html%23name-removal-of-the-oauth-20-imp
[SAH] Ah, *drafts*. I don't want to include references to drafts, but I'll see
what I can say about the issue.
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
