[OpenID] Logout Use Case

[Andrew Arnott]

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.
--
Andrew Arnott
"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


On Wed, Sep 30, 2009 at 7:33 AM, Joost van Dijk <joost.vandijk at surfnet.nl>wrote:

> Andrew Arnott wrote:
> > Facebook as you know already has a form of single-sign-out.  When I log
> > out of lala.com <http://lala.com>, I'm asked whether I want to log out
> > of lala.com <http://lala.com> only, or both lala.com <http://lala.com>
> > and Facebook.  This seems user friendly enough.  Although it leaves out
> > the option of "log out of lala.com <http://lala.com>, Facebook, and
> > everything else Facebook has helped you log into."
>
> It may be interesting to take a look at the work Andreas Solberg has
> done with SLO for identity federations (not OpenID, but SAML 2.0). He
> has some real-world experience with SLO, including the "everything else"
> scenario.
>
> He has a demo online:
>
> http://rnd.feide.no/content/how-create-a-fancy-iframe-demo-a-z
>
> See the bottom of that page...
>
> Cheers,
>
> --
> Joost van Dijk
> SURFnet
>
> >
> > 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.
> >
> > 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 /all/ 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.
> >
> > Thoughts?
> > --
> > Andrew Arnott
> > "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
> >
> >
> > On Wed, Sep 30, 2009 at 5:33 AM, Nate Klingenstein <ndk at internet2.edu
> > <mailto:ndk at internet2.edu>> wrote:
> >
> >     Steven,
> >
> >     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.
> >
> >     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.
> >
> >     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.
> >
> >     Thanks for taking the time to read our piles of word salad,
> >     Nate.
> >
> >
> >     On Sep 30, 2009, at 9:56 AM, Steven Livingstone-Perez wrote:
> >
> >         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.
> >
> >
> >     _______________________________________________
> >     general mailing list
> >     general at lists.openid.net <mailto:general at lists.openid.net>
> >     http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > general mailing list
> > general at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090930/b82c4d27/attachment-0001.htm>