On Thu, Aug 17, 2023 at 12:56 PM Hollenbeck, Scott <shollenb...@verisign.com> wrote:
> *From:* Murray S. Kucherawy <superu...@gmail.com> > *Sent:* Thursday, August 17, 2023 11:56 AM > *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 > > > > *[SAH] [snip]* > > 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. > > *[SAH] What I’m trying to say here is that a client shouldn’t mix > token-oriented requests in between session-oriented login and logout > requests. Maybe that’s the best way to say it: “Clients MAY operate as > either session-oriented or token-oriented clients, but they MUST do so > consistently by not mixing token-oriented and session-oriented requests > while interacting with an OP.” Does that work?* > That seems way better to me. > > > > > *[SAH] [snip]* > > > > > > > > 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. > > *[SAH] OK, how about this: “Alternatively, if mapping of an End-User's > identifier is not possible, or not supported by the RDAP server, the RDAP > server SHOULD support explicit specification of a remote OP by the RDAP > client in the form of a query parameter as described in Section 5.2.2 > unless the remote OP has been identified using an out-of-band mechanism.”?* > Works for me. > > > > > > > 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. > > *[SAH] I think we’re safe with not saying any more that’s already in RDAP > itself: if a client sees something it doesn’t expect, it can safely be > ignored.* > Sounds good. Thanks for working through all this with me. I'll send this to Last Call when the new version goes up. -MSK
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
