[OpenID] Logout Use Case

[Andrew Arnott]

Facebook as you know already has a form of single-sign-out.  When I log out
of lala.com, I'm asked whether I want to log out of lala.com only, or both
lala.com and Facebook.  This seems user friendly enough.  Although it leaves
out the option of "log out of lala.com, Facebook, and everything else
Facebook has helped you log into."
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>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
> 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/2c613559/attachment.htm>