Discussion on whether the backchannel draft may need to be updated has not happen yet. But here is how secevents proposes to handle it...https://datatracker.ietf.org/doc/draft-ietf-secevent-delivery/
Phil > On Aug 18, 2017, at 9:12 PM, 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? > > 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
