Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

["Hollenbeck, Scott" <[e-mail]>]

From: Murray S. Kucherawy <[e-mail]>
Sent: Thursday, August 17, 2023 11:56 AM
To: Hollenbeck, Scott <[e-mail]>
Cc: [e-mail]; AlBanna, Zaid <[e-mail]>; 
[e-mail]
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.