Facebook as you know already has a form of single-sign-out. When I log out of <a href="http://lala.com">lala.com</a>, I'm asked whether I want to log out of <a href="http://lala.com">lala.com</a> only, or both <a href="http://lala.com">lala.com</a> and Facebook. This seems user friendly enough. Although it leaves out the option of "log out of <a href="http://lala.com">lala.com</a>, Facebook, and everything else Facebook has helped you log into."<div>
<br></div><div>One way this could be done is a simple form of OAuth, where the RP is the service provider and the OP is the consumer. And the OP is thus authorized to remote log out the user. It needs to be OAuth, or something like that, rather than a redirect because we can't have the OP sequentially redirect the user agent to every RP to log them out of each one. The OP needs to remotely be able to log the user out. </div>
<div><br></div><div>In fact, this has some other interesting scenarios as well. If the user logs out of the OP, all RPs could be immediately logged out. If the user's account was compromised, he could even remotely log into the OP and force log out <i>all</i> RPs that have received positive assertions from that OP. For this to work, the OP and RP would have had to agree on the maximum session length at the RP.</div>
<div><br></div><div>Thoughts?<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Wed, Sep 30, 2009 at 5:33 AM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Steven,<br>
<br>
The real problem is that it's difficult to do it in a way that would be certain to really clear all the various sessions scattered around in a loosely coupled federated environment, and doing "something" may be worse than doing "nothing", if "nothing" makes it clear that the user need to terminate their browser session, for example. If some RP's don't go to the trouble of associating their application sessions with the provider's sessions, or some OP's don't store the list of RP endpoints, or if the browser gets stranded at some point and is unable to clear a cookie, etc. etc. etc. then the deployer or user's expectations may not be met.<br>
<br>
Unlike some others on the Shib team, I believe it's still important to implement some form of SLO. So long as deployers are aware of the limitations, it will address some use cases(such as Jonathan's, where they sound to have relatively tight control of the environment), which is a win.<br>
<br>
It's not near the top of my list of things that I'd like to see added to the OpenID protocol, but it's definitely feasible with the right caveats, and there are many examples to learn from out there.<br>
<br>
Thanks for taking the time to read our piles of word salad,<br><font color="#888888">
Nate.</font><div class="im"><br>
<br>
On Sep 30, 2009, at 9:56 AM, Steven Livingstone-Perez wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It does seem to me, particularly from reading those documents that despite the technical difficulties outlined there is a potential roadmap to SLO in OpenID - or at least a start :-)Need defining (if not already in the process) and much would be implementation recommendations rather than protocol.<br>
</blockquote>
<br></div><div><div></div><div class="h5">
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div></div></blockquote></div><br></div>