A potential issue is that supporting checkid_immediate makes it impossible to support the switch users feature.
At Yahoo, we do not support having simultaneous authentication sessions for different accounts on the same browser. It¹s theoretically possible to do this, however, I think that many users might be confused by the behavior. Allen On 1/12/10 5:02 AM, "George Fletcher" <[email protected]> wrote: > Regarding case B... > > At AOL if the user is already authenticated but has not given consent to be > "identified" to the RP we show a consent screen and allow the user to logout > and login as a different user (a.k.a. "switch users"). Also on this consent > screen we allow the user to permanently remember their consent decision. This > effectively give the user seamless SSO the next time they log into that RP. Of > course these consents can be revoked by the user. > > One of the issues of "switch user" is that it terminates the previous web > session. So if the user was reading mail for the first user, their mail > session is logged out. It's possible to keep these authentications separate > but in the end that seems more confusing for the user than helpful. > > I'm curious as to others experience. > > Thanks, > George > > On 1/11/10 7:54 PM, Allen Tom wrote: >> >> Hi Alex - >> >> I agree with Breno that cases A and C require the user to restart the >> process from the beginning. Given that the user indicated that they wanted >> to authenticate using an account at the OP, presumably the user chose an OP >> for which they already have an account and remember the password, so >> hopefully A and C are edge cases. >> >> Our statistics indicate that the overwhelming majority of the time, the user >> is already signed into Yahoo when the Yahoo OP receives an authentication >> request. I believe that other OPs have also observed similar behavior. >> >> B is definitely an interesting case, as people often have several accounts >> and may want to "switch users" before signing into the RP. I think the best >> UX would be for the OP's approval screen to indicate which account the user >> is currently signed in with, and an option to sign in as a different user. >> >> Allen >> >> >> >> >> On 1/11/10 3:01 PM, "Breno de Medeiros" <[email protected]> >> <mailto:[email protected]> wrote: >> >> >> >>> >>> For many RPs, if user starts processes A or C (with regards to their >>> in-house login system), I assume it'd still be often the case where >>> the user will have to re-start the process from the original context. >>> >>> Case B is more interesting as it raises issues exclusive to use of a >>> (open) federated login system. >>> >>> On Mon, Jan 11, 2010 at 14:44, Alex Barth <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> >>>> >>>> >>>> In the course of ironing out workflows between OpenID provder and OpenID >>>> relying parties it I am facing usability problems that I'd like to submit >>>> here to the attention of some more experienced OpenID developers than I am. >>>> >>>> I am interested in any feedback, pointers to existing conversations, >>>> sections in current and future specs that I may have overlooked etc. >>>> >>>> Here is the problem: There are some actions that can occur during >>>> authentication where a user can fall through the cracks: >>>> >>>> A User is redirected with an authentication request from RP to OP, requests >>>> a new password on OP, email client opens different browser for a one time >>>> password reset link embedded in the email. >>>> B User is redirected with authentication request from RP to OP, but would >>>> like to log in with different user than the one currently authenticated on >>>> OP, user is logged out and session is deleted. >>>> C RP offers OP as identity provider, user selects OP, is redirected with >>>> authentication request to OP. User does not have an account yet, creates >>>> one, confirms email address, but again, email client opens different >>>> browser >>>> (similar to A). >>>> >>>> In all of these scenarios the user's session and with it her authentication >>>> request is lost - the authentication process is stuck in its tracks. >>>> >>>> Is the assessment of the problem flawed? Is there a solution in the specs >>>> that I am overlooking? >>>> >>>> Thank you for your input. >>>> >>>> Alex Barth >>>> http://www.developmentseed.org/blog >>>> tel (202) 250-3633 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
