On Wed, Aug 16, 2023 at 6:48 AM Hollenbeck, Scott <shollenb...@verisign.com> wrote:
> *From:* Murray S. Kucherawy <superu...@gmail.com> > *Sent:* Monday, August 14, 2023 6:23 PM > *To:* Hollenbeck, Scott <shollenb...@verisign.com> > *Cc:* regext@ietf.org; 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. > > 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. > > *[SAH] Yes, I was trying to say “session” without using that word because > token-oriented clients don’t establish sessions in the way the term is used > in the document. On the other hand, would it be clearer to say something > like “within an exchange of requests and responses over a period of time”?* > What's the advice to an implementer of token-oriented clients? It feels like we're trying to describe a time boundary beyond which you can establish a new pattern. What might that be for non-session situations? It's fine if there's no good answer, but I wanted to tease out any opportunity to be more crisp here. > > > > 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. > > *[SAH] How about this: “If one or more remote OpenID Providers are > supported, the RDAP client SHOULD evaluate the additional information > described in Section 4.1 in order to discover the capabilities of the RDAP > server and optionally obtain the set of supported OPs unless that > information is available from a trusted out-of-band source and has already > been processed.”* > Perfect. > > > > > 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. > > *[SAH] OK, how about this: “An OP SHOULD include support for the claims > described in Section 3.1.5 to provide additional information needed for > RDAP End-User authorization; in the absence of these claims clients and > servers MAY make authorization and access control decisions as appropriate > given any other information returned from the OP.”* > Also perfect. > > > > > 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? > > *[SAH] Not that we’re aware of. At least one implementer has confirmed > that it’s more common not explicitly receive anything that identifies the > provider. The alternatives are described in 3.1.4.* > OK so this seems like a good candidate for another SHOULD-unless construction as you did above. Thanks for clarifying. > > > > > 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"). > > *[SAH] Mario helpfully reminded me that Section 5.2.3 describes the > objects to be returned in a response based on success or failure. How about > adding this to 5.1.1 right before the example: “Note that all of the > members of the "farv1_session" data structure are OPTIONAL. See Section > 5.2.3 for instructions describing when to return the minimum set of > members.”* > Thanks, I hadn't connected the two. So the normative prose around this does indeed say an empty object is syntactically legal, but 5.2.3 provides guidance that it should really never happen. Do we need to protect consumers against the possibility of a syntactically valid but semantically nonsense empty reply by giving them guidance about how to handle such a thing? I'm fine if the answer is "no", but I wanted to ask the question. > > 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." > > *[SAH] I’ll make this change: “In any case, an RDAP server SHOULD > invalidate the HTTP cookie associated with the session to prevent its > possible abuse before the cookie times out as part of terminating the > session.”* > (thumbs-up emoji) -MSK
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
