Thanks Phil and Bhathiya. On 19 August 2017 at 21:28, Phil Hunt (IDM) <[email protected]> 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 <[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 >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0lDDt5fABbxtONo4y9OIqWdhbMAh74pLEUGzY5hAXmw&s=SwFPhRZx4Tl5t27ozorxCDAaEmk47T7kOXZD157G4dU&e=> >>> [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.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 >> [email protected] >> 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.
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
