Back-channel logout response with HTTP 400

[Bhathiya Jayasekara]

Hi Piraveena,

On Sat, Aug 19, 2017 at 9:42 AM, Piraveena Paralogarajah <
piraveena.14 at cse.mrt.ac.lk> wrote:

> Phil,
>
> Thanks for you response.
>
> But If RP sends HTTP 400 response, then any how OP should handle that. I
> need that implementation in OP side.  Will OP send a logout token again to
> request the RP?
>

I don't think OP should. As per the spec, RP should send 400 response when
***logout token vaidation is failed***. In the 400 response, RP should
mention why the validation was failed. However, upon receiving the 400
response, sending the same logout token back to RP will not be of any use
as it was a validation failure, which means there was something wrong with
the token itself (or a configuration in RP/OP). So I think the only action
OP can take here is to notify there was an error with this particular RP
(maybe you can log it and proceed with other RPs) and it will require a
manual diagnosis to fix the issue if any.

Since id_token anyway has an expiry time, which means problematic RPs will
be logged-out anyway eventually, I don't think this is a major issue.

Thanks,
Bhathiya


>
> Then I will be helpful if you explain how OP will handle this response.
>
> Thanks,
> Piraveena
>
>
> On 18 August 2017 at 22:21, Phil Hunt <phil.hunt at oracle.com> wrote:
>
>> Piraveena,
>>
>> The log out event (which is based on SET Tokens) is informational.  Your
>> question frames the logout as a command rather then an informational event.
>>
>> Some background...
>> Normal functionality should be that the RP can only rejects the SET if
>> the SET cannot be validated or parsed (or unauthorized).  SETs cannot be
>> processed as commands. Thus the only reason for rejection is to let the
>> issuer know their may be a configuration issue that may impact subsequent
>> SET (ie. logout event) delivery.
>>
>> As to whether the logout is successful or not is for the RP to decide
>> within its own domain. Some Clients may decide they do not care about SSO,
>> some will. This is a contextual decision.  This is why SETs in general are
>> framed as FYI type messages rather than commands.  IOW a backchannel logout
>> event means “Subject xyz was logged out by the OP”. While we expect down
>> stream RPs to also cancel the users RP session, they are not obligated to
>> do so.  Likewise an RP logging a user out does not mean the OP must do the
>> same. This depends on the relationship of the RP to the OP and vice-versa.
>>
>> What assurance is there that logout notification worked?
>> I do understand that you are looking for an end-to-end confirmation of
>> success. One of my concerns when the Backchannel Logout spec was approved
>> for implementation was that the current draft does not support SET Delivery
>> which provides assured delivery so we can know a potential logout event was
>> received by an RP — giving some assurance that the logout notification was
>> successful.
>>
>> Phil
>>
>> Oracle Corporation, Identity Cloud Services Architect & Standards
>> @independentid
>> www.independentid.com
>> phil.hunt at oracle.com
>>
>> On Aug 18, 2017, at 5:20 AM, Piraveena Paralogarajah <
>> piraveena.14 at cse.mrt.ac.lk> wrote:
>>
>> Hi all,
>>
>> In Back-channel logout, If the logout is invalid, then RP should respond
>> with HTTP 400 Bad request. Then how P will handle this?
>>
>> It will be helpful if someone can explain the workflow.
>>
>> Thanks,
>> Piraveena
>>
>> --
>> Piraveena Paralogarajah
>> Undergraduate,
>> Department of Computer Science and Engineering,
>> University of Moratuwa,
>> Sri Lanka.
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.op
>> enid.net_mailman_listinfo_openid-2Dspecs&d=DwICAg&c=RoP1YumC
>> XCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJ
>> xPEivzjWwlNKe4C_lLIGk&m=sClsY6Tr0v3GB-kLpFWwMO-NEjex-
>> jDO1cqPjxlmWEw&s=hOwq2HHUdE9Z9wRpLT6enJxwjcZVXa9urw32pTZwmeg&e=
>>
>>
>>
>
>
> --
> Piraveena Paralogarajah
> Undergraduate,
> Department of Computer Science and Engineering,
> University of Moratuwa,
> Sri Lanka.
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20170819/1e306f24/attachment.html>