<div dir="ltr"><br><br><div class="gmail_quote">On Wed Feb 25 2015 at 18:39:52 Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Sorry, took me a while to get to looking at this (even at 2 pages). <br><br></div><div>In general this looks pretty good and isn't too far off from the implementation we did. Ours is img/get based and has no sid or equivalent. But it's pretty close otherwise.  A few comments and questions follow...</div><div><br>"Several OpenID Connect implementers have requested a front channel 
logout mechanism that doesn’t use JavaScript. " -> it's not the use 
of JavaScript, per se, but rather the nature of how JavaScript is used. 
The session management spec pretty much requires that an RP have Connect
 aware JavaScript<span style="font-size:11pt;line-height:115%;font-family:Calibri">
 on every page, which is a non-starter for many scenarios that involve 
low-touch or no-touch integration with existing applications. </span><br><br><div>RPs/Clients can have multiple redirect_uris and, if 
they have different domains, it can be problematic for a front-channel 
logout mechanism that's relying on cookies when only one logout_uri is 
allowed. We allowed for multiple logout uris in our implementation to 
account for this. I can't remember if we just hit them all or try and 
chose from among them based on the redirect_uris used in the corresponding SSOs. I think the former. I don't know if that's something that a logout spec should account for but it's a sitation that can fall out of multiple redirect_uris.</div></div></div></div></div></blockquote><div><br></div><div>Couldn't the logout_uri do redirects to cope for that situation?</div><div>Something like "<a href="http://google.com">google.com</a> redirects to <a href="http://youtube.com">youtube.com</a>, which serves an empty image" (or <a href="http://yahoo.com">yahoo.com</a> redirects to <a href="http://flickr.com">flickr.com</a>, or <a href="http://microsoft.com">microsoft.com</a> redirects to <a href="http://live.com">live.com</a> if you prefer ;-) ).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>If no "post_logout_redirect_uri" is provided to the "end_session_endpoint", is it expected that the OP keeps the user post logout (rather than sending them back to the RP)?  I kind of assume so but it's not practically clear (to me anyway) in this doc or in Session Management. FWIW, the implementation we did always keeps the user at the OP after logout. <br></div></div></div></div></blockquote><div><br></div><div>FWIW, I assumed the same (we do redirect to the post_logout_redirect_uri though after logout)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div><span style="font-size:11pt;line-height:115%;font-family:Calibri"><br></span></div><span style="font-size:11pt;line-height:115%;font-family:Calibri">"STS" is a bit of an overloaded term that means different things to different people/groups/companies. In a real spec its should be defined clearly or avoided.<br></span></div></div></div></blockquote><div><br></div><div>I, for one, have no idea what STS means.</div></div></div>