Hey Scott,
On Mon, Aug 14, 2023 at 5:54 AM Hollenbeck, Scott <shollenb...@verisign.com> wrote: > 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.* > "Revised I-D Needed". :-) > > > 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.* > OK, I thought you might have actually been trying to say "session". But the same text could legitimately mean, say, "month", or "before an unspecified timeout expires"; in the latter case, I'd be wondering what timeout you mean. > > > 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.* > So this isn't an interoperability requirement? I suggest making it clear why I might implement something deviating from this advice, and why that's okay. > > > 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.* > OK, same sort of outcome then, I think. > > > 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.* > But if I use one of those other methods, is there any degradation to interoperability or security? > > > 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.* > Does that mean at least one of the object's attributes will always be set? If so, a MUST at the bottom indicating such would tighten this up (e.g., "X is OPTIONAL, Y is OPTIONAL, Z is OPTIONAL, but you MUST set at least one of them"). > 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.* > Oops, I missed the first one. I think the first one is fine because the consequences of deviation are made clear. It's the second one that caught my attention. But you mentioning the timeout changes things a bit. Is it the case that you SHOULD invalidate the cookie to prevent its possible abuse before the timeout comes? If so, then just saying that satisfies my issue. Otherwise, and without thinking about timeouts, I was thinking "Why would you not invalidate a cookie you don't need anymore?" and the answer may well be "Because it'll time out soon anyway." > > 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.* > -MSK
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
