[Openid-specs-ab] [External Sender] Re: Input requested on remaining logout issue: Back-channel logout error handling

[George Fletcher]

I also agree that 2 is not a good option. If we want to communicate the
finer-grained status then I prefer 3.

On Thu, May 5, 2022 at 6:08 AM Mike Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> The “user already logged out” case isn’t an error – it’s a success,
> because logout is idempotent.
>
>
>
> 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.
>
>
>
> I filed https://bitbucket.org/openid/connect/issues/1491
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1491__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCan97MHK8$>
> to track this issue.  Please comment there and/or respond here.
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Joseph Heenan <joseph.heenan at oidf.org>
> *Sent:* Thursday, May 5, 2022 11:53 AM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Mike Jones <Michael.Jones at microsoft.com>; Filip Skokan <
> panva.ip at gmail.com>
> *Subject:* Re: [Openid-specs-ab] Input requested on remaining logout
> issue: Back-channel logout error handling
>
>
>
> 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.
>
>
>
> As a guess at the requirement, I think it’s probably important to
> distinguish very clearly the situations where the client:
>
>
>
>    1. sent an request that would always be invalid request (badly signed
>    jwt, wrong aud, etc)
>    2. sent a request that is technically valid but will never succeed
>    (e.g. user already logged out? User no long exists?)
>    3. sent a request that is technically valid but can’t be processed
>    right now (e.g. some part of the underlying service is down)
>
>
>
> Is that correct and all the situations?
>
>
>
> I agree that ‘2’ is not a good option.
>
>
>
> Joseph
>
>
>
> On 4 May 2022, at 12:53, Filip Skokan via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>
>
> Hello Mike, everyone,
>
>
>
> 2) is not in line with the discussion in #1487
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1487__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaz_diyXE$>,
> we should not be giving meaning to 5xx HTTP status codes.
>
>
>
> I think 1) is fine but I do recognize 3) as a valid option to allow for
> transmitting deployment-specific states.
>
>
> Best,
> *Filip*
>
>
>
>
>
> On Wed, 4 May 2022 at 10:20, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> I’d like people to weigh in on whether to merge
> https://bitbucket.org/openid/connect/pull-requests/169/simplified-error-handling-to-use-http-400
> <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$>
> as-is or whether to modify it to make it possible to once again distinguish
> between invalid requests and failed requests.
>
>
>
> 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.
>
>
>
> In summary, please respond indicating your preference for:
>
>    1. Use HTTP 400 Bad Response for all error responses.
>    2. Use HTTP 400 Bad Response for invalid requests and HTTP 501 Not
>    Implemented for unsuccessful logout requests.
>    3. 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.
>
>
>
>                                                        Thank you,
>
>                                                        -- Mike
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaX51UKt4$>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
>
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!MlZLHLB8J8xCaA030TIUTR9ILwd3dg3PQnlIjN9jVPi3H3kA3wayfmmhHq_BZ7_LXuH0d-odBHhPp-RoXbHpw3TI-HRWRlCaX51UKt4$
>

______________________________________________________________________



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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220505/2eb6cb9a/attachment.html>