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
