OpenID v.Next Core Protocol Charter

[Torsten Lodderstedt]

> 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.

understood.

>
> 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.

our security team also requires SLO

>
> 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.

agreed.

>
> It is not enough just to say SLO is good.

That's true :-)

>
> 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

I'm unfortunately unable to attend, but I would very much like to 
contribute to the WG's work.

regards,
Torsten.

>
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100526/00cbd92e/attachment.html>