From nobody Thu Jul 7 08:02:05 2022 Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F77C13CF60 for ; Thu, 7 Jul 2022 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh41T8eqj_sP for ; Thu, 7 Jul 2022 08:01:59 -0700 (PDT) Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEE8C1594AF for ; Thu, 7 Jul 2022 08:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3654; q=dns/txt; s=VRSN; t=1657206120; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BMBQtEavvGB/mdbPRFgyEEqvkf5t2nHHu9C5jytlRyQ=; b=fshHe1poYn0aMzhSUEiUC4/y5h+6RtK3Czc+1FbxaGrP0LU2BQQoFnAe qZpVhPR7NPLBe1CMYFLrs+hFmFvb708oNcR9X4I+36O8rbhTyY1uz2E2C aS6XpU6T8PwgD385Q6WE8vRLaLLxurX0/lQUxjSecgI9FFqsZUkzTeWd4 tT3zZIpRKsBZTt5HQkxmsSnWaQtDbaiSoa4nBv5ZaVffhJ6o3SqICprL7 9g93mZiklMSmrwO0dmMj+3QZ8M+YggJ4chtIQ8PEH2NeLVM3bp4nkhwVX fQjlbMNp2lfSHM3499E6CMK5ZVMYYPDuIo8pm0AbrpJSagHFra5RCNCZd A==; IronPort-Data: A9a23:KYgJZ6/qLkJRiQEJ9EgsDrUDx3+TJUtcMsCJ2f8bNWPcYEJGY0x3n WZJUWiEafvYZ2qmc4h3Ooqw9h9Tu5+Ez9ZkSAo5qikxFiIbosf7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVEOCXhqoPUUIYoAAgoLeNfYHpn2EgLd9IR2NYy24DmW1zV4 7senuWEULOb828sWo4rw//bwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWHq 9Prl9lVyEuCpktwVYn1+lrMWhZirrb6ZWBig1IIA/Ty2kAqSiYais7XP9JEAatbZqngc3mcB 7yhuLTpITrFMJEgl8wXVwRpFHpOIJdK/bH1PGCPk+mO31X/Ji6EL/VGVCnaPKUywMAuPkdjx aRCbi4GaQqbweu6hqyhUe8qjcMmRCXpFNpH/Cg/lneAUK1gHcGrr6bivLe02B8rhsdKGfvYb ccSahJxYQ7BeBxAPBEcD5dWcOKA3ySjImQJ9AP9Sawfu3fUwjFvzJbRIv2WKuKOYfgMs02bj zeTl4j+KlRAXDCF8hK/7XOohuLLmAvjWZhUE6e3ntZwjVKe1nA7CRAKWx28u/bRt6Klc9hFL RUL/Cc+9fJ371KxCNz8RFiypziOpBhFHcRKCOt84waIokbJ3zuk6qE/ZmYpQLQbWAUeH1TGC nfhcwvVOAFS IronPort-HdrOrdr: A9a23:XCrhBK2YCZWa3wrN9X5poQqjBI0kLtp133Aq2lEZdPUMSL36qy ncpoV46faSskdpZJhAo6HnBEDuexLhHPJOi7X5Xo3SJDUO2lHJEGgK1+KLqAEIcBeTygcp78 ldmt9FZ+EYY2IWsS+w2njcLz9p+qjizEmHv5a480tQ X-IronPort-AV: E=Sophos;i="5.92,253,1650945600"; d="scan'208";a="15491949" Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Thu, 7 Jul 2022 11:01:57 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.024; Thu, 7 Jul 2022 11:01:56 -0400 From: "Hollenbeck, Scott" To: "Rwilhelm@PIR.org" , "regext@ietf.org" Thread-Topic: Login/Logout Processing (was RE: [regext] I-D Action: draft-ietf-regext-rdap-openid-15.txt) Thread-Index: AdiSElo+n/dwjcKFSB2ZlqyqUWiQFg== Date: Thu, 7 Jul 2022 15:01:56 +0000 Message-ID: <102c42b35987492fb67f79834921d3e1@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt) X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2022 15:02:03 -0000 Thanks, Rick. Trimming things up a bit and changing the subject=20 appropriately... >>> In the last sentence: Is the client required to wait until the access=20 >>> token has >>> expired before submitting the new login request? Or can it send logout= =20 >>> and >>> login back-to-back? (Or even just a login command while currently logg= ed=20 >>> in?) >> [SAH] Let's talk about this. What's appropriate behavior? IF the server= =20 >> gets a >> "login" during an active session, it can either ignore the second "login= ",=20 >> or it >> can return an error. Similarly, it the server gets a "logout" when there= 's=20 >> 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=20 >> query/command >> wasn't processed as requested. > [RW] First off, I will certainly defer to those with more implementation = in=20 > this > realm. However, based on my experience as a user, I would expect a login= =20 > that > happens during an active session to "just work" and override the previous= =20 > active > session. This could happen when I have an active session at the server b= ut=20 > the > client browser (with the session) crashes or is otherwise inaccessible.=20 > This > seems better than the alternative: If the new login request is refused,= =20 > then > the user is (essentially) locked out until the session timeout value=20 > expires. > Related, if the server gets a "logout" when there is no active session, I= =20 > 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 co= uld=20 > be > an information leak (aka security risk). The document currently describes a session/refresh path segment to perform = the=20 kind of "override" behavior described above. Having a "login followed by a= =20 login" do the same thing seems counter-intuitive. My own experience with=20 server-side session management is that there is no lockout. If the client=20 sends the right HTTP cookie, and the session is still active, there won't b= e a=20 problem. Another login should be possible if the "old" session gets corrupt= ed. Let's look at the server-side options again for situations in which the ser= ver=20 receives a login followed by a login, or a logout where there's been no log= in,=20 or a refresh without an active session, or a session status without an acti= ve=20 session: 1. Return an error. HTTP includes a 409 (Conflict) response that can be=20 returned if a received request conflicts with the current state of the serv= er. 2. Accept the request and ignore it. I'm not sure what an appropriate HTTP= =20 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. Opti= on=20 2 seems like it could mislead the client into thinking that something has=20 happened unless there is, in fact, an appropriate HTTP response code availa= ble=20 to describe a no-op (I couldn't find one). Option 3 might be doable if we c= an=20 figure out what the "somethings" are, like processing a second login receiv= ed=20 while a session is active, but the other command sequences present problems= .=20 As you described above, a logout received without an active session is=20 processed differently than the "login followed by a login" situation. Is th= at=20 really the best course of action? I think consistent behavior would be=20 preferred. Scott