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? [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.”? 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.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
