[OpenID] Logout Use Case

[Steven Livingstone-Perez]

Thanks for that Nate.

So it does seem a push (via OP callback for apps that have a tcp channel 
open)/pull (RP polling when it's a client that does not... particularly 
useful when inside the firewall) approach would need to be used.

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.

This may also be useful:
https://wiki.aai.niif.hu/index.php/ShibIdpSLO

/steven
http://livz.org

--------------------------------------------------
From: "Nate Klingenstein" <ndk at internet2.edu>
Sent: Wednesday, September 30, 2009 1:05 AM
To: "Steven Livingstone-Perez" <weblivz at hotmail.com>
Cc: "Jonathan Coffman" <jonathan.coffman at gmail.com>; <general at openid.net>
Subject: Re: [OpenID] Logout Use Case

> Steven & Jonathan,
>
> Remember that HTTP user-agent sessions are persisted in several ways: 
> some are entirely client-based state in the form of cookies, while  others 
> primarily manage server-side state.  Pushing out messages to  the RP is 
> not necessarily sufficient to either deal with client-based  state or deal 
> with session state persisted by the applications  themselves once a login 
> context is established via OpenID.
>
> I suggest you take some time to read about the way Shibboleth thinks 
> about federated SLO.
>
> https://spaces.internet2.edu/display/SHIB2/SLOIssues
> https://spaces.internet2.edu/display/SHIB2/SLOWebappAdaptation
>
> Take care,
> Nate.
>
> On Sep 29, 2009, at 10:53 PM, Steven Livingstone-Perez wrote:
>
>> - OP maintains a list of RPs the user is currently logged in to and  upon 
>> RP1 killing it's local session and pinging the OP, the OP then  'pushes' 
>> a message out to all of the other RPs instructing them to  kill the 
>> user's session.
>
>