<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">If the logout action is initiated at the OP then asking
the user for scope is reasonable.
<div><br>
</div>
<div>Scoping a logout coming from the RP is where it gets tricky.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>My C was making the assumption that this is SP/RP initiated
making B and C different.</div>
</blockquote>
<br>
understood.<br>
<br>
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">
<div><br>
</div>
<div>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.</div>
</blockquote>
<br>
our security team also requires SLO<br>
<br>
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">
<div><br>
</div>
<div>In the US it is not in the FICAM SAML 2.0 deployment profile,
for several reasons. </div>
<div><br>
</div>
<div>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.</div>
</blockquote>
<br>
agreed.<br>
<br>
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">
<div><br>
</div>
<div>It is not enough just to say SLO is good.</div>
</blockquote>
<br>
That's true :-)<br>
<br>
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">
<div><br>
</div>
<div>If you are coming to to the openID summit in London we can have
a session on SLO.</div>
<div><span class="Apple-style-span" style="font-family: Times;">
<pre><a moz-do-not-send="true"
href="http://wiki.openid.net/2010-OpenID-Summit-EU">http://wiki.openid.net/2010-OpenID-Summit-EU</a></pre>
</span></div>
</blockquote>
<br>
I'm unfortunately unable to attend, but I would very much like to
contribute to the WG's work. <br>
<br>
regards,<br>
Torsten.<br>
<br>
<blockquote cite="mid:4DDEB683-E386-466B-967B-5925DE2708B6@wingaa.com"
type="cite">
<div>
<div><br>
</div>
<div>If there are other hot topics people who are attending want on
the agenda let me know.</div>
<div><br>
</div>
<div>John B.</div>
</div>
<div><br>
<div>
<div>On 2010-05-24, at 6:50 AM, Torsten Lodderstedt wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:51E02E7F-9C7A-482E-883B-8220EC6BB921@wingaa.com" type="cite">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>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>