> -----Original Message----- > From: Julien Bernard <[email protected]> > Sent: Wednesday, January 18, 2023 11:05 AM > To: Hollenbeck, Scott <[email protected]>; [email protected] > 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 <[email protected]> > >> Sent: Monday, January 16, 2023 2:33 PM > >> To: Hollenbeck, Scott <[email protected]>; [email protected] > >> 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. > >> - 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
