[OpenID] What about Logout?
rabbit at cyberpunkrock.com
Thu Apr 9 09:13:22 UTC 2009
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
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.
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
> Thus the RP rendering the desktop page does not know all widget
> 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
>> 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
>> 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
>> 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.
More information about the general