<div dir="ltr"><div dir="ltr">I also agree that 2 is not a good option. If we want to communicate the finer-grained status then I prefer 3.<input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Thu, May 5, 2022 at 6:08 AM Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_5865276022143122553WordSection1">
<p class="MsoNormal">The “user already logged out” case isn’t an error – it’s a success, because logout is idempotent.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I filed <a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1491__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCan97MHK8$" target="_blank">
https://bitbucket.org/openid/connect/issues/1491</a> to track this issue. Please comment there and/or respond here.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> Thanks,<u></u><u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Joseph Heenan <<a href="mailto:joseph.heenan@oidf.org" target="_blank">joseph.heenan@oidf.org</a>> <br>
<b>Sent:</b> Thursday, May 5, 2022 11:53 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>; Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] Input requested on remaining logout issue: Back-channel logout error handling<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></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.
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
sent an request that would always be invalid request (badly signed jwt, wrong aud, etc)<u></u><u></u></li><li class="MsoNormal">
sent a request that is technically valid but will never succeed (e.g. user already logged out? User no long exists?)<u></u><u></u></li><li class="MsoNormal">
sent a request that is technically valid but can’t be processed right now (e.g. some part of the underlying service is down)<u></u><u></u></li></ol>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Is that correct and all the situations?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I agree that ‘2’ is not a good option.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Joseph<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<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" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hello Mike, everyone,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">2) is not in line with the discussion in <a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1487__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaz_diyXE$" target="_blank">
#1487</a>, we should not be giving meaning to 5xx HTTP status codes.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Best,<br>
<b>Filip</b><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">I’d like people to weigh in on whether to merge
<a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/169/simplified-error-handling-to-use-http-400__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaIhAqFB0$" 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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">In summary, please respond indicating your preference for:<u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
Use HTTP 400 Bad Response for all error responses.<u></u><u></u></li><li class="MsoNormal">
Use HTTP 400 Bad Response for invalid requests and HTTP 501 Not Implemented for unsuccessful logout requests.<u></u><u></u></li><li class="MsoNormal">
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.<u></u><u></u></li></ol>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> Thank you,<u></u><u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaX51UKt4$" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaX51UKt4$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaX51UKt4$</a> <br>
</blockquote></div></div>
<HR><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><BR>
<tr><BR>
<font color="#404040">The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.</font></td><BR>
</tr><BR>
</table><BR>