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