Back-Channel Logout Request: Specify how to handle timed out requests / offline RPs

Issue #1605 resolved
Erik Tesar created an issue

After reading the current (and almost final!) draft, as an implementer I am not sure how to handle cases where the OP wants to send a HTTP request to the RP with the Logout Token (as defined in section 2.5) but fails because the connection times out. There are many possible reasons why something like this could happen, for example, if the RP has an outage.

Currently, the draft does not specify how to handle these cases and this could (and almost certainly will) lead to inconsistent behavior between implementations. If I were to implement the draft, I would find it reasonable to try to send the request again after some time since a logout is a pretty important event. But I think it would also reasonable to not re-send the logout event.

In my opinion, the spec must clearly state how to handle these cases to prevent inconsistent behavior and wrong assumptions across implementations.

Comments (6)

  1. Michael Jones
    • changed status to open

    This was discussed during the 22-Aug-22 working group call. @Nat Sakimura asked what the SecEvents specs do in this case, because it's a parallel situation. I agreed that we should behave in the same manner.

    I investigated this after the call and found this text in https://www.rfc-editor.org/rfc/rfc8935.html:

    The SET Transmitter should not retransmit a SET unless the SET Transmitter suspects that previous transmissions may have failed due to potentially recoverable errors (such as network outage or temporary service interruption at either the SET Transmitter or SET Recipient). In all other cases, the SET Transmitter SHOULD NOT retransmit a SET. The SET Transmitter SHOULD delay retransmission for an appropriate amount of time to avoid overwhelming the SET Recipient (see Section 4).

    If people agree, we could add similar language to the Back-Channel Logout specification.

  2. Log in to comment