<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:51E02E7F-9C7A-482E-883B-8220EC6BB921@wingaa.com"
type="cite"><base href="x-msg://50/">That is a reasonable approach and
can be done within the existing spec by best practices if OPs support
checkID immediate.
<div><br>
</div>
<div>the problem tends to be the scope of a logout button at the RP. </div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
<blockquote cite="mid:51E02E7F-9C7A-482E-883B-8220EC6BB921@wingaa.com"
type="cite">
<div><br>
</div>
<div>Should that:</div>
<div>a) only log the user out of the RP</div>
<div>b) The RP + the OP</div>
<div>c) The OP + all RP the user is logged into.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</blockquote>
<br>
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.<br>
<br>
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. <br>
<br>
<blockquote cite="mid:51E02E7F-9C7A-482E-883B-8220EC6BB921@wingaa.com"
type="cite">
<div>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.</div>
<div>That would be protocol independent.</div>
</blockquote>
<br>
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.<br>
<br>
regards,<br>
Torsten.<br>
</body>
</html>