Re: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt)

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

Thanks, Jim. I'm working on -16 to address this topic and other recent feedback. I'm planning to include text that describes error return conditions.

Scott

> -----Original Message-----
> From: Gould, James <jgould=[e-mail]>
> Sent: Tuesday, July 12, 2022 9:13 AM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail];
> [e-mail]
> Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D
> Action: draft-ietf-regext-rdap-openid-15.txt)
>
> 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.
>
> Scott,
>
> My preference is option 1, where if the request conflicts with the current
> state it needs to result in an error.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://secure-web.cisco.com/146IYbLb06o7EQ5y-
> S9CI7Wv51aAaxl8hFAuOBaHou3sDkfQPFMQu6BUoW4k5ofYC5YtOj6XXRCKD
> HYzan_NZGxdaN0YSvV0pwQb7R9i9kzQj1h9R05Pagm54-
> 27p6uMqOMzoZGv2vinpZe2J8m4PKqdSLdJjiCepHPZ1JM1mtuI50NVmuZ8vRF
> i_0YBy7IEEjGceS0HpXLfup5UC4X63esKGLab9WHmN-
> OZdrNHmUQpEtHd1kkwxdbMiJ2nTpenX/http%3A%2F%2Fverisigninc.com%2
> F>
>
> On 7/7/22, 11:02 AM, "regext on behalf of Hollenbeck, Scott" <regext-
> [e-mail] on behalf of shollenbeck=[e-mail]>
> wrote:
>
>
>     Thanks, Rick. Trimming things up a bit and changing the subject
>     appropriately...
>
>     >>> In the last sentence: Is the client required to wait until the access
>     >>> token has
>     >>> expired before submitting the new login request?  Or can it send
> logout
>     >>> and
>     >>> login back-to-back?  (Or even just a login command while currently
> logged
>     >>> in?)
>
>     >> [SAH] Let's talk about this. What's appropriate behavior? IF the server
>     >> gets a
>     >> "login" during an active session, it can either ignore the second "login",
>     >> or it
>     >> can return an error. Similarly, it the server gets a "logout" when there's
>     >> no
>     >> active session, it can either ignore the "logout" or return an error. I'm
>     >> inclined to return an error to explicitly note that the submitted
>     >> query/command
>     >> wasn't processed as requested.
>
>     > [RW] First off, I will certainly defer to those with more implementation in
>     > this
>     > realm.  However, based on my experience as a user, I would expect a
> login
>     > that
>     > happens during an active session to "just work" and override the
> previous
>     > active
>     > session.  This could happen when I have an active session at the server
> but
>     > the
>     > client browser (with the session) crashes or is otherwise inaccessible.
>     > This
>     > seems better than the alternative:  If the new login request is refused,
>     > then
>     > the user is (essentially) locked out until the session timeout value
>     > expires.
>     > Related, if the server gets a "logout" when there is no active session, I
>     > think
>     > that it should ignore the "logout" (rather than returning an error).  The
>     > thinking being that returning an error is at best useless and at worst could
>     > be
>     > an information leak (aka security risk).
>
>     The document currently describes a session/refresh path segment to
> perform the
>     kind of "override" behavior described above. Having a "login followed by a
>     login" do the same thing seems counter-intuitive. My own experience with
>     server-side session management is that there is no lockout. If the client
>     sends the right HTTP cookie, and the session is still active, there won't be a
>     problem. Another login should be possible if the "old" session gets
> corrupted.
>
>     Let's look at the server-side options again for situations in which the server
>     receives a login followed by a login, or a logout where there's been no
> login,
>     or a refresh without an active session, or a session status without an active
>     session:
>
>     1. Return an error. HTTP includes a 409 (Conflict) response that can be
>     returned if a received request conflicts with the current state of the server.
>
>     2. Accept the request and ignore it. I'm not sure what an appropriate HTTP
>     response code would be for this situation.
>
>     3. Accept the request and do "something".
>
>     Option 1 can be done consistently for all the above request sequences.
> Option
>     2 seems like it could mislead the client into thinking that something has
>     happened unless there is, in fact, an appropriate HTTP response code
> available
>     to describe a no-op (I couldn't find one). Option 3 might be doable if we
> can
>     figure out what the "somethings" are, like processing a second login
> received
>     while a session is active, but the other command sequences present
> problems.
>     As you described above, a logout received without an active session is
>     processed differently than the "login followed by a login" situation. Is that
>     really the best course of action? I think consistent behavior would be
>     preferred.
>
>     Scott
>
>     _______________________________________________
>     regext mailing list
>     [e-mail]
>     https://secure-
> web.cisco.com/1zzMrKkgYlj9VhlxPYw6YLgXo4UAztsC_b_SIIxy0OJCV9U2y757
> cdfeXR-
> TsC4CBsm4x0Yza6BzHsVVgxL47gZOr0EEg3eYwSmzQahgfdLx6MCjcvGofpNEU
> HHZt2Y9yHuOqVA2iKKNDFe4kYtLZHy4rnHFrCuG4pBqHTT16_dC9eQWYrcA7F
> A4k25iCZW0YD3jfVPuhbDXOJoN5T2R71VL27lBZvgz67YLjIgfoeMRu8B5U9-
> yu2qyTAFnQ2bvd/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
> Fregext
>