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://en.wikipedia.org/wiki/Robustness_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.
- 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://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-21.html#name-implicit-grant
The draft for Oauth 2.1 also omits it:
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-07.html#name-removal-of-the-oauth-20-imp
- section 4.1
I'm not that familiar with OIDC and that's might be the issue but I don't
really
understand the need for additionalAuthorizationQueryParams.
Is there a way to clarify this or a reference that would help? I think this
might
be a question for Pawel.
[SAH] I hope he answered that question to your satisfaction.
[JB] Yes
- sections 4.1, 5.2.1 and 5.2.2
If I understood correctly, farv1_id and farv1_iss query parameters can only
be
used if providerDiscoverySupported and issuerIdentifierSupported are true.
IMHO it would ease the understanding to add a reference to those server
capabilities in the query parameters sections.
[SAH] OK, can do.
[JB] Thanks
Julien
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
