OpenID Single-Sign-Off

[Kurt Raschke]

On Jul 1, 2005, at 1:26 PM, Kristopher Tate wrote:

> Either way, I think it is time for us to think about Single-Sign-Off.
>
> -Kris

I'm not entirely sure that this is the right direction for OpenID,  
for three reasons:

1.  Potential for unintended behavior:  Suppose I use an OpenID  
identity from Site A to log in to Site B.  While I'm working on Site  
B, my login to Site A expires.  Site A then triggers the OpenID  
single-sign-off mechanism, and logs me out of all of the sites I've  
logged in to using OpenID--including Site B.  Thus, at my next  
transaction with Site B, I'm suddenly asked to re-authenticate.  In  
addition to being confusing, being redirected back to a login page  
could lead to the loss of data in form submissions.

2.  Burden on consumers:  Consumers would have to support another  
type of OpenID request, even in the case of things like the  
guestbook, which does not keep any user state.  The guestbook,  
therefore, would have to accept and then silently discard the single- 
sign-off request.

     Additionally, suppose you've already signed out of a site you  
logged in to using OpenID--the site will still have to receive and  
process the single-sign-off request.

3.  Burden on producers:  Producers now have to track which sites  
each user is actively logged in to, and, as noted above, they still  
won't know if your session on the consumer has already ended due to  
some other reason.

If we were discussing an SSO system designed to be used among a  
number of servers on an internal LAN, this type of state-keeping and  
integrated sign-off would make sense.  However, given that OpenID  
producers and consumers are on the Internet, and operated by various  
entities with various security policies in terms of session time-out  
and such, I'm not sure that it makes sense in this case.

Is there something here I'm not seeing?

-Kurt