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

[Mike Jones]

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 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<mailto:openid-specs-ab at lists.openid.net>> wrote:

Hello Mike, everyone,

2) is not in line with the discussion in #1487<https://bitbucket.org/openid/connect/issues/1487>, 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<mailto: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 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<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab

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