[OpenID] Feedback from OpenID demo

[Martin Atkins]

Bill Shupp wrote:
> 
> Obviously, #2 really highlighted #1.  People thought that login should 
> be an explicit action, not automatic.  When discussing #1, I mentioned 
> an idea that Luke Shepard shared this week at IIW, of adding 
> "logout_setup" and "logout_immediate" to the protocol.  The idea being 
> that if you click logout on the RP, it could send a "logout_setup" to 
> the OP, which would trigger a popup asking if you also want to logout of 
> the OP as well.  This idea got a pretty favorable response, and seemed 
> to satisfy some of those concerned with the Single Sign Out issue.  
> "logout_immediate" could behave similar to "checkid_immediate", where 
> the logout is performed without user interaction, and might be favored 
> by higher value RPs like mint.com or the like.  Obviously, there's room 
> for RP abuse here, though.
> 

This logout_immediate thing makes me nervous for the reason you state at 
the end here. checkid_immediate doesn't actually change any state on my 
OP, it just inspects the state. logout_immediate *does* change state in 
on my OP from the context of my RP, which I don't like the sound of at all.

logout_setup is better because it is an interation at the OP that causes 
the change in state. This creates a log out flow similar to one I've 
created on a current project of mine where I have behavior that could be 
described as single sign-on: the Sign Out link goes to a page served 
from the authentication provider which explains that this action will 
also end the session on all other sites in the "network" and offers the 
user a chance to back out if that's not what he wanted to do.

Also, without the RP periodically checking in with the OP this doesn't 
seem to solve the problem: if I use the "Log Out" function on one RP I 
get logged out of that RP and my OP but not any other RPs I'm already 
logged in to. Doing some kind of call to the OP on every request (or 
every few requests), much as is done with Facebook Connect today, can 
solve this problem, but it creates new problems:

  * The user experience on the RP may be impacted in a far worse way if 
the OP is down or slow.

  * It dramatically increases the amount of load an OP has to deal with; 
many of today's OPs probably aren't scaled to deal with it.

  * It will need to deal sensibly with the transition between one 
identifier and another as well as the transition between logged out and 
logged in and vice-versa. In Facebook's current implementation I can 
attach multiple identifiers to my account, so this change in identifier 
might also change the OP in use, requiring the RP to check in with all 
of them.