Interruptions in authentication process

Allen Tom atom at yahoo-inc.com
Tue Jan 12 00:54:28 UTC 2010


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
>> 
> 
> 



More information about the specs mailing list