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

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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 7/7/22, 11:02 AM, "regext on behalf of Hollenbeck, Scott" <regext-bounces@ietf.org on behalf of shollenbeck=40verisign.com@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_SIIxy0OJCV9U2y757cdfeXR-TsC4CBsm4x0Yza6BzHsVVgxL47gZOr0EEg3eYwSmzQahgfdLx6MCjcvGofpNEUHHZt2Y9yHuOqVA2iKKNDFe4kYtLZHy4rnHFrCuG4pBqHTT16_dC9eQWYrcA7FA4k25iCZW0YD3jfVPuhbDXOJoN5T2R71VL27lBZvgz67YLjIgfoeMRu8B5U9-yu2qyTAFnQ2bvd/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext