[OpenID] What about Logout?

Peter Williams pwilliams at rapattoni.com
Thu Apr 9 10:09:08 UTC 2009

> -----Original Message-----
> From: Rabbit [mailto:rabbit at cyberpunkrock.com]
> Sent: Thursday, April 09, 2009 2:13 AM
> To: Peter Williams
> Cc: Johannes Ernst; general List
> Subject: Re: [OpenID] What about Logout?
> I think I see what you mean.
> In common practice, I doubt this will be terribly problematic given
> session timeout, though I'm interested to hear why this would be a
> pressing issue.

I'm not sure SLO is that pressing in today's openid world, wanting to share a few address books to define one's personal community of interest.

I'm assuming a UI world along the lines of
http://ontologyonline.org/visualisation/c/GeneOntology/gene+ontology+entity, where both identity management federations AND data mesh federations are driving the interactions with and between widgets. I'm also assuming that RPs in "RP affiliations" are communicating in computing grids, using the grid bindings for web service providers that are supporting a "main" RP.

It's fair to say, this is not your classical social networking or portal site.

> Beyond the OP, the browser is the next best place to handle session
> management. The only alternative would be to have all OPs know about
> each other at least to the extent that they know "User X has an
> account with OP Y whose logout endpoint is Z" without knowing
> precisely what account User X has at OP Y. If there was a way for OPs
> to send a logout signal to RPs, then the User would only need to be
> redirected (silently if need be) to the OP logout endpoints.
> That sounds pretty complicated though.

Assuming folks eventually become rational and apply https, there is also the control point known as the SSL sessionid cache - already handling advanced multi-component session management for hypermedia communications. Rather than build browser plugins, I'd rather see SSL support websso properly.

I think we have gone WAY WAY beyond today's reality in openid adoption, tho. But it's nice to see the roadmap over 2-5 years.
> =Rabbit
> On Apr 9, 2009, at 4:47 AM, Peter Williams wrote:
> > I like the thinking, and it was very clearly expressed.
> >
> > But there is the case that different widgets [being openid...where
> > RP's (vs user's) discover and select metadata] choose different OPs
> > which like yahoo may have persistent OP sessions.
> >
> > Thus the OP supporting the initial desktop page does not know all
> > sessions.
> > Thus the RP rendering the desktop page does not know all widget
> > sessions.
> > Thus no one widget knows all widget sessions.
> >
> > There is no obvious party that knows all sessions, to present a
> > multi-session authority UI for user selected-logout. Only a browser
> > plugin could be knowing the total picture.
> >
> > As I said in a private  email to some folks, the nearest we came to
> > addressing this (to us, a very real issue set) with current open
> > standards was to impose SAML2's idp-proxying model on the widgets,
> > forcing the widgets to use the same IDP as the desktop RP.  But even
> > this was not entirely successful, and openid auth has no constrained
> > op proxying model - in any case.
> >
> >> -----Original Message-----
> >> From: Rabbit [mailto:rabbit at cyberpunkrock.com]
> >> Sent: Thursday, April 09, 2009 1:23 AM
> >> To: Peter Williams
> >> Cc: Johannes Ernst; general List
> >> Subject: Re: [OpenID] What about Logout?
> >>
> >>
> >> On Apr 8, 2009, at 11:43 PM, Peter Williams wrote:
> >>
> >>>
> >>> And if a users RP page consists of a mashup of several other RPs,
> >>> each supported by one of several (RP's choice of) OPs?
> >>>
> >>
> >>
> >> The RP should work within its own domain of concerns.
> >> When it comes to SSO, the RP is only concerned with two things:
> >>
> >> 1) The User session with an OP
> >> 2) The RP session with the User
> >>
> >> (And the RP is only concerned with #1 by the nature of the
> protocol.)
> >>
> >> RP sessions are started by logging in through one OP. That is the
> >> only
> >> OP the RP should be concerned with. If the RP supplies widgets for
> >> other services that the User logs into using different OPs, those
> >> widgets are additional RPs and none of the initial RPs concern. The
> >> RP
> >> should not care how the User is logged into those other widgets.
> It's
> >> only concerned with providing the widgets to the user. The
> >> functionality of those widgets is handled mostly out of band (ie:
> >> Netvibes supplying a Facebook widget).
> >>
> >> If I'm not understanding your example, and it truly is the RPs
> >> responsibility to manage the sessions of multiple OPs for a single
> >> User, then I would say it still comes down to two choices:
> >>
> >> 1) A "Logout" link that ends the session between RP and User.
> >> 2) A "Logout" dialog that gives the User the choice of which
> sessions
> >> to end.
> >>
> >> The second option, I still strongly feel, is more within the OPs
> >> domain of concerns and so the User should be sent to the OP where
> >> they
> >> may be given the option to end sessions with individual RPs, all
> RPs,
> >> or sign out of the OP itself. Any cancel links would return the user
> >> back to the RP still signed in.
> >>
> >> =Rabbit

More information about the general mailing list