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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Aug 17, 2023 at 12:56 PM Hollenbeck, Scott <[e-mail]>
wrote:

> *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?*
>

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