Thanks for the review, Murray. Notes below.
Scott From: regext <regext-boun...@ietf.org> On Behalf Of Murray S. Kucherawy Sent: Saturday, August 12, 2023 7:58 PM To: regext@ietf.org Cc: AlBanna, Zaid <zalba...@verisign.com>; regext-cha...@ietf.org Subject: [EXTERNAL] Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23 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. AD review: I note that the shepherd writeup's last question points out the creation of a registry using Specification Required rules, and thus doesn't need a designated expert, referencing RFC 8126 Section 4.6. However, that section of that RFC says: This policy is the same as Expert Review, with the additional requirement of a formal public specification. In addition to the normal review of such a request, the designated expert will review the public specification and evaluate whether it is sufficiently stable and permanent, and sufficiently clear and technically sound to allow interoperable implementations. So yes, we do need to appoint designated expert(s) and this document needs to include any advice that they should have when reviewing specifications. Such advice is missing here. Do you want to add any? [SAH] Yes, that’s my mistake, confusing “specification required” with “RFC required”. I need to add text that instructs the expert to review specifications to ensure that any request to register a value meets the requirements described in Section 3.1.5.1. I also note from the writeup that you attempted to get OAUTH WG input but were not successful. I will raise this to the SEC ADs and ask them for advice as soon as I've sent this. For that matter, you might want to trigger an early SECDIR review, although there's going to be one as part of Last Call anyway. In Section 3.1.2, what is a "given period of interaction"? [SAH] The intention here is to use encourage clients to use one form of interaction or the other consistently in the course of sending RDAP queries and receiving RDAP responses over a given period of time. For example, don’t mix in token-oriented actions while in the middle of a session-oriented interaction. In Section 3.1.3, bullet 1, "OpenID OpenID Providers". [SAH] Will fix. In Section 3.1.3, bullet 1, why is that only a SHOULD? Why might I not do this? [SAH] A client might have received that information from some other source, such as published documentation provided by a server operator, and it may hard-code certain preferences. The SHOULD exists to encourage dynamic processing of the returned information, but it’s not an absolute requirement. In Section 3.1.4, why is that only a SHOULD? Why might I not do this? [SAH] This SHOULD exists because it’s possible to make identification, authentication, and authorization decisions without the additional RDAP information described in Section 3.1.5. An end-user who presents an identifier like a Gmail address, for example, will find that their credential “works”, but their access to information can be limited due to the lack of finer-grained authorization information. In Section 3.1.4.1, same question. [SAH] This SHOULD exists because other methods exist to discover the provider. The server might not support the query parameter because it can determine the issuer from the given credential (Gmail maps to Google, for example), or it may only support a single identity provider. In Section 5.1.1, the entire object is OPTIONAL. This doesn't seem right. Would there be any practical use to such a thing? [SAH] A token-oriented client won’t ever establish a session. In Section 5.5, why is that SHOULD not a MUST? [SAH] There are two SHOULDs in 5.5. They’re not MUSTs because the cookies will eventually time out and become invalid without any specific client or server actions. MUSTs would be stronger, though, and I’m open to making that change if you think it’s a better approach. In Section 9.2, at least in the HTML version I looked at, the two registrations are run together. It would be helpful to readers to separate them somehow, at least with a blank line, though you could also make each a subsection. [SAH] I’ll see what I can do. Thanks for including Section 10. -MSK, ART AD On Mon, Aug 7, 2023 at 6:36 AM James Galvin via Datatracker <nore...@ietf.org <mailto:nore...@ietf.org> > wrote: James Galvin has requested publication of draft-ietf-regext-rdap-openid-23 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ <https://secure-web.cisco.com/1xD0WuRO0D9ku8ke5mha8PSiP5miORfbei664dq-OKMRZr4w-R2pDY91ISuF4KbtAu9EcPzbfNNHcLJudnjoZcuj4A2NxpKC2dLwm8EJg82YeGj_6EKb8fVk1Pf1Nan8FnG3pWkatm1UlWodaqLqLSqKcX3aM-0BWvthqV8ozYsKM2oflYMP1ASNFz_RSQKhzGPC0uysuGKJ8XavBOgEmnxL-5qtEgbg0JMufVZfbhzrHj9X6hJgVTqLTL0ykA-jQdmhqtj4cbsPAoN1ce7MNMC8p4xRysWKwgvUiwltxlow/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-openid%2F>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
