Interruptions in authentication process

[George Fletcher]

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"<breno at google.com>  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<alex at developmentseed.org>  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
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>        
>>
>>      
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100112/a79c3b88/attachment.htm>