If the logout action is initiated at the OP then asking the user for scope is reasonable.
Scoping a logout coming from the RP is where it gets tricky. Allowing a RP to initiate logout of the user at the OP and all of the other RP is one of the use-cases that I have seen. My C was making the assumption that this is SP/RP initiated making B and C different. SLO is more of an issue in the EU where some government's have it as a requirement in there eGov deployment profiles for SAML. In the US it is not in the FICAM SAML 2.0 deployment profile, for several reasons. I think the place to start is by creating a requirements doc so we can all get on the same page for what the feature we want actually is. It is not enough just to say SLO is good. If you are coming to to the openID summit in London we can have a session on SLO. http://wiki.openid.net/2010-OpenID-Summit-EU If there are other hot topics people who are attending want on the agenda let me know. John B. On 2010-05-24, at 6:50 AM, Torsten Lodderstedt wrote: >> That is a reasonable approach and can be done within the existing spec by >> best practices if OPs support checkID immediate. >> >> the problem tends to be the scope of a logout button at the RP. > > Why not ask the user for the scope of the logout action? a) seems reasonable > to me in any case. b/c could be triggered if the user wants to be logged of > from all RPs he/her logged into using the same OP as the current RP. > > BTW: would you really distinguish b and c? I would tend to offer a user at > most the option to log off from the whole "cloud" of the OP and its RPs. > > At Deutsche Telekom, we use a (proprietary) SSO/SLO protocol and > automatically logoff users from the OP and all connected serices when they > logoff from any service. > >> >> Should that: >> a) only log the user out of the RP >> b) The RP + the OP >> c) The OP + all RP the user is logged into. >> >> SAML has two methods for c using front channel using http redirects. This >> is unreliable because users tend to close browsers and this results in a >> unpredictable state. The other is to use a back channel approach where the >> OP directly messages each RP that the user has logged out. It works better >> but is more complicated. >> > > The front channel approach has the advantage that the RP has access to all of > its cookies stored in the user agent. It can properly cleanup the session > and, moreover, this characteristics opens opportunities to design a session > management w/o the need for a backend session database. > > As you pointed out, the back channel approach is more complicated. It > requires a session handle and forces the RP to have a backend session > database, or at least a session revocation list. > >> A better approach would be for session cookies to be easily identifiable in >> the browser and give the user a reasonable UI for removing them. >> That would be protocol independent. > > If I understand you correctly, this requires some kind of browser plugin > aware of OpenId RP/OP session cookies. What troubles me is if the user just > deletes the cookies, the RP/OP does not have a chance to detect the "logoff" > and cleanup resources associated with the user session. > > regards, > Torsten.
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
