+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 <[email protected]> > wrote: > > Hi Piraveena, > >> On Sat, Aug 19, 2017 at 9:42 AM, Piraveena Paralogarajah >> <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> >>>> On Aug 18, 2017, at 5:20 AM, Piraveena Paralogarajah >>>> <[email protected]> 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 >>>> [email protected] >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_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 >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
