Non-directed identity UX question

[Allen Tom]

Hi George -

We've seen evidence that users mistype their OpenID urls on RPs, which is
not surprising since users probably aren't sure what their OpenID urls are
anyway...

My hunch is that most of the time, the user mistyped the string, rather than
is logged with the wrong account. If the user mistyped the string, then it
would seem best for the OP to just ignore what the user entered, or
alternatively tell the user to switch accounts.

If the user initiated the login process by entering their email address,
then I think it would more likely that the string is correct, since the user
probably knows their email address and is able to type it correctly.

I agree that delegation does seem kind of broken and needs to be fixed. I
would like the OP to know the URL that was delegated to it.

Allen



On 1/14/10 11:49 AM, "George Fletcher" <gffletch at aol.com> wrote:

> Hi,
> 
> Just wondering what others have done regarding the following use case.
> This is a non-directed identity flow. (Note: this is not an issue for
> directed identity because in that flow there is no user entered claimed_id).
> 
> 
> Alice is currently logged in to her OP (example.com) as aliceisno1
> (OpenID: http://aliceisno1.example.com). She then goes to a relying
> party (pictures.example.net) and starts a non-directed identity flow
> using the OpenID http://alice.example.com.
> 
> Question:
> 
> What should the OP show Alice when she arrives at the OP to
> authenticate? It seems to me there are a couple of options.
> 
> 1. Tell Alice that she's currently logged in as
> http://aliceisno1.example.com and then offer Alice an option of logging
> out of http://aliceisno1.example.com and logging in as
> http://alice.example.com. This would require the OP to ensure that only
> http://alice.example.com is authenticated after the logout event (or
> not... see option 2).
> 
> 2. Tell Alice that she's currently logged in as
> http://aliceisno1.example.com and ask if she wants to use that OpenID
> instead. (See note below about possible impacts on RP implementations).
> 
> 3. Ignore any SSO related cookies and just require Alice to authenticate
> http://alice.example.com and return the appropriate data without setting
> any session cookies. This could have some implications on global logout
> (but of course that's not supported right now).
> 
> [I've seen all three in the wild]
> 
> Of course Alice should be able to cancel any option and get back to the RP.
> 
> Option 2 impacts on RPs:
> 
> It turns out that for delegation reasons, the RP really should key their
> identity of the user on the claimed_id entered by the user. If the best
> practice (from a usability perspective) is to go with option 2, then RPs
> could connect http://aliceisno1.example.com to http://alice.example.com.
> What this means is that RPs need to do "late binding" and only key data
> by the user's claimed_id if the returned claimed_id matches what was
> entered.
> 
> Any idea of how many RPs do "early binding" vs "late binding"?
> 
> Other thoughts or suggestions?
> 
> Thanks,
> George
> _______________________________________________
> user-experience mailing list
> user-experience at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-user-experience