<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Unfortunately since an application typically<div>- will have a combination of front and back-end state which is removed during logout</div><div>- the back end state is typically referenced exclusively by front end state</div><div>- “already logged out” on the front channel is represented typically by the absence of front end state</div><div>- cookies may temporarily or permanently be removed by user action or browser policy</div><div><br></div><div>We typically can’t make a front channel determination that the user is already logged out, just that the attempt to clean up session state failed. </div><div><br></div><div>Indeed, new browser cookie policy may very well mean that their session will be alive and well if they navigate back to the site. </div><div><br></div><div>For back channel, the caveat that one may have only asynchronously _initiated_ a logout - the deletion of front end state will need to wait until if/when the application is interacting with the browser. </div><div><br></div><div>These are FWIW why I am a fan of the proposals to send back-end signals that tokens are to no longer be relied upon, and why the contributed DTVA work took this approach. </div><div><br></div><div>Wrt error reporting, option #3 seems most appropriate. We are not manipulating sessions as HTTP resources so HTTP error codes alone cannot provide fidelity. </div><div><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On May 5, 2022, at 4:08 AM, Mike Jones via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:479536341;
mso-list-template-ids:2122198086;}
@list l0:level2
{mso-level-start-at:0;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-start-at:0;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-start-at:0;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-start-at:0;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-start-at:0;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-start-at:0;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-start-at:0;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-start-at:0;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:664746506;
mso-list-template-ids:-979060750;}
@list l1:level2
{mso-level-start-at:0;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-start-at:0;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-start-at:0;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-start-at:0;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-start-at:0;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-start-at:0;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-start-at:0;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-start-at:0;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">The “user already logged out” case isn’t an error – it’s a success, because logout is idempotent.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The remaining question is whether we want to be able to distinguish between syntactically invalid requests and requests that failed for other reasons. If so, we should add “error” and “error_description” parameters.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I filed <a href="https://bitbucket.org/openid/connect/issues/1491">
https://bitbucket.org/openid/connect/issues/1491</a> to track this issue. Please comment there and/or respond here.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Thanks,<o:p></o:p></p>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Joseph Heenan <joseph.heenan@oidf.org> <br>
<b>Sent:</b> Thursday, May 5, 2022 11:53 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>Cc:</b> Mike Jones <Michael.Jones@microsoft.com>; Filip Skokan <panva.ip@gmail.com><br>
<b>Subject:</b> Re: [Openid-specs-ab] Input requested on remaining logout issue: Back-channel logout error handling<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m struggling a little with this conversation because I don’t think I understand what is meant by ‘failed request” or the required behaviour here.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As a guess at the requirement, I think it’s probably important to distinguish very clearly the situations where the client:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
sent an request that would always be invalid request (badly signed jwt, wrong aud, etc)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
sent a request that is technically valid but will never succeed (e.g. user already logged out? User no long exists?)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
sent a request that is technically valid but can’t be processed right now (e.g. some part of the underlying service is down)<o:p></o:p></li></ol>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is that correct and all the situations?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree that ‘2’ is not a good option.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Joseph<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 4 May 2022, at 12:53, Filip Skokan via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hello Mike, everyone,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2) is not in line with the discussion in <a href="https://bitbucket.org/openid/connect/issues/1487" target="_blank">
#1487</a>, we should not be giving meaning to 5xx HTTP status codes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think 1) is fine but I do recognize 3) as a valid option to allow for transmitting deployment-specific states.<o:p></o:p></p>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Best,<br>
<b>Filip</b><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, 4 May 2022 at 10:20, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’d like people to weigh in on whether to merge
<a href="https://bitbucket.org/openid/connect/pull-requests/169/simplified-error-handling-to-use-http-400" target="_blank">
https://bitbucket.org/openid/connect/pull-requests/169/simplified-error-handling-to-use-http-400</a> as-is or whether to modify it to make it possible to once again distinguish between invalid requests and failed requests.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If you want to be able to distinguish between these two cases, do you want to use “error” and “error_description” parameters, as suggested by Andrii, or to use 400 and 501 HTTP
response codes, as the specification currently does.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In summary, please respond indicating your preference for:<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
Use HTTP 400 Bad Response for all error responses.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
Use HTTP 400 Bad Response for invalid requests and HTTP 501 Not Implemented for unsuccessful logout requests.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
Use HTTP 400 Bad Response for all error responses, but use “error” and “error_description” body parameters to distinguish between invalid and failed logout requests.<o:p></o:p></li></ol>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Thank you,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> -- Mike<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span>Openid-specs-ab@lists.openid.net</span><br><span>https://lists.openid.net/mailman/listinfo/openid-specs-ab</span><br></div></blockquote></div></div></body></html>