Issues with single sign out

Dick Hardt dick at sxip.com
Tue Nov 7 23:28:54 UTC 2006


On 7-Nov-06, at 1:03 PM, Johannes Ernst wrote:

> On Nov 7, 2006, at 10:47, Dick Hardt wrote:
>
>> * clearing session cookies
>
> I think there are two ways of dealing with this:
>  - give the IdP/OP/whatever-its-name a means to tell the RP  
> directly that user X needs to be logged out, without going through  
> the browser. Disadvantage: doesn't go through a firewall in some  
> circumstances.

no access to cookie from app

>  - create a page at the IdP/OP with N iframes in it, each iframe  
> corresponding to a RP, accessing the RP with a parameter, such as  
> http://example.com/?lid= (as we do it right now in LID, or  
> something like it)

not all browsers send the cookies if the page is in a frame

>
> In addition, I think that RPs should always expire their sessions  
> after some time (minutes, not days) and automatically revalidate  
> with the IdP/OP. Then, by default, an abandoned computer logs  
> out ... as it is generally good practice for PCs.
>
>> * differentiating between logging out of the site and logging out of
>> all OpenID sessions
>
> This is important, thank you for bringing it up. I would suggest  
> that single-sign-out would always have to be triggered through the  
> IdP, never through a RP. If so, it could be left to the IdP/OP how  
> to implement that, just like we don't prescribe how to authenticate  
> either.

how does the user get to the OP to trigger it? Once logged in, there  
are no links to the OP unless it is the [logout] link
>
> I realize that just passes the buck, but I'm generally comfortable  
> not standardizing things where there are good chances we haven't  
> found a clearly superior design alternative. It might turn out to  
> be "log off on RP means log off from this RP only; big red button  
> on IdP means log off everywhere".

I was sharing the issues we had. I think until someone has the  
complete UX figured out, there is no point in implementing.

-- Dick



More information about the user-experience mailing list