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=40verisign....@dmarc.ietf.org> > Sent: Tuesday, July 12, 2022 9:13 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; rwilh...@pir.org; > regext@ietf.org > 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 > jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE- > B4BA42740803/jgo...@verisign.com> > > 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- > boun...@ietf.org on behalf of shollenbeck=40verisign....@dmarc.ietf.org> > 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 > regext@ietf.org > https://secure- > web.cisco.com/1zzMrKkgYlj9VhlxPYw6YLgXo4UAztsC_b_SIIxy0OJCV9U2y757 > cdfeXR- > TsC4CBsm4x0Yza6BzHsVVgxL47gZOr0EEg3eYwSmzQahgfdLx6MCjcvGofpNEU > HHZt2Y9yHuOqVA2iKKNDFe4kYtLZHy4rnHFrCuG4pBqHTT16_dC9eQWYrcA7F > A4k25iCZW0YD3jfVPuhbDXOJoN5T2R71VL27lBZvgz67YLjIgfoeMRu8B5U9- > yu2qyTAFnQ2bvd/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2 > Fregext > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
