[OpenID] Feedback from OpenID demo

[Luke Shepard]

Agreed, logout_immediate can be scary. I think it would be fine to start with just logout_setup - simpler is better after all. A provider that wants to aggressively log out can just redirect immediately if it wants to.


On 5/27/09 10:09 AM, "David Recordon" <david at sixapart.com> wrote:

I agree that logout_immediate seems a bit scary, if we already have a
challenge explaining to users what "always remember" means and will
do, having an OP also explain that the site could log them out is even
more complex.  I think the equivalent of a logout_setup makes sense
especially when combined with a popup style UI.

--David

On May 26, 2009, at 6:03 PM, Martin Atkins wrote:

> 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.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090527/8a985e35/attachment.htm>