Back-channel logout response with HTTP 400

Sat Aug 19 16:05:46 UTC 2017

Thanks Phil and Bhathiya.

On 19 August 2017 at 21:28, Phil Hunt (IDM) <phil.hunt at oracle.com> wrote:

> +1.
>
> The OP (transmitter) only needs to know if the RP is unable to understand
> or validate the event. It does not need to know the outcome.
>
> Phil
>
> On Aug 19, 2017, at 12:14 AM, Bhathiya Jayasekara <tobhathiyaj at gmail.com>
> wrote:
>
> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0lDDt5fABbxtONo4y9OIqWdhbMAh74pLEUGzY5hAXmw&s=SwFPhRZx4Tl5t27ozorxCDAaEmk47T7kOXZD157G4dU&e=>
>>> 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-jDO1cqP
>>> jxlmWEw&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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0lDDt5fABbxtONo4y9OIqWdhbMAh74pLEUGzY5hAXmw&s=gLiffvJAQLZHc25OyAoZeC6DkRFtFCINZoEY7kLvqu0&e=>
>>
>>
>

-- 
Piraveena Paralogarajah
Undergraduate,
Department of Computer Science and Engineering,
University of Moratuwa,
Sri Lanka.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20170819/2523d647/attachment.html>